Gatsby: SSR content dependent on origin

[zslabs]

Summary

Gatsby does an amazing job of SSR wherever possible, but with how my app works (currently all Node/Express) is I serve the root path different content based on where the origin domain is pointing; since I allow customers to map their "listings" to a custom domain; which points to the same server, and ultimately shows their content instead of the default marketing homepage I setup. Would Gatsby be able to handle these dynamic index pages, serve up the correct content, but at the same time -- still take advantage of SSR? I know I could hook up the componentWillMount() to an API call to grab the relevant content and then ultimately render either my marketing component or the listing, but since that'd be done client-side at that point, wouldn't my SEO suffer?

Environment (if relevant)

Node
Express
Nunjucks (current templating language)

[sidharthachatterjee]

Hello @zslabs

Would Gatsby be able to handle these dynamic index pages, serve up the correct content, but at the same time -- still take advantage of SSR?

Since Gatsby builds to static assets and doesn't handle serving them, _serving the right content_ would need to be handled outside of gatsby.

You should be able to run multiple builds (one for each origin) and serve the right one from Express.

[zslabs]

Really appreciate the response! Since I’d be building the site with an external DB (MongoDB in this case) I’m wondering if Gatsby would even be the right tool.

Having all the built-ins is amazing, and makes exposing a React app to the world much more approachable. But, since the builds of some of my Gatsby sites take 2-3 minutes, I’m wondering what that perception would look like to customers that save their changes in a dashboard, and then need to wait several minutes for their changes to actually “be live” compared to other services (and the current implementation) that is instant since it’s a direct serve from Express.

Are there any strategies or examples of how others using Gatsby for a full-blow app would get around the build times? I’d like to use it for the marketing site, dashboard, and front end app, but wondering if that’s where things might get too tricky.

[zslabs]

Does Gatsby support custom server routing like Next.js? https://nextjs.org/docs/#custom-server-and-routing

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[DSchau]

@zslabs the analogy to custom server routing would be client-only routes.

To address your specific question(s):

But, since the builds of some of my Gatsby sites take 2-3 minutes, I’m wondering what that perception would look like to customers that save their changes in a dashboard, and then need to wait several minutes for their changes to actually “be live” compared to other services (and the current implementation) that is instant since it’s a direct serve from Express.

I think you'd be surprised how OK people are with this. _If_ this is not the case and you find that a re-build is an unnecessary barrier to using a tool like Gatsby, you can certainly then approach with a new solution. Specifically, you could use a combination of client-only routes and a direct connection to the (MongoDB) database which will then allow for dynamically edited/updated content.

There can be a performance hit (and drawbacks, e.g. SEO) when sourcing dynamic data, so we generally recommend the full re-build route, but Gatsby is flexible enough that you can solve the problem in a variety of different ways.

Are there any strategies or examples of how others using Gatsby for a full-blow app would get around the build times? I’d like to use it for the marketing site, dashboard, and front end app, but wondering if that’s where things might get too tricky.

We'll have more on this front soon. As you note, there are a _ton_ of benefits of the unified approach, and as I mentioned I think these obstacles are certainly not insurmountable. You may want to check out the Flamingo Case Study to see an example of a company use Gatsby for various areas and for a dynamic, web-app.

Going to close this as answered, but please feel free to reply if we can help further!

Thanks for using Gatsby! 💜

[zslabs]

Thanks @DSchau really appreciate the thorough response!