How to use Gatsby with Redwood in a monorepo setup?

Get Help and Help Others
1

Repost from How to use Gatsby with Redwood in a monorepo setup? · Issue #1036 · redwoodjs/redwood · GitHub

For many reasons, including static site generation, automatic image optimization and i18n, I prefer to use Gatsby for my marketing / landing pages. (on example.com)

However I definitely want to use redwood for the app itself. (on app.example.com)

So I’m wondering what’s the best setup here.

Should I just add another “side” to my redwood app and continue working with yarn workspaces?

- web
- app
- api
package.json

Or should I import the full redwood repo in a lerna configuration?

- web (gatsby)
- app (redwood)
   - api
   - webapp
   package.json
package.json

In either case, how do I deal with shared files like the tailwindcss theme etc.

Any guidance here would be greatly appreciated. Thanks

2 Likes
2

Hi @freddydumont! Thanks for starting this conversation. I do want to clarify one thing to make sure I’m on the same page — there’s a difference between integrating Redwood and Gatsby Vs. using Gatsby for your “www” and Redwood for your “app”.

Gatsby “www” + Redwood “app”

The simplest way to do this is have 2 separate projects (repos). In your deployment configuration (e.g. Netlify dashboard), you’d set the Gatsby project to deploy to something like https://mysite.com and the Redwood project to deploy to https://app.mysite.com.

And if you wanted to, you could use Lerna (on top of Yarn Workspaces) to create a Monorepo. It would require some config and setup, of course. And I might even recommend your directly structure in this case to be:

- www (gatsby)
  - gatsby folders
  - gatbsy root files
- app (redwood)
  - api/
  - web/
  - redwood root files
package.json
other monorepo/lerna config

Both Netlify and Vercel allow you to deploy multiple sites from a Monorepo.

Gatsby + Redwood integration

If you’d like to swap the Redwood Web side for Gatsby (e.g. replace the web/ files in a Redwood Project with a Gatsby project), it’s conceivably possible although you’d be the first I know of to try it. I’m very curious how it might work. Or even if it would work.

Since the Redwood API is GraphQL, you should be able to consume it with Gatsby although I’m not familiar with how Gatsby works at this level. (Note: you wouldn’t have to integrate the two for Gatsby to use a Redwood API — you could do this in the first example above as well.)

You’d need to manually handle the CLI for local dev and build with custom package.json scripts, which I don’t think would be too bad.

But you’d most likely lose Redwood generators and Cells – you could try to use the required imports for Cells but I think it would take extra config to make it work with Gatsby’s data fetching (if it even worked at all).

So I’m not sure what you’d gain in doing this other than having fully pre-rendered pages/routes across both your “www” and “app”. You’d have access to the Gatsby plugin ecosystem throughout as well. But, again, this assumes integration like this is even feasible.

Anyone else have any ideas about how, or even why, and integration could and should work?

5 Likes
3

I didn’t consider replacing the web side with Gatsby, more like adding a Gatsby side to the existing setup. Kinda like you could eventually add a react-native side.

Seems like the straightforward solution is rather to deploy to different subdomains like in your first example.

Thanks for your answer @thedavid!

2 Likes
4

Ah, makes sense. There’s the general concept of Redwood Sides (currently api/, web/) that will one day become extensible. Effectively they are yarn workspaces (which is why you can add more workspaces now, e.g. lerna example above). But there are additional concerns regarding core Redwood config/babel/webpack and CLI commands.

All possible as is. Just not convenient.

Yet.

Keep us posted!

2 Likes
5

I’ve grappled with this a few times, and IMHO, it best not to replace the web side even if you’re using Gatsby for the front end.

A very typical setup would probably be:
A. gatsby for landing page, FAQs, contact pages, privacy policies etc.
B. Redwood for the actual app, where most of the pages are dynamic
C. Gatsby can pull data from RW using graphql where required

