Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter
takeshape.io
takeshape.io
I am kind of sold on "static" sites, but why is this particular stack and set of solutions so exciting? (As opposed to using, say, Rails on Heroku (which I use as a default baseline), or even the alternative setup (Vuejs version of Gatsby -- I am sure there is one by now, and whatever competes with graphQL).
Two years ago I went with TakeShape as my publication's CMS, for two key reasons.
The first was that TS gave us a interactive visual front-end for managing content, which we could then publish as a static (i.e. pre-rendered HTML/CSS/JS files hosted on S3) website. Almost every other existing solution is built on directories full of Markdown files, which would be unusable to the rest of my team of non-technical editors and authors. I wish it weren't the case, but some people just don't want to step outside a WYSIWYG editor.
The second was that TakeShape provides a visual interface for modelling our data structures and exposing them through an API. This allowed us to figure out features and content on-the-fly, without solving for any backend problems (database maintenance, server uptime, etc.), while we test our assumptions. With the API, we can have the option to build out more complex functionality over time.
I built our site using TS's built-in static site generator, but I'm really excited to start experimenting to see if we should port our templates over to Gatsby. What I like about Gatsby is that it makes progressive enhancement much easier for static sites, and I expect it'll let us set a baseline experience with basic, static HTML functionality and then layer richer React-driven interactions on top. We've already hit against some of the limits of static in terms of our identity management and interaction, so this seems like a promising next step.
The publication, if you're interested, is https://massivesci.com
It's exciting because it's a static site and not using something like Rails? The static site approach still isn't that well known. Right now, I try to use static sites wherever I can because of their reduced complexity.
There's nothing "static" about this site. You're still querying a back-end database, you've just outsourced it to a third party. And looking at the example site, it doesn't exactly seem "simple" to me. Hell, instead of just using one (heroku) this one relies on TWO (netlify and the authors, takeshape).
This "stack" seems to be mainly being pushed by the people trying to sell the 3rd party backends.
This article is just talking about one approach to taking one’s content and assembling it into a static website. The same basic workflow one should expect when dealing with any static site generator, the only difference being in the particulars of content aggregation and the build process.
Static sites predate web apps. In fact, the first websites were purely static.
> reduced complexity
you're telling me webpack + react + node_module hell + graphql reduces complexity?
> you're telling me webpack + react + node_module hell + graphql reduces complexity?
You are using the word _complexity_ in a different sense. The complexity you are talking about is the complexity of developing and building web pages. However, once they are built they are simple static files that can be served from anywhere. As opposed to the complexity mentioned in the parent post, which is the complexity of running a typical web application that includes a backend server and likely a database. Even such plain and commonplace technology as a Wordpress installation has a higher complexity of running than a Gatsby-based site.
JAM stack development puts the complexity on the build side but pays it back on the operational aspect and performance. I have been a Ruby developer for over 10 years and I will say that React/GraphQL is indeed much easier than a full blown Rails app both operationally and development wise. Heroku is a black box that runs Rails and provides databases/load balancers to back it. Here you are pushing your generated pages to a CDN, and using them to host your GraphQL endpoints.
Isn't static sites how the web started? I feel like static sites are well known and table stakes for understanding how to build a website.
Are you equally excited about Gatsby and Jekyll(/Hugo/Pelican)?
Gatsby, Jekyll and Hugo are all in roughly the same category of static site generators.
However.
The exciting thing about Hugo is how incredibly fast it builds.
The exciting thing about Gatsby is how ridiculously pleasant it is to work with for a modern frontend developer. It has hot module replacement, built in (so you don't need to reload the page to see your changes). It has various plugins (e.g. for various CSS preprocessors, for the dev version of Netlify CMS, for image resizing, etc.), which just work. Its graphql-based data layer, which allows you to query files from the file system just as easily as data from a third-party api during page build, is beautiful. It is also insanely configurable, is written in a frontend-friendly language (JavaScript) and exposes hooks to its internals, which is a great help if you are a JavaScript developer (as opposed to Hugo, which is rather rigid and Go-based).
But this comes at a cost of about 60-kB runtime. So if your static site is not insanely interactive to justify this payload, your performance-obsessed friends will point their finger at you, and Alex Russell will tweet another facepalm emoji. Although Gatsby is trying its best to reap as many performance benefits as it possibly can by automatically splitting javascript on per-page basis, and adding link rel=preload tags to prefetch the assets before the user tries to navigate to particular pages.
As for Jekyll, I can't think of anything exciting about it.
- knows modern JS - knows ReactJS - knows webpack well - knows how to deal with node_module dependency hell - knows graphql
(Full disclosure I'm a Co-Founder of TakeShape)
Take a look at Smashing Magazine, for example. That's a static html website built with Hugo. Guess who built it? Professional frontend developers :-)
Maybe you don't need a professional for your site, or maybe you do. If you are a company that is sold on the idea of having a very fast, elegant, interactive, and yet searchable site, then maybe you do. Also, if you are a frontend developer and already have the skills, then maybe you'll like this tech for your own site (I know many frontend devs do).
In short, being able to scale to as many requests as your CDN can handle, with none of the operational overhead of a traditional web server, is really really nice.
For the e-commerce part of it, it's a custom API written in Scala that handles our inventory, warehouse, and fulfillment needs. As well as interfacing with Stripe for actual order processing. Want to get that team to write their own blog post as several people have asked about it!
Javascript APIs Markup
Coined by Matt Biilmann, Co-founder of Netlify
In other words, every single page application ever built?
Two other good options are:
And
If you want access to the beta, message the folks at support@forestry.io.
(Disclosure: I'm involved in the company, but not in a major way.)
There is a grammatical typo in the opening headline which should read 'how to use Gatsby.js ...'.
If you want to see another example of Gatsby powered by a GraphQL native CMS, check out the following tutorial: https://docs.graphcms.com/tutorials/developers/gatsby_and_gr...
It's like someone is trying to market/brand programming paradigms that otherwise would be common patterns.
He came up with the name in his living room over beers.
Neat podcast episode about the etymology here - https://www.heavybit.com/library/podcasts/jamstack-radio/ep-...