Hey, everybody. I'm starting a new little project, and I want to build it in React. I looked at Gatsby as a possible solution, but as of two days ago knew nothing about it. I stood up a site pretty quick, worked out my APIs, got authentication up and some GraphQL data flowing, all with relative ease.
I'm very much in the learning phase, and at this point I'm having some doubts as to whether or not Gatsby is the ideal situation for this.
Long story short, I want users to be able to log in and post stuff. I can see the workflow as to how it can be done, but is Gatsby a good idea for this approach? I know it's a static site generator, but how static? Will there be cache issues?
I guess my biggest question is, if I'm pulling data from an API into GraphQL and rendering a page with it... and then a user posts something new... will that data show up on the site without having to do a build?
I know I can just fetch the data... I can think of a couple of workarounds... but the larger question is, am I just using the wrong tool for the job? Or will I be okay if I continue down the Gatsby path for this type of application?
Hi Jason,
I too was very confused the first time I used Gatsby as to its strengths and weaknesses.
In my opinion, this is an anti-pattern. Gatsby is a great tool for creating websites that are static and respond to an event. I used it to create a company landing page that was rebuilt when we changed the content using a CMS.
If your website fetches data on render, it's not a good suit for Gatsby.
Hope this helps,
Jonathan
This is the static pre-rendered, vs dynamic client side js challenges - Check Ben Awad's youtube channel as there is a video where he goes through use-cases for when to use gatsby vs. next.js vs. create-react-app. Doing a search I see he's tweeted where he's combined gatsby and CRA, which I think will provide you use-case - https://twitter.com/benawad/status/1219283120622637057
Hey Jason,
I was facing the same issue, luckily
Gatsby cloud now has incremental builds, meaning the whole site won't be rebuilt.
I am trying strapi or ghost as a headless backend.
There is already an edit in place ( like medium ) starter that uses netlfiy ID and draftjs for the editor
It's called gatsby-starter-procycon.
Let me know how you solve this. I am working with a similar issue.
Hi! I used Gatsby alot and this is possible with a hybrid solution BUT as others have mentioned if you have alot of user generated content you might want to use Next.js to be able to serve the content SSR without a rebuild.
Have a look at nextjs seems a better fit.
Hey Jason, of course this is possible in Gatsby. You can check out https://www.gatsbyjs.org/docs/adding-app-and-website-functionality/. Whether Gatsby is the right tool for the job is a very subjective question though. Personally I use Gatsby when I'm pulling in content from different sources during build time. This works well for a blog. For more dynamic applications I prefer NextJS (https://nextjs.org/). If you are not planning to take advantage of server side rendering or you are looking for the simplest option, I would recommend using create-react-app to first build the app and then migrate later if needed.
Hey, thanks for the info. If you say it can be done, I'll keep on plugging.
Server-side is what I want, and the page routing is what I want. I first looked at NextJS, but it didn't exactly sing to me.
I'm open to further opinions, if anybody else has 'em.
I agree with arjun.
I've built many applications with Gatsby and Next.js over the years.
One of Gatsby's strengths is being able to pull in data and content from various APIs, CMSs, and even the file system at build time with the purpose of using it to generate static pages. A typical workflow with Gatsby is setting up some sort of automation to rebuild the site when data/content changes in a headless CMS.
The static pages are rehydrated after being rendered so it is still a React app in the end. That means you can still interact with APIs and any other interactive features you'd typically code. But if most of the data you are using is runtime then you may want to consider Next.js or CRA.
You can make an app like this work using Gatsby just fine but you're not playing to its strengths.
Awesome.
"A typical workflow with Gatsby is setting up some sort of automation to rebuild the site when data/content changes in a headless CMS."
I was thinking exactly this, and I'm glad to see it as a recommendation. If you have any links to particular workflows, I'd love to see them.
Thanks for the info and opinion. It helps tons.
Gatsby Cloud is Gatsby's own build/preview platform. It has 1st party integrations with the most popular headless CMS providers. It has a very slick workflow where changes in a CMS are almost instantly available as a preview. It also just launched incremental builds so re-builds take seconds, not minutes.
I've only played with Gatsby Cloud. I prefer hosting my stuff on Netlify or Now.sh, at least for now.
With either of those platforms, they will deploy whenever you push to a GitHub branch. This is good for data from the file system.
I've also started building a platform for list-based sites that uses Google Sheets and Gatsby. There, I use Zapier to trigger a rebuild on Netlify when the Google Spreadsheet is updated. You could use the same approach to trigger a deploy when your other data sources change.
Hey, thanks for the great advice everybody. I ended up moving from Gatsby to Next.js, and even though I was trepidatious because I had already invested some brain power in Gatsby, it was clearly the right move.
All of your kind and patient advice helped me a great deal. Thanks!