Multiple clients with the same server?


is it a way to make multiple client in a redwood app please ? For example how should i proceed if i want to make a chrome plugin, a mobile app (electron) and a web site which all share the same server and my react custom components ? Is redwood can handle this ?

1 Like

I have a similar question more focused on the auth side of things. I’m making a redwood js that needs to auth with a CLI and chrome extension i am making

Tbh i digged a bit in the sources to make validation process shared between api and web. What i can tell is that all the build process is pretty embedded. I don’t know an easy way to make different build target at the moment. But i don’t know these tools very well (vite, webpack, yarn etc.) I’m coming from Angular and NX and building is pretty different (even if webpack is in the stack). However as the API is totlaly separated from the FrontEnd in Redwood, it seems possible to connect any client to it (with GraphQL only) … but how to make it shares sources with the current project is pretty obscure to me. I won’t have time to dig more sadly. I feel like redwood has some potential about how it wires things together but these last days when i got stuck i couldn’t really get any help from anybody and i felt it pretty discouraging. So i think i will try on more mature projects with more active community.

Per the official README, the intent of the framework is to enable multiple frontends:

You’ll notice that the web side is called “web” and not “frontend”. This is because Redwood conceives of a world where you may have other sides like “mobile”, “desktop”, “cli”, etc., all consuming the same GraphQL API and living in the same monorepo.

Perhaps you could leverage serverless functions to provide access to the backend from various interfaces (which would each have their own directory inside the monorepo).

1 Like

Sides sound like an excellent idea, but I don’t think it’s progressing.

Hitting a backend function sounds like a nice idea and there is some documentation around hitting them with authenticated users, but it requires a cookie to go along for the ride so this is only going to work if the request is coming from you redwood website

I am building a tool that will need a CLI and a Chrome extension

I am going to get around the CLI with some kind of unique access token setup and hit a custom function (how i would love to hit my gql endpoint.) but have no idea how to deal with the Chrome extension.

It may be that I have to leave dbAUth behind and look at clerk and try and make that work somehow. Not the outcome I want.

@growms Stick around for a bit. The community is usually reasonably active, I think the core team may have been a bit busy with the conference.

1 Like

At the moment it’s not done, in addition the idea of having these sides is nice but lack the “share” side. If you dig in the type generator or scaffold, nothing is done for separated web and api. In addition “web” path is hardcoded so if you need 2 web app like an admin and a portal, you can’t. I’ll open a new thread because i think it’s a more wide problem.