Is it possible to sccafold the different Redwood layers into their own directories?

Get Help and Help Others
1

Given a monorepo similar

I’m interested in breaking apart the layers into their own different directories. Breaking up the layers but also still being able to use all the Redwood tools to create components, pages etc or deploy, serve but ONLY for that directory. Running yarn redwood generate page home / in ./apps/blog would create that page but soley in ./apps/blog. The same for any API directory.

Here’s what the directory structure looks currently

api
  db
  src
  server.config.js
  package.json

What I’m looking to do, currently, is more like the following where the layers are broken up in a monorepo

/project-root
  /libraries
    /component-library
    /deployments
  /packages
    /shared-code
    /daemon-1
    /api-1
      db
      src
      server.config.js
      package.json
    /api-1
      ... etc
    /api-2
  /serverless
    /lambda1
    /lambda2
    /lambda3
  /apps
    /todos-example
    /ecommerce
    /blog

Under ./apps would live all front ends and example websites. Under ./packages would have, for example, our business logic and other microservices. In either ./apps and ./packages would be code managed both by Redwood and other executables.

Can I … ?

My primary question is: Is it possible to generate just a Redwood web app in ./apps/todos-example but all the files are root level to that directory (ie: ./todo-example/src & /todo-example/package.json) and the same for backends. If not can I manually clean things up if needed (after running a scaffold) and Redwood would still know how to handle a root directory for either an API or WEB?

If the above is true, then when I run yarn rw generate page in ./apps/todos-example is it smart enough to know how to run within the directory?

Futher questions but enumerated

For 20% less reading!

  • Can I, or rather “How do I”, generate just the api or web layers into a directory?
    • Or can I only scaffold a full project then go delete happy?
  • Can I use yarn rw to manage any given directory?
    • If that directory is, say, an api directory is it possible to change that name are there adverse effects?
  • Can I have multiple APIs point to the same DB?
    • If so what are the best practices here? I would imagine having a single backend that handles the creation, migration & seeding and all other APIs can interact with it but do not manage the schema in any way.
  • Is there anything special that needs to be handled if I were to deploy each layer separately?
    `? Same for packages or serverless. Breaking apart the layers also allows separate builds and deploys which are required.

I’m interested in breaking apart the layers into different areas and each may be different Redwood managed directory. Breaking up the layers but also still being able to use yarn redwood as the tool to create components, pages, layouts etc but ONLY for that directory. Running yarn redwood generate page home / in ./apps/blog would create that page but soley in ./apps/blog.

1 Like
2

Hi. I did read and am trying to understand what it is you want to accomplish— and thanks for the detail.

But, one thing you did not say was — why?

Why do you want this structure and what benefits do you think it affords?

3

Basically multiple teams are working on different things and they should be deployable only when we need instead of deploying the entire project every time. The monorepo houses many different aspect when deploying a platform.

At the company that I’m at we have many front ends (each FE is it’s own product for example) so having multiple directories in ./apps is useful right off the bat. We also deploy different microservices & database updates as needed. Different web apps could both use the same microservice (db backed) and they don’t require deployment at the same time.

Keeping them separated is ideal but also it would keep my monorepo tidy whereas there is no need to have both an ./api and ./web directory for an app that is a front end. Isolating everything by layer makes it much easier to work in, essentially, atomic packages.

1 Like