apex/up 7975
Deploy infinitely scalable serverless apps, apis, and sites in seconds to AWS.
apex/gh-polls 1680
Polls for user feedback in GitHub issues
JustinTulloss/zeromq.node 1663
Node.js bindings to the zeromq library
c4milo/gsync 334
gSync is an rsync based library for sending delta updates of files to a remote server.
apex/static 296
The static site anti-framework – general-purpose library, purpose-built commands for various domains
koajs/koa-hbs 156
Handlebars templates for Koa.js
apex/gui 132
GitHub readme UI components
Axis360 is a panoramic (360 video) rendering engine
Apex monochrome Atom theme UI (slim variant)
Lightning fast template and view engine built on top of Incremental DOM and Babel (ES6 Templates + Incremental DOM working together)
issue commentapex/logs-js
Thanks for pointing that out, I can reproduce it as well. I'll see what's going on there
comment created time in 10 hours
issue openedapex/up
logs --format should accept json for logs
Currently you have to do up logs | cat to trigger the !isatty() condition, but there should be a flag
created time in 2 days
issue commentgolang/go
proposal: spec: add sum types / discriminated unions
My only feedback is that type foo,bar inside of an interface looks a bit awkward and second-class, and I agree that there should be a choice between nullable and non-nullable (if possible).
comment created time in 2 days
issue commenttj/gobinaries
definitely free to run your own, but probably not as a subdomain on gobinaries.com
comment created time in 3 days
issue commentapex/up
Trouble with deploing zip archives with terraform
Hmm I'm not sure I understand the scenario, you use Up to build and then Terraform to deploy? By default Up will build your program as ./server, and Up itself injects ./main (the Up proxy) before deploying so it becomes part of the zip.
The ./main is cmd/up-proxy, and it's stored in the up binary, so I guess if you wanted to avoid using up for deployments you would have to do your own build and copy it to ./main. This is where that happens https://github.com/apex/up/blob/cafa45273ba0949244219265f23803c47fda6947/platform/lambda/lambda.go#L907-L919
comment created time in 4 days
issue commentapex/logs-js
Adding option "snapshot" to an event
ahh true, it would have to hide it in multiple locations, not just the "Discovered fields" panel. Maybe context is the way to go, I'll have to think about that some more
comment created time in 4 days
issue commentapex/logs-js
Adding option "snapshot" to an event
You should be ok! unless you're hitting that error maximum allowed length of 1024 bytes you shouldn't need to re-create the project. Currently everything is always searchable, but having something like context along with fields might be nice as you mention just to keep it out of the UI.
I think it could be solved in the UI as well, maybe a menu item for the fields where you can hide everything nested so it's not so noisy
comment created time in 5 days
startedcharmbracelet/bubbletea
started time in 7 days
push eventapex/logs-js
commit sha b306a125112069a674b936fb7c36bc839748e0ae
add test.js to gitignore
commit sha 0166bfcedf2abcb9efbd0c8145e27d3d678180ff
regenerate to add `project.mode`
commit sha 0ea03f6270aa7703eade28054e898d267d80a6fb
Release v1.2.0
push time in 8 days
push eventapex/rpc
push time in 8 days
push eventapex/rpc
commit sha 77da68924a863c528cea4d91352f416e6b2556e1
add checking of invalid HTTP scheme for Go client as using HTTP results in a silent failure
commit sha a5acf04d79f98445e58cb9c4fba79db162e7f2a7
add errors and net/url imports for Go client
push time in 8 days
push eventapex/logs
commit sha 145adab63b05111d9c61bfb6cd8567dc1f9a8581
regenerate to add Project.Mode field
commit sha 76b57193b25fb1e97e1668560ab611779370f298
Release v1.1.0
push time in 8 days
issue closedapex/roadmap
This should be pretty easy actually, likely within the next week or so. The only awkward part I see so far is that Heroku doesn't differentiate between stdout and stderr, so we'll probably have to check for common keywords or something there.
- [x] add endpoint
- [x] move parsing to ./internal and share with CloudWatch
- [x] add tests
- [x] add auth
- [x] add parsing of logfmt
- [x] add styling of empty
message - [x] add omission of empty
messagefrom field stats? - [x] add fields to internal CR logs
- [ ] decide on convention for
source[proc]fields - [ ] add event formatting so it looks familiar to Heroku users
- [ ] rename a few fields?
servicefor example is not very descriptive - [ ] add to marketing site
- [ ] treat deploys as annotations
- [ ] QA (test batching as well)
- [ ] document
- [ ] guides
- [ ] blog post
- [ ] marketing??
- https://devcenter.heroku.com/articles/logging
- https://devcenter.heroku.com/articles/log-drains
closed time in 8 days
tj
issue commentapex/roadmap
pretty much done but Heroku does virtually zero buffering so it hits the API with a lot of requests, which kind of hurts the cost-effectiveness of Apex Logs, this might need revisiting
comment created time in 8 days
issue closedapex/roadmap
Currently it's focused on structured logging, as message has a 1024 byte limit. This option while creating a project would effectively remove that limit, at the cost of slightly worse performance (at 500gb+ scales, generally nothing to worry about)
- [x] add option to schema
- [x] add option to UI
- [x] integrate
- [x] QA with and without
- [ ] regenerate clients
- [ ] regenerate docs
closed time in 8 days
tj
issue closedapex/logs-js
Insertions fail when key too long
Hey there, seeing this error quite frequently:
Clustering encountered a key Msg_0_CLOUD_QUERY_TABLE.message that is 2115
bytes long, which is more than the maximum allowed length of 1024 bytes.
I have an example request that's failing, but it's long and contains some potentially sensitive information that I don't trust myself to remove so I can send it privately.
Thanks!
closed time in 9 days
obibring
issue commentapex/logs-js
Insertions fail when key too long
If you run $ logs upgrade && logs instance update to update to v0.9.21 you should see a "Storage mode" option when creating a project, and the new plain-text option will remove this 1024 byte restriction.
If you wanted to retain your old logs you could create a new project, and start sending logs to that one instead, or like we talked about you could quickly delete/re-create a project with the same name to avoid re-deploying your app(s).
Let me know if there are any issues!
comment created time in 9 days
issue commentapex/logs-js
Insertions fail when key too long
Just a quick update. I have it almost ready to go, doing some QA today and then there should be a release tomorrow morning!
comment created time in 9 days
push eventtj/tj
commit sha a38e3022c6df75da206c1fb0398a352cfb4ce4b5
adjust copy
push time in 10 days
push eventtj/tj
commit sha b495b8520b8f3873a0652543eecfb98c1682962b
remove logs for now
push time in 10 days
push eventapex/logs
commit sha 2d8c5f6c2b4bf5ca713bb2b1a4cc826138712455
add ErrInvalidScheme when HTTP is used HTTP can result in silent failure, as Cloud Run will redirect to HTTPS, which in turn is a 200 for the HTML content
commit sha 4009f12b22f897e60ad3f6c7dd2eb96cf6edc148
Release v1.0.1
push time in 10 days
issue openedapex/roadmap
Currently it's focused on structured logging, as message has a 1024 byte limit. This option while creating a project would effectively remove that limit, at the cost of slightly worse performance (at 500gb+ scales, generally nothing to worry about)
created time in 10 days
issue commentapex/logs-js
Insertions fail when key too long
Yep, if you give it the same name you'll have the same slug used for the ID and all the logs will just start going there again. Technically you'd maybe have 30s of downtime or so, I don't know that there's a way around that unless it's a new ID and you re-deploy stuff to point there
comment created time in 10 days
issue commentapex/logs-js
Insertions fail when key too long
No problem! Appreciate your team giving it a try, let me know if there's anything you feel is missing, I have a pretty huge to-do list but that can always help me prioritise.
I just looked at the message length, it's 59 characters. Is that error expected for such a length? Is their a recommended max length?
hmm that doesn't sound right, I can't imagine even 59 multi-byte characters taking up 1024 bytes. I definitely use more than that for my own logs, I try to keep most of mine as actionable messages like "user login", "error sending email" etc, but I have a lot of longer plain-text from Lambda as well
comment created time in 10 days
issue commentapex/logs-js
Insertions fail when key too long
Currently message is special-cased for the structured use-case to improve performance. The only solution I can think of right now is to add an option when creating a project, basically to opt-out of the performance and allow much larger messages. The performance improvement is negligible until you're in the 500gb+ range anyway.
For now if it's ok for your app you could use some fields which don't have this restriction, for example instead of putting a stack trace in message just add the error message and then use a field such as trace or stack.
I'll try to get that option in soon, hopefully it won't be confusing
comment created time in 10 days
issue closedapex/gh-polls
"api.gh-polls.com" certificate is expired
The svg can't render in https, help wanted QAQ
closed time in 11 days
yuxino
issue commentapex/gh-polls
"api.gh-polls.com" certificate is expired
should be ok now!
comment created time in 11 days
push eventtj/tj
commit sha 2e61e497bcabf33daf87fe32c08632f166025f46
Update Readme.md
push time in 11 days
push eventtj/tj
commit sha 5e2d1f8ca3e56a9f2f75a9ca0eb7ccbf3d28f03f
add new companies thanks!
push time in 11 days
issue commentapex/gh-polls
"api.gh-polls.com" certificate is expired
my bad, I keep forgetting to fix this, should have some time today
comment created time in 11 days
push eventapex/invoke
commit sha ee7853bbf7654e62593d21f0b40ea7a6d734b7b8
fix SyncQualifier() document
commit sha 9ccbf64cf32d0fcee1ff0736fdfaa2eeca77f78c
Merge pull request #4 from d-tsuji/patch/d-tsuji fix SyncQualifier() document
push time in 12 days
issue commentopentracing/opentracing-go
Simplify capturing errors from Spans
@yurishkuro I don't actually use defer much in practice, not sure why I suggested that haha but yeah I agree
comment created time in 15 days
issue openedapex/roadmap
- [ ] move search to the top or bottom
- [ ] refactor query settings to look nicer and add this option
created time in 15 days
push eventtj/tj
commit sha 20ae608f9bfc2587d7a489e5f83bada5b27b4f41
add missing link
push time in 16 days
push eventtj/tj
commit sha f5116765969221eb40a443adf346bcc38b74d24e
remove a few avatar placeholders
push time in 16 days
push eventtj/tj
commit sha 98f20de0cc093c559f805a8b05f5bdac152e22e4
add placeholder
push time in 16 days
push eventtj/tj
commit sha 9613d22a2352e8dbcff4e1ecd6bc45d8f5c00bff
change links
push time in 16 days
push eventtj/tj
commit sha a49975af9df25e71a44dcd680a0263e01021cd9a
add sponsors to my profile why not
push time in 16 days
push eventtj/tj
commit sha d0f6ec8c52cdded7a0625aef6662a2060ab39111
Update Readme.md
push time in 16 days
issue commentaws/aws-sam-cli
I think I found it, I'm generating a template, and Go outputs null for nil slices, so it was Layers: null for a Lambda function. It validates as ok though, so something funky in the logic there, it would be nice if the validation was performed when packaging as well (if it's not already).
comment created time in 16 days
issue commentaws/aws-sam-cli
FWIW I updated to 1.4.0 and it's giving me the same error
comment created time in 16 days
issue commentaws/aws-sam-cli
I get this as well. It would be great to write SAM in something more robust and portable (Rust, Go, etc), Python always causes issues with its weird versioning as well
comment created time in 16 days
issue closedtj/sponsors
RPC API server, client, and documentation generation for Go
There's too much boilerplate for APIs right now, and many existing solutions are over-engineered for many use-cases in my opinion. I'd like to polish what I use internally, and make it available as OSS.
It could use GraphQL for the schema, but I don't use GraphQL for querying or mutations personally, queries are fine but mutations are pretty awkward, and not curl-friendly.
It would be similar to JSON-RPC, simple input and output, and the "method" in the URL, for example curl -d '{ "email": "tj@apex.sh" }' https://api.example.com/send_email. RPC has some limitations, however, in most cases I think this works great and performs perfectly fine, you can drop back to vanilla HTTP for edge-cases.
I'll add more details here if people are interested.
Features
- Statically typed schema definitions, simpler than OpenAPI and friends due to RPC restrictions
- Generate clients for JS, Go, TypeScript, etc
- Generate documentation as markdown and HTML
- Generate a server, internals of each method are user-defined
closed time in 16 days
tj
issue commenttj/sponsors
RPC API server, client, and documentation generation for Go
https://github.com/apex/rpc
comment created time in 16 days
issue commentapex/up
Add timeout config option when invoking lambda directly.
awesome!
comment created time in 17 days
push eventapex/up
commit sha cafa45273ba0949244219265f23803c47fda6947
merge History.md
push time in 17 days
issue commentapex/up
Add timeout config option when invoking lambda directly.
up upgrade should give you v1.7.0-pro with lambda.timeout defaulting to 60 seconds
comment created time in 17 days
push eventapex/up
commit sha 2b695f1dc2f23ba4cc7856d0ca0fe92c43e0da96
Release v1.7.0
push time in 17 days
push eventapex/up
commit sha 15098243be37f15ead97992c308a4bd1f42a820b
add DeletionPolicy Retain to DNS zones this can easily create a conflict if you start manually adding records to the zone
commit sha 2354e3a6832baa756f23732e6ca5733bb6df266d
add UpdateReplacePolicy Retain to DNS zones
commit sha 40a25bc0dac0216c4679612ce54560f89aa21323
add lambda.timeout back, defaulting to 60s. Closes #814 I will leave this undocumented for now since it is an uncommon use-case at the moment, but you can make this whatever you like for background processing by crafting your own Lambda event which looks like a request, bypassing API Gateway
commit sha 9770c5062e3a39563d183f84ce51cec52bf683ec
change LICENSE, commercial use requires a subscription
push time in 17 days
issue closedapex/up
Add timeout config option when invoking lambda directly.
Prerequisites
- [x] I am running the latest version. (
up upgrade) - [x] I searched to see if the issue already exists.
- [x] I inspected the verbose debug output with the
-v, --verboseflag. - [x] Are you an Up Pro subscriber?
Description
I'd like to call my application (lambda function) directly with cloudwatch for daily batch work which takes longer than 30 seconds. I've increase the timeout on my lambda function, but there is still a timeout in up which I can't modify. I did find a similar request https://github.com/apex/up/issues/751. I'm asking for the something similar with another reason. Please give us a way to increase the timeout when calling lambda directly and not through api gateway.
I understand as a workaround I can deploy "background work" as a separated function and call it, but up is already configured with all my CI pipelines and environment variables and I really like using up! This would be an amazing feature for me.
Steps to Reproduce
Deploy an application which takes longer than 15 seconds to complete:
const Koa = require("koa");
const app = module.exports = new Koa();
app.use(async function(ctx) {
await new Promise((resolve) => setTimeout(resolve, 60000));
console.log("Blocking log");
ctx.body = "Hello World";
});
if (!module.parent) app.listen(process.env.PORT || 3000);
Run the following commands:
up
aws lambda update-function-configuration --function-name apex-timeout --timeout 100 --region eu-west-1
aws lambda invoke --function-name apex-timeout --cli-binary-format raw-in-base64-out --payload '{ "path": "/" }' out --log-type Tail --region eu-west-1 --query 'LogResult' --output text | base64 -d
Output:
.
.
.
2020/08/31 11:21:43 http: proxy error: net/http: timeout awaiting response headers
{"fields":{"app":"apex-timeout","duration":15021,"id":"","ip":"","method":"GET","path":"/","plugin":"logs","query":"","region":"eu-west-1","size":0,"stage":"staging","status":502,"version":"$LATEST"},"level":"error","timestamp":"2020-08-31T11:21:43.092673704Z","message":"response"}
END RequestId: ***
REPORT RequestId: *** Duration: 16129.38 ms Billed Duration: 16200 ms Memory Size: 512 MB Max Memory Used: 98 MB Init Duration: 182.57 ms
When I try to increase the timeout to 100 using .proxy.timeout:
Error: initializing: reading config: validating: .proxy: .timeout: should be <= 25
up.json for reference:
{
"name": "apex-timeout",
"regions": [
"eu-west-1"
]
}
Love Up?
Please consider signing up for Up Pro (https://up.docs.apex.sh/#guides.subscribing_to_up_pro) or donating via https://opencollective.com/apex-up/donate.
Slack
Join us on Slack https://chat.apex.sh/
EDIT: updated aws cli command to work with cli version 2
closed time in 17 days
t1bb4r
issue commentapex/up
Add timeout config option when invoking lambda directly.
You're right sorry, my brain wasn't working yesterday haha. I'll add an option and maybe just default it to something higher
comment created time in 17 days
push eventtj/tj
commit sha f4934baa1cea8b310c8a0d5e366556e78bc042cf
Update Readme.md
push time in 17 days
push eventtj/tj
commit sha daeee611c9e0e8bbfab81d7b5b6ab4809c02b352
Update Readme.md
push time in 17 days
push eventtj/tj
commit sha c3907a4d6597a2585269d0d8c4106549b800d96a
Update Readme.md
push time in 17 days
push eventtj/tj
commit sha 9630fbbb2ae93c1e7c2bbc22d6e7bb2319455b98
Update Readme.md
push time in 17 days
push eventtj/tj
push time in 17 days
push eventtj/tj
commit sha 426980a3695676ccf5dd1c657ef7198c830295dd
Update Readme.md
push time in 17 days
push eventtj/tj
commit sha dc7c577f14fcd48be92110f4ac5ef842e9155f9b
Update Readme.md
push time in 17 days
issue closedmochajs/mocha
Since OpenCollective has more funds than I do in the bank, and no one is willing to share for the % of contributions I've made to the project, I would like to delete every line which is still associated with my commits. I'll try to send a pull-request soon, same for the docs and website.
closed time in 17 days
tj
issue commentmochajs/mocha
To be fair he's done a lot of work as well, just feels a bit shady, but whatever don't worry about it I guess. OSS sucks
comment created time in 17 days
issue commenttj/gobinaries
👍 I'm not sure it's possible to get that info from Cloudflare, it would be cool!
comment created time in 17 days
issue openedmochajs/mocha
Since OpenCollective has more funds than I do in the bank, and no one is willing to share for the % of contributions I've made to the project, I would like to delete every line which is still associated with my commits. I'll try to send a pull-request soon.
created time in 17 days
issue commentapex/up
Add timeout config option when invoking lambda directly.
Oh sorry what I said doesn't make sense actually, not sure what I was thinking haha. The regular proxy.timeout should be ok for the 25 seconds for API Gateway, and then this X-Up-Timeout for internal invocations? I thought that was the intention of d5e15dfe
comment created time in 18 days
push eventapex/actions
commit sha bfdcc640c26bfe23e108d759182d9b5b92f9d7da
remove aws/sam action
push time in 19 days
push eventapex/actions
commit sha 4229101502ccc07186388684c3acdd319e9d0440
docs
push time in 19 days
issue commentapex/up
Add timeout config option when invoking lambda directly.
Hmm if you set the proxy.timeout to 900 and X-Up-Timeout that should be enough right? That should give you the override for background work, and the default for the API Gateway UX
comment created time in 19 days
push eventapex/actions
commit sha 11d0c1fc19f07c2617ae826c817bdc358ac16d04
remove go action use the official one
push time in 19 days
push eventapex/actions
commit sha 51619b34c84d06c5a1f546c201824bf36a86cd5e
try stage only new actions stuff seems to not allow passing all the args?
push time in 19 days
push eventapex/actions
commit sha fc148c8eed77598a7f2aa80255a9020fcc6aec8e
remove default CMD
push time in 19 days
push eventapex/actions
commit sha f5de570771557ae3d04f1b1d1c287e6323e5e613
remove default
push time in 19 days
push eventapex/actions
commit sha 18160a4e1c5084ca571faf9e91d254c589b16705
add start of up/action.yml
push time in 19 days
issue commentapex/up-examples
Yeah AWS removed Python as well I think :( and with the way they chose to do layers I can't add the proxy to each Lambda runtime, so it more or less only works with Go & JS at the moment. If they exposed the runtimes as ARNs for use with layers it would be fixable but I think we're out of luck for now
comment created time in 22 days
pull request commentapex/rpc
TS: use camel case in object field names
The generated approach is what I did with validation in the Go server portion and it works pretty nicely https://github.com/apex/rpc/blob/master/generators/gotypes/gotypes.go#L155-L168.
The schemas can get pretty huge so I don't think that would be ideal, especially for the browser JS client. I guess the JS client would be another reason to consider just leaving the fields as-is (timestamp stuff still applies though), but the extra bulk isn't really worth it there just for camelcase IMO.
comment created time in a month
push eventapex/up
commit sha c5ca649cd8bf1bb12c1fbbaec72130a98b89942f
Release v1.6.2-pro
commit sha ef62b9e282bd7f58ce5299ed289ecaf02a321858
Release v1.6.2
push time in a month
startedbradfitz/shotizam
started time in a month
push eventapex/up
commit sha 3899667a65f6d700c57ea79cb22116d73fa843a7
update .goreleaser.yml to remove drawin 386
commit sha e938b6308ab88422e347c3bb645e25c0872779f2
fix Stripe dep, Go is just randomly updating them...
commit sha abecacc31209bd5984f5d16596cdeef81a8673c7
Release v1.6.0-pro
commit sha 755e08a6568eef3d3017201bec1e84f22fa36d62
Release v1.6.1-pro
push time in a month
pull request commentapex/up
change timeout through UP-TIMEOUT header. Closes #814
hmm great it's 100mb haha.. Go mod is really messing things up, I'll look into what's causing the bloat
comment created time in a month
pull request commentapex/up
change timeout through UP-TIMEOUT header. Closes #814
Just uploading v1.6.0, should be up pretty soon
comment created time in a month
created tagapex/up
Deploy infinitely scalable serverless apps, apis, and sites in seconds to AWS.
created time in a month