Server Side Rendering, Static Sites, and GraphQL
Understanding the Trends
Back in October of 2016, Zeit released Next.js and introduced React developers to an easy way to create a site with Server Side Rendering. For those not keeping up, the industry has for a few years now been moving from client side rendering, to the elusive Universal or Isomorphic web app. While everyone describes these things a little differently as they keep evolving, a universal web app typically blends the initial speed performance and SEO advantages of rendering from a server, with the performance advantages gained after initial load with client side rendered apps.
To further complicate the issue, recently Progressive Web Apps have been gaining prominence with the GoogleIO and the creation of this site comparing implementations of hackernews, as well as new production sites like twitter lite. The most important point to know about PWA’s, is that they attempt to like act like a mobile app and optimize data usage and performance for primarily developing markets. For this blog I’m going to be focusing on server side rendering vs static sites, but know that a lot of the concerns for these technologies overlap and that the goals of all these technologies are converging.
Static vs Server Side
I’ve touched on this previously, but of course the main advantage to a static site, is that there is no server at all. This means faster performance, less cost to host, and no security issues. Effectively, a static site will always beat out one with a server as shown in this comparison blog post here.
However, having a completely static site also comes with limits. Obviously complex webapps are going to need a database that is quickly growing and changing. While it is possible to create a static site which has a database and continuously update itself via webhooks (I’ll show exactly how in another blog), it has to rebuild the entire site every time which is obviously not practical for a complex webapp.
Why GraphQL RIght Now
GraphQL is a technology invented by Facebook that has been around for kind of a long time (2015) but has just been picking up steam in the last year. There are many places to find why people are using GraphQL over REST, but the gist of it is that you can query exactly what you want from the frontend, and not have to worry about anything else. I strongly recommend reading more about GraphQL here, or on the promotional sites of any of the tools I list below.
The reason why you should use GraphQl now however, is that just recently the stars are aligning and all tools surrounding the technology are ready at the same time.
- Apollo: The client used to interface with GraphQL. Much simpler than Relay and well supported.
- GraphCool: BaaS that takes care of all server side coding, just like firebase. The difference is unlike firebase, you are not locked in and at any time can take your data and scheme with you and write your own backend.
- Next/Nuxt: I’ll talk about these technologies a lot more in a second, but they are basically simple ways to make server side/ static apps. What is exciting however, is that great boilerplates are coming together showing Next.js in use with GraphQL, as well as official support integrating GraphQl into Nuxt.js.
- GraphCMS: Simple solution to integrate a CMS into your GraphQL webapp.
Server Side Rendered/ Static Apps with GraphQL
While doing this on your own is entirely possible with React and Vue, it’s kind of a pain. Luckey there are two well supported and amazing tools for both React (Next.js) and Vue (Nuxt.js)! Both of these tools can also directly export your web app into a static site. If you’re using an updating database this will obviously break your site, but otherwise transferring is completely painless. The great thing about these libraries is that they are small modifications to two well supported and loved frameworks, and abstract away most of the difficult decisions when working with advanced React or Vue Applications.
To integrate GraphQL with Next.js, an excellent boilerplate exists, and to integrate GraphQL with Nuxt, you can use the official example. Having implemented both of these solutions, I will say that I found the Nuxt integration with GraphQL to be infinitely easier and more straightforward. With the module system, the creators of Nuxt abstract a lot of the boilerplate that is required in the Next/ React version.
Is this worth the trouble?
100% yes. As a sole developer I now have a safe firebase alternative backend that I can pull out of at any time (this alone is worth it), all the benefits of server side rendering, and the ability to create a static site whenever I want. This means I don’t have to mess with Static Site Generators, Wordpress, Ecommerce backends, or any databse/ server code. I can code everything up in the framework that I’m used to, and hook everything together with a far simpler and more efficient API system. Exciting times to be a web developer.