How do I test my jobs? Is there a local runtime a-la miniflare? Or do I have to deploy and then run my unit tests against your APIs?
Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
71–80 of 114 posts
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#72I don't understand how the example on this page works: https://docs.defer.run/features/delay/ Does the "defer" directory make the exports of those modules special? Because the defer function isn't called until the endpoint is hit, there's no way to really know (without static analysis, which is a can of worms) which functions will actually get deferred. Moreover, how does the defer function know, at runtime, which fu…
Here’s how our Builder works: When a commit is pushed, we fetch your application’s repository from GitHub and compile (if TypeScript) all the files in the first `defer/` folder found. Then, we require each of those files to retrieve the metadata exposed by the `defer()` helper, on the `default` export (is it a CRON function or not, a function name, concurrency, retries, etc). When a background function gets a call fr…
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#73I'm kind of perplexed by this. It's very clearly infrastructure. Putting "zero infrastructure" in the title and using the same API as Lambda invoke etc. doesn't make it true. I also get double the risk of downtime, security as it's a third party running on top of AWS vs. just running on AWS. The API looks nice - but no mention of typescript at all in this post or the website, so presumably type-safety isn't the thing…
> It's very clearly infrastructure. Putting "zero infrastructure" in the title and using the same API as Lambda invoke etc. doesn't make it true. > I also get double the risk of downtime, security as it's a third party running on top of AWS vs. just running on AWS. You are right. We provide an infrastructure service. We mean by "zero infrastructure" that you don't have to implement and/or manage your own. Our service…
To achieve type safety normally involves a shared interfaces folder and has to be specifically implemented
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#74Earlier quoted context omitted.
Here’s how our Builder works: When a commit is pushed, we fetch your application’s repository from GitHub and compile (if TypeScript) all the files in the first `defer/` folder found. Then, we require each of those files to retrieve the metadata exposed by the `defer()` helper, on the `default` export (is it a CRON function or not, a function name, concurrency, retries, etc). When a background function gets a call fr…
Oh that's cool. You should make the type safety thing clearer on your lp
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#75Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#76Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#77Is this built on top of Bull? Interesting idea.
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#78I only skimmed through the landing page so maybe I missed it, but the value proposition isn't clear to me. If you're going to `await` for the contacts import to finish anyway, what's the advantage of separating the import logic from your main API? It's blocked, so might as well be part of the same service, no? I could see maybe if the API returned right away with a pointer the user can later poll for task progress, b…
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#79Checks to see if it uses export or module.exports in the example OK, tell me more...
We support both CJS and ESM but showcase examples in ESM in our docs and landing