I would not recommend to use Gatsby in a project if it requires a frontend with complexity beyond static-scrollable content.
Some problems that I found after some months of integrating it with an existing CMS:
* Development complexity: depending if Gatsby is run on development or production mode, React's `render` methods are called in the browser or inside NodeJS.
Having this code executed in a Node process is expected because Gatsby is a static site generator, but this big split between the environment of development and production builds, paired with a growing codebase that keeps evolving, catches new developers on our team with multiple and surprising bugs.
* Debug complexity: JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode.
* Runtime requirements: as far as I remember, executing `gatsby build` on my development machine uses ~3.4 GiB of private RAM for the main node process, and it takes around 5 minutes if the local cache is cleared (it ends in around a minute with cache).
Its important to remember this when choosing in which server the build runs.
* Integration: Gatsby does not provide out of the box integration with CMS for content authoring (like for example, page drafts).
Now to be honest, the global idea seems good (static websites built with React), but I would wait a few more years until it becomes more mature to use it again for any future project.