Why Gatsby and Vercel is a fantastic choice for a lot of projects

There are a million ways to build a site

Almost everyone has their preferred stack when it comes to building websites. That’s especially true if you’ve been in this game for a while. Trying to convince you why you should use one tech over the other is a waste of time. Instead, I will try to tell you what problems Gatsby and Vercel have solved for us with minimal effort from our side.

I often get amazed at how people can stitch up amazing apps and services without writing a single line of code by utilizing various no-code solutions like Wix, Weebly, Zappier, hosted forms, widgets, etc. I honestly have never tried to go that way partially because I don’t know anything about them and partially because I enjoy building things with code.

But more and more I’m starting to realize the importance of just getting things done as opposed to having fun doing it, which is actually a common trap software engineers tend to fall in. The cool thing about Gatsby is that it allows us to do both, so you can continue being trapped in the fun zone if you really want to.

Gatsby is efficiency

Gatsby, like the no-code solutions, almost feels like cheating at times, due to its vast plugin ecosystem. From the developer’s standpoint of view all you have to do is to npm install your plugin, include it into the Gatsby config, along with any relevant settings, and you are ready to start using it. Yes, this is not “point and click”, but it’s damn close, and still lets you feel like a real programmer.

But the plugins are actually just a small part of what makes Gatsby so appealing. If you haven’t heard yet, Gatsby is a static site generator. And if you know anything about static site generators then you know that they usually produce very performant pages due to, well, being static and as such no need for a backend. Assets produced by static site generators can be served through something like S3 and its delivery further optimized with a global CDN network.

What differentiates Gatsby from many static site generators is the technologies it’s built upon, namely React, GraphQL and Webpack. It’s a fair question to ask how would one use GraphQL in a static site, and the answer is, during the build phase. Gatsby exposes any data that you need during the build through various data connectors that are available as plugins. The data itself can live anywhere. It could be a MySQL database hosted somewhere on the internet, it could be markdown files right in the same repo, it could be inventory from a Shopify store, or it could be your recent tweets, the possibilities here are endless.

All of these connectors expose the data through GraphQL. Essentially, your Gatsby pages describe the data they need in the form of GraphQL queries and then use that data to build up the page. All of this happens during the build, and by the time Gatsby gives out the HTML assets they already contain all the data you need, presented in the markup you defined. You could of course make XHR requests to fetch more data but it would defeat the purpose of Gatsby as a static site generator.

Gatsby is dynamic

So as you can see, being a static site does not mean you cannot have dynamic content. The only thing it really means is that all your content was pre-built, or even pre-rendered if you wish, before sent to the client. Obviously, this might not scale for very dynamic sites that have tens of thousands of pages or where content changes constantly. But for landing pages, company websites, e-commerce with under a thousand products, and many other use cases it is a fantastic choice.

Some parts of your site that need to be very dynamic, say a shopping cart or a checkout page can still utilize standard AJAX techniques to communicate with a web server or a third party service. Nowadays, in the times of headless e-commerce and headless CMS platforms, there many different hosted SaaS solutions that expose APIs which can help you with accomplishing pretty much any task you need without you having to worry about a backend at all. That combined with Gatsby can really accelerate your time to production and simplify maintenance.

Now the other two parts of Gatsby stack, namely React and Webpack, are of course nothing groundbreaking, however, what they provide is quite compelling. React, being one of the most popular front-end libraries out there, is also really fast. Since it can be server-rendered the output is HTML markup which is later hydrated for any interactivity you might have. Coupled with Webpack you have a very modern build setup that’s ready to facilitate anything that JavaScript ecosystem throws at you.

Gatsby is convenience

As an example of convenience that Gatsby provides, let’s take a look at how you can easily deliver optimized images for your sites. By optimized I mean the following:

• Serve high-resolution images for high-density pixel screens.
• Serve images in a modern Webp format for browsers that support it.
• Lazy load images, with a blur-up effect.

The first part comes with you needing to issue a GraphQL query to get your image processed:

query {
  file(relativePath: { eq: "images/default.jpg" }) {
    childImageSharp {
      fixed(width: 500, quality: 90) {
        ...GatsbyImageSharpFixed
      }
    }
  }
}

After that all you have to do is use the result of that query with gatsby-image React component:

<Img fixed={data.file.childImageSharp.fixed} />

Now that was painless. You also have a few useful image processing functions available to you. You can resize an image, crop it, rotate it, turn it into greyscale or duotone right out of the box (well, almost, because this functionality is provided by plugins).

This powerful image processing system that produces highly optimized results, required very little upfront effort to make it work. Now that’s what I call productivity. Gatsby has a few more gems like this one, for example, gatsby-plugin-manifest which helps with providing web app manifest and generating multiple icon sizes and a favicon from a single source.

I know this is all possible to set up in other platforms too, there are many open-source libraries out there that help with it, you might even have it all automated with your own tools. But Gatsby has it all ready for you to use in one coherent system, backed by a large community and an ever-growing ecosystem of open-source plugins.

Vercel loves Gatsby

If you thought Gatsby was cool wait until you learn what Vercel can do for you. Vercel, previously known as Zeit and the same company that created Next.js, is a hosting platform for projects built with JAMstack frameworks (JavaScript, APIs, Markup). In reality, it means you can use pretty much any modern front-end framework (or even plain JavaScript) that communicates with the backend through an API. The API itself may or may not be hosted on Vercel itself, but we’ll get to that a bit later.

To deploy to Vercel all you really have to do is run vercel init once (assuming you’ve signed up with Vercel) and after that all your git pushes will trigger a deployment. Your main branch will be deployed to a production endpoint while all other branches will be deployed to a unique preview URL, and just like that, without any effort, you have a basic staging environment. You can also configure a custom deploy hook that can be triggered by things like content changes in headless CMSs or product changes in e-commerce back-end.

Vercel is CI/CD

Chances are, Vercel already knows how to build your project without any specific instructions because it works out of the box with the most popular front-end frameworks out there. It integrates with package.json scripts so you can customize the build instructions if needed. All the build logs are available in the dashboard and you can inspect the result and status of each deployment. For simple projects, this is a perfectly adequate CI/CD setup. Once again, zero effort.

Vercel allows you to configure environment variables for three environments, Production, Preview, and Development right from the dashboard. The values are encrypted so that means they are perfect for storing secrets. When developing you can pull environment variables using vercel env which will download the development variables from Vercel and place them in .env. With this, you have a simple solution for hosted secrets that stay out of your repo.

Vercel is supersonic fast

One of the biggest benefits you can get from using Vercel is the performance it delivers. Vercel, as they put it, has an obsessive focus on end-user performance. Vercel delivers all your files through a global edge network (or CDN) which is built on top of multiple AWS regions. With this, they are able to cache and optimize the delivery of all assets, take care of automatic SSL encryption, asset compression, and cache invalidation.

Vercel is serverless

It is also super easy to build an API with Vercel. All you need to do is create a folder named api in your project and place JavaScript (or Go, Python, Ruby at the time of this writing) files in that folder that export a function. These functions are using Express-like interfaces. The name of your file will be the URL under which it can be accessed. These functions are served through AWS lambda.

export default async function subscribeEmail(req, res) {
  subscriptionManager.subscribe(req.body.email);
  res.status(200).json({ success: true })
}

Vercel has got you covered during development too, just run vercel dev and your whole project along with API routes will be available locally.

Conclusion

Using Gatsby and Vercel we were able to go to production in record times and also produce some of the fastest pages we’ve ever had before. The whole system is very robust, easy to manage, and a pleasure to develop with. Both Gatsby and Vercel are only going to get better with time. For me and my team, it is a no brainer to keep investing our knowledge into both of these. The amount of efficiency and convenience both of them add for us is somewhat of a game-changer. If I had to list most notable highlights of what came for free, it would be these:

• Amazing, zero-setup local development experience.
• Basic CI/CD.
• Zero-setup deployment.
• Zero-setup serverless API.
• Super performant pages due to optimizations on multiple levels.
• Image processing.
• Automatic SSL.
• Hosted secrets management.

Yes, some of these are very basic in the functionality, but they are more than enough for a lot of the projects out there.