I want to deploy different microservices with different entrypoints (some are web and some are api-only) but want to share the type definitions in a monorepo.
What is Redwood’s approach to this?
Codegen from the GraphQL API is probably the answer you’re looking for, as the GraphQL API from Redwood is probably the conduit between all separate services
Say I have several external REST API services I need to spin up independently of each other, but I still want to share type defs and utilities between them. What would be the Redwood approach, save from creating an entire separate repo?
That mainly depends on your deployment strategy I’m afraid, you could use docker to have them all live in one repo - redwood doesn’t really much say in that
Let me change this topic a bit to be “RW developers discussing monorepo” - since I am not so interested in knowing how was Redwood repository constructed (this would be the “redwood” way to use monorepo). I am a lot more interested in learning how RedwoodJS application developers create and manage monorepos and what was the motivation to take that approach.
Lerna was the first tool created for monorepos management and it was abandoned (mostly for performance reasons) for several months until Nx took over the subsequent Lerna evolution. My take is that Nx, combining Lerna with their proprietary features (task scheduler for example) made Lerna more difficult to adopt by the “masses”.
I believe that the Redwood core team used Yarn with Workspaces approach - technique that does not compete with Lerna, as Lerna will use Yarn’s workspaces if possible. I have tried this approach just on the surface and it seemed to me as “too low level” (a lot of manual work).
Probably the latest innovation in this area is “Turborepo” - see the discussion Folder hierarchy in packages for details on this approach.
As I am preparing for a large RedwoodJS-based application from the general domain “patient centric healthcare portal”, I would like to construct the monorepo repository benefiting from experience of smart application developers.
I am just using yarn with workspaces at the moment. In i.e. packages/myPackage I just add: "web": "workspace:web" to the package.json. And then I can import easily via web/src/..... Same goes other way around.
In tsconfig of myPackage I had to add these two lines to include:
"../../.redwood/types/includes/all-*",
"../../.redwood/types/includes/web-*"
Now I can consume typings of web for i.e. routes. I still do not have full typing on some parts ([Bug?]: Query types missing in mono repo setup · Issue #7295 · redwoodjs/redwood · GitHub), but I get along well with it so far.
1 Like
Thank you @dennemark, this is a very simple approach that clearly works. I am working on a more general solution that will allow “mixing” all kinds of packages (not just the front and back end parts of a Redwood application). In my opinion, the approach of using yarn with workspaces seems best.
Stay tuned as I believe that you will like the solution offered by https://goldstack.party/ open source project (I am working on adding RedwoodJS to their list of supported packages)