I know it is mentionned that redwood is planning to support “sides”. Is it public RFC, discussion or detailed roadmap somewhere about that? If not where is the best place to start a discussion please ?
Needs / Use cases :
setting multiple clients (#1487)
setting different targets (electron, capacitor…)
setting shared packages, for example : schema validation (client/api, #7618, #6948) or Ui, types, graphql (client/client)
ability to scaffold only client side
Motivation :
To me this architecture issue is crucial because i’m looking for a tech for the next project of my client and Redwood seems to tick all the boxes but i can’t afford being stuck when the project scales and my client ask for other clients. Ofc you can hack things like i did for schema validation with zod… well not reassuring…
I am very interested in having this capability. A cursory dive into the code this evening brought up a few major roadblocks to how this would be handled if its something that was even worth working on right now given the potential changes that could come with RSC support.
Hard coded references to web and api. The biggest offender I found was the rw upgrade command which would have to dynamically look for additional web modules, likely by ingesting the redwood.toml and finding all web projects from there.
Disambiguation on commands that target web. All your generate, destroy, setup, etc. commands would have to have a flag or optional field added that would allow targeting specific web modules, or if multiple exist we could potentially require running the command from within the workspace of the web module you’re targeting.
Developing. Developing with multiple front end requires binding additional ports, which we could just read from the toml, but having a sane fallback strategy would also be nice. Serving should require a relatively minor lift of not hard-coding the options.
Deploying. Deploying is a whole bugbear of a problem. Figuring out how to build either all sides, each side individually, or a vertical slice of each web side paired with the common api side, and handling that across each supported deployment target is likely the biggest lift of such an effort.
Re: Number 4:
My intuition says that allowing a side to be targeted in the deploy command and a “traditional” redwood dist being built off that and deployed is the easiest path there. In Vercel you could target the same repo with multiple deploys, and override the deploy command to target the specific web side you want to package up with the UI. There is some concern about race conditions with migrations there but nothing that couldn’t be worked around. Looking through the code, baremetal seems like the scariest deploy to get this working around.
IMO it’s not very good right now, as you analyzed.
We also have a mono repo at work where we resorted to having two redwood projects next to each other as we wanted two backends and two frontends, but share stuff between them. They can’t find each other in production, so there’s not much to reuse at that point in time.
I do believe the people currently working on Redwood’s RSC capabilities are rethinking the repo structure and build system for many of the reasons you outlined.
I’ll ask @Danny and @Tobbe to perhaps give a preview of their thinking.
I’m letting @danny take lead on these changes for now. But from our discussions so far it seems to make the most sense to not require an API side at all for a fresh RW project in a RSC world. And when one is required it probably makes sense to just enable it in the web server that’s already serving the initial SSR Stream and subsequent RSC responses.
We’re probably going to focus on serverful deploy options first, like Fly. And then look at Netlify and Vercel later. Deploys will be a big lift, as you noted @asdfjackal.