Here's an idea of how the whole thing works when you have non-technical users:
1. You need some sort of Content Management System for non-technical users to be able to create content.
2. That CMS stores the content however it sees fit (db/files/whatnot) and provides an API to fetch it.
3. In gatsby, you build "source plugins" that fetch the content and fill it in an in-memory GraphQL sever.
4. Building the site entails fetching all content, feeding it to GraphQL, making a webpack build to run in nodejs, making a webpack build to run on the final site, and finally generating the HTML files.
If this doesn't sound so bad, here are some complaints in no particular order:
- There are no incremental builds. You must rebuild everything every time you want to publish a change. Our builds currently clock in at ~8min.
They've been saying they want incremental builds since 2 years ago. They are "just around the corner" since ~6 months ago. They "already did the hard part" ~4 months ago. They "will offer incremental builds sometime in the future but only in the cloud paid-for version" as of ~1 month ago.
- Users hate not being able to immediately see how their content will look like (especially if every time they publish there's a ~10min. delay to actually being able to see it). We had to setup a "preview" environment that is running gatsby in development mode. Gatsby the company just recently started selling this as a paid cloud service (we built it ourselves).
- Development mode does not serve html files like production builds do. The site behaves differently in that mode, and some issues only happen in actual builds. When you encounter one such issue, the feedback loop becomes "full build for every change" == ~10min of waiting to try every single change. This is a HUGE productivity killer.
- Gatsby generates html files. Then it hydrates that html in the client, using ReactDOM.hydrate. Sounds cool, but the React devs explicitly stated that prerendered content must match exactly what the client-side would render, and if it doesn't your site may completely break and it won't be considered a rehydration bug.
Now consider what happens if you try to use a component that changes appearance by doing size detection, or if you have some area that changes between "Hello <user>" or "log in" depending on whether the client is logged in, etc. BTW, these bugs only happen when you test actual builds, not in development mode of course (massive waste of time as per the point above).
- Gatsby hijacks NODE_ENV (setting it to "production" for actual builds and "development" for the development mode). This leaks into the many tools involved in the many things that happen while building (babel, webpack and all of their plugins, times two compilations, plus the rendering phase, etc). For instance, I've lost many hours trying to get a full, tree-shaken but unmangled build to no avail.
- Gatsby infers GraphQL types from the data you feed into it. It usually works, but when it doesn't it is painful to discover why (your queries return weird results) and fixing it means specifying your data types manually (something you already did once when you defined the database, again to define the models in the CMS, and yet again when you specified the API Gatsby uses to fetch the contents)
- Many months ago we went with CSS Modules because Gatsby sold it as a way to get the CSS required for each page inlined in the HTML itself. Fast-forward a bit, people where having issues with specificity (because of ordering) ... and now Gatsby inlines ALL of the site's css in each and every page. Our html's usually have more inlined CSS than actual HTML!
I can assure you I'm going the next.js route if I ever have to build a site with similar technology.