Dynamic Site with Workers
I currently have a worker which handles post requests for the root path and uses a database and a kv namespace. The context is a discord bot that handles the interactions only via webhook. Now I want to build a website for it (like a dashboard) and, since it needs to use the same bindings and data, I was thinking to use the Worker so that I can integrate everything.
I discovered Workers Sites but I see that for new projects it recommends to use Pages. I never used Pages before but obviously it wouldn't be a problem for me but now I'm unsure what to do. I've considered
- using Workers Sites to integrate everything into the existing Worker
- using Pages to host separately the Worker and the website
- using Pages to host both the website and the main POST handler (is this even possible?)
What do you suggest?
6 Replies
One man's opinion: Use pages to host the front end separate from the backend Worker. At least for now. Sounds like Workers will soon support Assets (like Sites), and that will be the way of the future (instead of Pages?).
Uhm, ok I will try that. Would be very cool to integrate everything in a single worker instead of having to use two different services (and domains) so I'll keep an eye on it, thanks a lot!
sounds like in the future Workers + Assets will be how that is done. Which will be nice. Although it's not a bad thing to think of the front end (Pages/Assets) and the Backend (Workers) in a semi-separate standpoint. Depending on the complexity of your dashboard you could also just jam the HTML into the Worker to render out for a given path request (i've done this, but it feels quite hacky).
Yeah, I thought that but I'll probably use React and maybe Next.js so I wanted a more flexible solution
yeah, just think of the FE and BE as separate and loosely coupled through the API spec:)
Ah btw, if I use Pages with, let's say, Next.js, will it be possible for me to directly access database/kv (for example in a server component) or do I need to call my Worker?