My reasoning for this is simple - Gatsby excels at certain things - i.e. static-ish content. Redwood excels at others i.e. dev experience and dynamic data driven apps. If you only need one of these things, and and not the other, probably best to stick to the tool that’s best for the job.

To each their own though, and please do post here if you find a better way, would be more than happy to be proven wrong here!

2 Likes
6

I tried to make it work with a few different approaches, but the best is to stick to redwood for the whole stack.

In the end, the benefits of Gatsby aren’t worth the hassle of maintaining two different frameworks. What I miss the most is automatic image optimization though. Not sure how to do that in a SPA.

3 Likes
7

Some good news potentially @freddydumont - I can’t say I’ve tested it thoroughly or anything, but I think netlify will automatically optimise images for you (its in the post processing section).

Alternatively worth a look into https://github.com/webpack-contrib/image-minimizer-webpack-plugin

Webpack is powerful but can be super annoying. Here’s another thread (for a completely unrelated problem) where I walked through adding to the existing RW webpack config CORS issues when developing locally against a separate API server

1 Like
8

@danny @freddydumont I think image optimization is definitely worth a discussion regarding Performance and the Redwood roadmap. Might be worth organizing research/ideas in a GH Issue.

No pressure and mostly thinking out loud.

2 Likes
9

@freddydumont FYI Danny is going to demo NextJS + Redwood API at tomorrow’s Meetup:

10

Yes :raised_hands:, image optimisation is also one of the features which drives me to look up a solution for integrating Gatsby with Redwood.

Another feature from Gatsby which could improve the web client performance is the prefetching the links with low priority in the view. Pre-rendering is first class in Gatsby too.

Rich plugin library (2000+ of plugins), recipes and starter library in the Gatsby ecosystem which could further bootstrap the web side of things. Hence it need not reinvent the wheel in Redwood.

I think it would be superb if Redwood integrates Gatsby for the web side. :heart_eyes: Though I have no idea how easy or complicated the integration process would be, or whether Gatsby philosophy fits with Redwood, I’m just throwing my ideas out. Hopefully, both Gatsby and Redwood community could make this integration happen. Or even better, make it first class in Redwood. :100: :star_struck:

I’ve just started exploring Redwood yesterday, but I’ve already fallen deeply in love because of how fast and easy to use it. The documentation is superb, I love the additional explanations of the reason for the decision made in the right context and concise manner. I also love Redwood for the generators, GraphQL, Prisma, cells, name route, and opinionated structure of the file structures, so that I can focus on the content rather than dealing with bikeshedding and the complexity of selecting and integrating the right libraries.

2 Likes
11

Hi @andrewlamyw! Welcome to Redwood. We’re excited to have you aboard :rocket:

You’re correct that there’s a lot more nuance under the hood regarding “Redwood integrating Gatsby for the web side”. BUT don’t let that stop you from experimenting and dropping into the community for both help along the way and sharing the things you learn.

Couple quick thoughts:

  • image optimization has come a long way and is often depending on the service you’re using for assets. @rob did some work on this in the Example Blog which uses Filestack
  • Prerending is on our radar for sure!
  • I also think Gatsby’s plugin ecosystem is super cool. But it’s also often a WebOfPain™ :rofl: There’s a lot of existing React packages on NPM you’ll find to do what you’re looking for and they all just work with Redwood because Redwood is just React. One reason for the abundance of Gatsby-specific plugins is that is super complicated under the hood. (My opinions of course. And mostly to just say the NPM Ecosystem > Gatsby Plugin Ecosystem)
  • DX (developer experience) > optionality. The things you :heart: about Redwood are there because of specific, hard choices which often have constraints. But our belief is that DX over time is what increases happiness and performance the most. But we’ll need people like you to help validate whether we’re correct and on the right path!

All that said, thanks for sharing your enthusiasm. And please do keep passing along the :fire:

2 Likes
12

