Earlier this year I started using Nextjs more and more for developing small web apps. I initially wanted to use Gatsby, because I love it but wasn't able to because I needed authentication and dynamic routes.
You can't do that with Gatbsy...
me being an idiot, 2k19
That is when I read the "Adding App and Website Functionality" and "Building a Site with Authentication" pages on the Gatsby documentation. And oh BOY did it change my view of Gatsby!
Something finally clicked; Gatsby is just react. 🤯 I know right, what a mind-blowing statement. Obviously I knew that Gatsby sites are built with React etc, but I was fixated on the Gatsby way of building sites. Installing a source plugin, creating a createPages loop to render some pages and throw it up on Netlify. However, when I started thinking of it as Create React App with more bells and whistles, anything and everything was possible.
The first thing I did was add Firebase authentication to a site. Now, I am not going to go through any specifics since there is a great tutorial by Auth0 which I used as a base. The basic idea is;
- Create a "private" page.
/pages/app.js. - Tell Gatsby to render any pages with a slug of
/app/*to that page. - Add Reach Router or React Router routes to the
app.jspage. - Create all your auth methods. Login/Signup, log out, getCurrentUser etc
At this point, I slightly changed my approach from the Auth0 article. I added AppContext using the React Context API. Which kept track of the auth state. I also created a Protected Higher-Order Component to wrap my private routes in. On load, it would check the auth state and either allow the user on the page or redirect them back to the login page.
PRETTY FREAKING COOL!
Now you might be thinking.
Why is this cool
You, maybe... 2k??
Lets talk about it
You can add preview functionality. This is solved with Gatsby Cloud, but we are developers, reinvent everything again. You'd create a pages/preview.js page and once an author is logged in, you can display all the draft posts by requesting them from your data source. Then you can route to /preview/:id, which can then display the content of the page using the same template as the public page. This will require a bit of morphing of data but it will be worth it, eventually.
Ecommerce. Provide an account to your customers to see past purchases or to see exclusive deals.
PAAS. Build out your public site using the usual Gatsby formula and provide potential customers with a quick process between discovery and conversion. Then the app part of your site can use the pages/app.js method described above.
Just think about it this way. Whatever you have built in React before, you can build it with Gatsby. The only difference, you can provide a super-fast, SEO friendly, experience to your customers to convert them quickly. Then use whatever backend or microservice architecture you want.
Hopefully my rambling helped you give Gatsby another chance if you thought that it was too restrictive and couldn't be used to build large scale applications.
Top comments (4)
I strongly disagree that Gatsby is right for even most react projects.
Gatsby is fantastic if your sites main focus is content. Blogs, shops, forums, etc.
But any app that wants to provide a service, or some kind of complicated functionality will require either a lot of hacks on the developer end or poor UX.
Let’s say you were making a todo list with Gatsby where you save TODOs between sessions on a server somewhere. With Gatsby you’d have ur todo page template slug then during every page load you’d need to make a 2nd request (after the initial GET request) to a server to load up that user’s TODOs.
This mean the site would either load initially with no content THEN have the content flash in OR the page renders a spinner initially which is bad UX.
That’s the advantage you get with per request SSR. You can read a cookie at request time then render the whole page, TODOs included.
Honestly since Nextjs added smart static rendering at build time, I don’t really see a great story for using Gatsby unless you’re hooking into another CMS.
I agree with you that Gatsby is good for content-heavy websites. I mentioned in another comment that if your site has primarily private routes (which is what your TODO example would have since it would be user-based) then Gatsby wouldn't be a good choice and an SSR solution would work better.
However, if you have a content-heavy site with some private route functionality needed, then this approach would definitely work. I threw the PAAS idea into my article as a possibility but you'd probably be trying to do too much.
As for the bad UX around the spinner. I'd argue that if you have a Nextjs app, you'll either have a longer load time (initial load) or use something like nprogress (on page change) while the site finishes loading its data, which could also result in a bad UX experience. With Gatsby, you'll be able to, on-page change, also use nprogress or skeleton content loaders. You'd be able to give the same "loading" experience on both Gatsby and Next (without that much hacking, if any).
With both Gatsby and Next, your page change experience will depend on your API performance, network speed, and the effort you put in to indicate something is processing. As with any app/website, the effort you put into your UX will determine the quality, not the framework you use.
I love both Gatsby and Next, and I definitely agree with you that there are a time and place with both. Definitely depends on the type of website you are trying to build.
Wait, Wat ?
Good point, but... Why twisting Gatsby to do what a 'regular react app' do with ease ?
Sorry, I don't get it 🤔
If you have a app that only has private routes then this approach is overkill.
Although it really isn't that different to a 'regular react app'. You'll still be using a client side routing solution, you'll still need a auth service and you'll still be populating data from an API.
Where this becomes really powerful is when you have a client with, for example, a WordPress site and Shopify. You can then use these two sources to generate a static site with both the shops items and general content. The site will be super fast and SEO friendly. Then you can utilise Shopify' services to process the purchases etc. Also if they have protected content on WordPress, you can use WordPress as the auth service to serve the private content to the users.
This definitely has a specific use case and probably won't suit every project.