How to use Gatsby with Redwood in a monorepo setup?

Repost from https://github.com/redwoodjs/redwood/issues/1036

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

1 Like

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

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

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

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

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

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

@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

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

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

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:

1 Like

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

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.

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.