You could do this, but why not just run the API from within Astro?
You could do this, but why not just run the API from within Astro?
Fi like to have things seperated, because Astro is just a simple PoC but the backend is already bigger than I thought. I will probably switch UI Framework (next or smth like that) in the future
Fand with two seperate "projects" I am not limited to a specific ui framework
HYou can isolate the backend into a different package, then have a simple shim within Astro that passes the request into the backend
HThen you can keep them separate, but within the same app
HAnd the backend is always in sync with the frontend
Fim already using rfc (from hono) to have end to end safety, so its always in sync. but Ive never worked with a shim.
Fi was just curios if this setup works correcly, thanks for the input 
Fahhh another "bonus point" with my current setup is that its easier to interact with Cloudflare Bindings (especially D1). I really did not enjoy how astro handles bindings...
Fand Astro does not support service bindings in the
@astrojs/cloudflareIf you are willing to get a little jiggy, you could probably make your “Worker” call Astro instead?
HBut yeah, this seems more complex
Bis the
environmentsjust out of curiosity, when I call
fetch(/api)
HNot really. Pages uses branches, though you can only define explicit environments for “production”, and “everything else”
Bhow do i configure different d1 databases in my wrangler.toml for my pages
Bthats all im trying tp do
HNot sure, actually. Might be a case of “try it and find out”
HFor dev, or when deployed?
Bboth
Bi believe for local it only uses a local sqlite database for some reason (since d1 cant be used locally)
Bim on
next-on-pagesIf im not mistaken I already tried that out a bit ago, and got 404 all over the board... then I had to deploy my worker under a new subdomain (like api.dashboard.mydomain.com)... but Astro (and wrangler) received a lot of updates... xd
Fbut I really hate that setup xd. I like isolation (per process / page).
HYou can use the wrangler.toml for local, but I don’t think that supports environments. As for the deployed version, that has to be configured via the dash
Blel
HDid you deploy it as a route, or as a Custom Domain?
Bwell i guess i can pass in
--d1--kvfirst as a route really like dashboard.mydomain.com/api and secondly as custom domain api.dashboard.mydomain.com
The astro page is always under custom domain (dashboard.mydomain.com)
The astro page is always under custom domain (dashboard.mydomain.com)
HThat’s probably the easiest, though it looks kind of ugly
HPut it in your package.json scripts so you don’t have to remember
Bim eating spaghetti with mushrooms right now its delicious
Boops.. wrong dm
HDo you see requests in the tail logs for the Worker?
Fim jealous xd
HDamn, making me hungry now…
Fas I said, I tried that really long ago (proably 8+ months ago) and just wanted to ask before I go all in in that direction aswell. I can come back if I did some tests
Fsorry for pinging you / answering. But ive just spent time deploying everything (or making a good staging environment, with Zero Trust, etc -- the basics). But a request from dashboard.mydomain.com/ping to dashboard.mydomain.com/api/v1/ping does not work (it just returns 404 and the tail does not see the request registered). I dug a bit deeper and do I have to exclude / include a specific route in the _routes.json that is generated by astro?
Left backend (worker) right frontend (pages)
Left backend (worker) right frontend (pages)
Fis there a way to explicity tell the page that some routes should NOT be handled by the page itself because something else is taking care of it (in that case the worker) ?
Fwhen using
I'll try with absolute url
exlude: ["/api/*"](log) TypeError: Fetch API cannot load: /api/v1/pingI'll try with absolute url
HIf the Worker is being called at all, then it should be called before Pages
Fin the screenshot you can see that it is not called at all, because the pages tail has the api/v1/ping call
HYeah, so something else is happening. What is the route for your Worker?
FFand the Page has a custom domain pointing to
dashboard.ruxiom.devabsolute url with excluding does not work...
S
Scould someone help? I'v trying to upload strapi.
Son localhost its works but unfortunetly there not.
Fthe wierd thing is that a normal request (from bruno, local, or the browser itself) succeedes. only the sort of "subrequest" to an worker route from a cloudflare page is not working as expected (or by design)
Fok I was able to finally sort it out. But this seems like a super hacky workaround, there has to be a way to do without my current doings..... (worker sites had the exact use-case I am looking for right now).
Basically in Astro I created an
The content is pretty simple:
As you can see I had to add an additional Service Auth Include Rule in our Zero Trust Dashboard, without it I get the error that I am not allowed to view that endpoint.
This seems absolutely ridicoulus, it really does...
Basically in Astro I created an
/api/[...request].jspagesThe content is pretty simple:
As you can see I had to add an additional Service Auth Include Rule in our Zero Trust Dashboard, without it I get the error that I am not allowed to view that endpoint.
This seems absolutely ridicoulus, it really does...
