tedeh.net
1157 words

The future is now: trying out GraphQL and AWS Lambda

Lately I’ve been trying out some new technologies that may change web development. The GraphQL query language combined with a serverless architecture enabled by Lambda form a wonderful combination that makes the work of developing an API and managing a server obsolete. Or does it? Let’s have a peek into the future!

Brief explanation of concepts

Let’s start out with an explanation of some of the key concepts.

What is GraphQL?

GraphQL is a query language developed by Facebook that may or may not be destined to replace REST as the dominating way to write web APIs.

It basically allows you to describe which data you want and how you want it formatted, and the server will serve it up just like that. This is unlike REST which defines a set of endpoints representing resources where every resource usually corresponds to a table or collection in your database.

Typically you need to request several REST endpoints as part of the process of rendering a given page in a web UI, while GraphQL promises to be able to deliver exactly what you want, how you want it, with just a single query.

What is AWS Lambda?

AWS Lambda is a cloud offering from Amazon delivering “event-driven, serverless computing” that is also “instantly scalable”. It was launched in 2014 and has been getting a lot of hype lately.

So does “serverless” mean there is no server? No, it does not. Your code will still run on a server, it basically just means that you define and upload functions that only get executed when requested and AWS Lambda takes care of all the details required to make it work. A function can be anything from a processor for image uploads to a regular web server – which is what we are going to use it for.

A great thing about AWS Lambda is that it comes with a generous one-million requests per month free-tier, which means that you can try to deploy the repository I’ve attached to the internet without having to pay anything at all!

Client and Server with GraphQL/Apollo

The first thing to do was choosing a GraphQL client and pick a suitable tutorial. I settled on Apollo and followed this tutorial written by one of their developers.

Apollo describe themselves on Github as a “A community building flexible open source tools for GraphQL” and they have created many convenient packages to help GraphQL gain wider use. An alternative is Relay - which is just like GraphQL also created by Facebook.

Using the tutorial, you get to build a basic web application that shows a list of channels and their messages in a sub page. Essentially a “todo-app” with a different name. You can create new channels and post new messages to the individual channels. Some important features of Apollo and GraphQL are showcased:

  • Schemas (defines what data GraphQL offers)
  • Queries and mutations
  • Resolvers (how the actual data is fetched or commited to the store)
  • Optimistic UI (updates are shown before being confirmed by the server)
  • Subscriptions (receive updates over a web socket)
  • Tooling (graphiql which lets you explore and query a GraphQL endpoint)

Note: The tutorial is in some respects obsoleted by the fact that Apollo had a major version bump (2.0) in the time since the tutorial was written. Most of the concepts were easy to translate to the latest version, so I opted to follow it anyway.

Getting it on the web with apex/up

Finishing the GraphQL/Apollo tutorial and getting a working version, I went and looked for a way to get it published on the internet.

I’ve always been a fan of TJ Holowaychuk since he’s single-handedly responsible for like half of the entire node.js ecosystem. His new venture is called apex and one of the tools he has developed is apex/up which makes working with AWS Lambda literally as simple as a single command.

With apex/up you can deploy your web server to any of the datacenter regions (or all of them) that support AWS Lambda.

Once the tutorial was done, it did not take a lot of effort to get the build process for apex/up ready. You deploy the server by executing up in the server directory, waiting for a few minutes, and then opening the URL of your newly deployed live server in the browser with up url --open. Voila — your server, ready to receive requests from anywhere in the world in less than five minutes after running a single command. Amazing!

A few of the features that apex/up provide:

  • Single-command deploys and updates to any number of AWS datacenters
  • Lifecycle hooks to speed up deployment
  • Buy domains with a single command from Amazon Route53 and directly wire them to your servers via the console
  • Deploy servers written in node.js, Golang, Python and more. Also provides a static server that serves files from the current directory.
  • Streaming logs from all your deployed functions/servers
  • Will support other platforms besides AWS Lambda in the future

Try it yourself

I decided to publish the code I wrote on Github if anyone wants to try – if you have an Amazon AWS account, node/npm and apex/up installed you can get the working app running in only about four commands! See the attached README for instructions.

Conclusions

I must say GraphQL has made me excited. I’m doubtful that it will replace REST but it will definitely compliment it. The query language feels refreshing, and tools like Apollo really help when developing more complicated concepts like optimistic UI – things that are important when your intention is to build high quality interfaces like TEDEH LTD does.

You can say what you want about Facebook, but they are definitely at the forefront when it comes to developing the tools and frameworks that help create the modern web.

AWS Lambda is also cool technology, but it has some drawbacks. When you are running web servers that don’t see a lot of requests every minute you will experience cold starts where it takes a certain amount of time (a few seconds typically) before your server responds. It is more expensive than equivalent EC2 instances, and probably more expensive “request-for-request” when it is compared to any regular VPS too, once your app no longer fits in the free tier.

However, I belive it shows great promise when used as a playground for apps and services that you are validating. You don’t suffer lock-in when using AWS Lambda and a complimentary tool like apex/up – you are just writing a plain server anyway, and should your app take off, there will always be the opportunity to graduate it to a real server. The generous free tier makes this a very attractive proposition, in my opinion.

All in all, a great learning opportunity that I would recommend to anyone with an interest in the future of web development to follow. I will definitely try to leverage these techologies in a future project!