I wanted to add a sister package to my redwood app, and my search led me to this thread. In case anyone is reading this who normally uses Lerna, you should know you can just use yarn workspaces now and it works well with the existing redwood setup. I’ll post my details here in case it helps others.

root package.json. Add your new package (eg. "contracts’) to the Workspaces list.

{
  "private": true,
  "workspaces": {
    "packages": [
      "api",
      "web",
      "contracts"
    ]
  },
  "devDependencies": {
    "@redwoodjs/core": "^0.20.0"
  },
  "eslintConfig": {
    "extends": "@redwoodjs/eslint-config"
  },
  "engines": {
    "node": ">=12",
    "yarn": ">=1.15"
  }
}

Remove lerna config, since yarn workspaces satisfies my needs.

Then in web I can install my new package normally. Note if you have issues installing try adding the version eg. yarn add emanator-contracts@1.0.0

  "dependencies": {
    "emanator-contracts": "1.0.0",
  }

Full repo can be found https://github.com/emaNaFTe/monorepo

2 Likes
13

I’ve used Gatsby. I like it.
But my question is this: Why not use Redwood for the landing pages? Is there a particular reason why not to?

Image optimization is a good example, but let’s suppose that images are optimized.

Can the whole app be created with Redwood? Let’s say:

A “marketing” area brings data in from some headlessCMS and the other area of the app is totally run by Redwood. Can Redwood do that? Bring in data from other external sources? Seems like Redwood might do the whole thing.

Just curious.

14

One of the main features which make a Gatsby site :rocket: is pre-rendering.

Which mean the data could be pulled from data storage (e.g. CMS) at build time rather than runtime. Hence reduce the time to load the contents of the website.

Furthermore, a pre-rendered site also leads to better SEO.

And they’re also focus on the accessibility part.

15

Prerender is coming to Redwood :rocket:

2 Likes
16

Curious if anyone has actually setup a mono-repo with redwood in the mix and the details of doing so?

It seems like @thedavid’s original suggestion of the folder structure makes sense, though I think this means I can’t use yarn workspaces at the root of the directory unless I collapse the who of redwood into a “app” workspace I think. The app sub-dir would work well with netlify specifying a “base directory”

The other thing I was curious about is if it’s a monorepo, why not treat /api and /web as seperate, i.e. don’t re-build the api if there are only changes to the web directory? (this would also be easier to just add a third workspace to the original setup). On second thought, this probably won’t work since “sites” on netlify are different urls, so I don’t think you could publish the web and api to the same url, yeah I’m not sure how to approach this. My use-case is wanting to publish docs on on a docs subdomain. Plus I don’t think would work with specifying base-directory on netlify, as in making one site with a root directory and another with /docs as the base directly sounds like it wouldn’t work as the I would assume the root directory would change with changes to /docs still.

Maybe I should make a dumby site to experiment with this.

17

Would /docs be a Gatsby project? If so, I think it might work just fine to have that directory in your project repo — just don’t try to manage it as a yarn workspace.

18

It will be a docusaurus project, but effectively the same. Just a static website.

Yeah I think you’re right. Workspaces is over-complicating things for something like this.

19

Yeah, you should be able to make this work just fine and skip the integration with yarn workspaces. You’ll likely need to add another step to the build command and/or create a script that does what you need + yarn rw deploy ...

FWIW, if you really wanted to get fancy, you could build the Docusaurus static files and put them in web/public/docs (or something), which would effectively use a subdomain like your-domain.com/docs

20

Bit of follow up. I’ve got the docs up just on a subdomain learn.cadhub.xyz far from complete, but I do have one end to end tutorial for OpenSCAD.

as an aside, I’m not doing docusauros build && yarn rw deploy I’ve tried to setup netlify’s monorepo stuff where each project has a base directory. It’s supposed to only build the project that has changes, but so far I’m having trouble with it and end up triggering builds myself. Still need to look at the docs again to figure out what I’m doing wrong. :man_shrugging: