You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the ctx object is basically { ...context, ...env, ...ctx } where context is the response from CTX.fetch() and ctx is the arg on the fetch with waitUntil ...
and as a pre-requisite of this we need to get api being dynamically generated in ctx.do ... as well as user ... and if a Response is returned then you can override the default response ... but basically it outputs as json({ api, ...ret, user }) where ret is the response from the method (not being a Response or an Exception)
Additionally ... we can add hostname filters in addition to pathname routing:
Then ... I'm thinking we can use workers.do to deploy every build to it's on commit-specific deploy on Workers for SaaS
but ... we can also generate a worker.js in a GitHub action where we dynamically do all of the boilerplate ...
we then don't need ANY IMPORTS
and it could Build in GitHub actions (with no yarn) and Deploy on Cloudflare in 5-10s end to end
we can also support the import if you want ... but if you create an api.js and
then we just need to get cname.do going ... we can tie any domain in that to any worker including dynamic dispatch workers with workers.do and if you don't return a response, we could soft merge the api and user objects so you could set or override properties ...
But we should also support an even more concise syntax:
and
the interface is basically routes as the keys under api where the method interface is:
but you should also be able to respond with any object and it creates a JSON serialized response in:
and if there is an exception it should respond with:
the ctx object is basically { ...context, ...env, ...ctx } where context is the response from CTX.fetch() and ctx is the arg on the fetch with waitUntil ...
and as a pre-requisite of this we need to get api being dynamically generated in ctx.do ... as well as user ... and if a Response is returned then you can override the default response ... but basically it outputs as
json({ api, ...ret, user })
whereret
is the response from the method (not being aResponse
or anException
)Additionally ... we can add hostname filters in addition to pathname routing:
Then ... I'm thinking we can use workers.do to deploy every build to it's on commit-specific deploy on Workers for SaaS
but ... we can also generate a worker.js in a GitHub action where we dynamically do all of the boilerplate ...
we then don't need ANY IMPORTS
and it could Build in GitHub actions (with no yarn) and Deploy on Cloudflare in 5-10s end to end
we can also support the import if you want ... but if you create an api.js and
or call it whatever you want ... maybe even specify it as a custom domain ... then it's a file called
demo.apis.do.js
then we just need to get cname.do going ... we can tie any domain in that to any worker including dynamic dispatch workers with workers.do and if you don't return a response, we could soft merge the api and user objects so you could set or override properties ...
The text was updated successfully, but these errors were encountered: