In my previous post on GraphQL, I gave a high level overview on the GraphQL ecosystem and how it compares to a traditional REST API. Now it is time to discuss the language features of GraphQL and how it can be used to create an API in JavaScript.

There are two distinct pieces of GraphQL to remember. First its a language to create queries for an API. Second its a runtime library on the server to handle queries directed at the API. The GraphQL language is what I will look at first.

Last year, I started using GraphQL at my job. I decided to create some GraphQL prototypes in my spare time, to get better acquainted with the GraphQL ecosystem. In 2018 I learned the basics of GraphQL and wrote two articles about my experience, but never dove into using GraphQL in real world applications. The GraphQL React prototype discussed in this article along with my Apollo prototype are the beginnings of that production application journey. In the future, I plan on using GraphQL for the API layer of my applications.

The GraphQL prototype discussed in this article is a React front-end application that connects to a GitHub GraphQL API. The API provides details about my repositories, and React displays those details in a dashboard. The dashboard is shown below.

Over the last year or so I've heard whispers about a technology called GraphQL. GraphQL is marketed as an alternative for the REST API which so many of our applications use these days (all my websites/mobile apps use different REST APIs). I decided that I'd heard enough about GraphQL and it was time to try it out and form my own opinions.

I created a prototype GraphQL API in JavaScript. There was a bit more development work for the GraphQL prototype then I anticipated, so I am splitting up my GraphQL research across two separate discovery posts. The post you are reading now serves as an introduction to the GraphQL ecosystem and compares it to the humble REST API. The follow up post will look at my work developing a GraphQL prototype.

When it comes to CSS preprocessors (stylesheet languages that add features on top of CSS and transpile to CSS), in the past I've often used Sass. When I first started learning about CSS preprocessors, the two main choices were Sass and Less. The reason I decided to learn Sass instead of Less was due to its greater popularity and me trying to follow industry trends. At the time, Bootstrap had just released version 4, which switched its stylesheet language from Less to Sass¹. In my mind, it didn't make sense for me to learn a preprocessor language that was being left in the dust.

Over time, I increasingly wished to learn the difference between Sass and Less. It was hard for me to tell if there were differences in the functionality of Sass or Less, or if Sass was picked as the favorite due to syntactical preferences and third-party library support. Last year I wrote two front-end application prototypes, graphql-react-prototype and apollo-client-server-prototype. Instead of using a stylesheet technology I already knew such as Sass or JSS, I decided to learn Less and use it as the stylesheet language for these prototypes.

Traditionally when building a mobile app or website, the application is split into a few different layers. The necessary layers commonly comprise a front-end, backend, and database. In recent years, the backend is often a REST API that makes requests to a database. The front-end communicates with the REST API through HTTP requests.

To set up a REST API, a server is needed to host backend code. Using a backend server means app developers have to spend time managing infrastructure. As I mentioned in my post on Terraform, when cloud computing came along new techniques for handling infrastructure were introduced. With AWS Lambda, we have a new technique for handling code and infrastructure in our backend. AWS Lambda introduces containerized functions and serverless computing.