Every story needs a hero. But, not all heroes are the same. Some of them have superpowers, and some are ordinary people. This story’s hero is just a regular software developer who works in a small team on a medium-size application. Our hero loves his job most of the time, except when he sends a test push notification to thousands of their customers in production, like a few minutes ago.

One day, his boss came with a new project. “We need to build a new complex application for our new important customer.” Nice, our hero loves challenges! “But we need to do it fast, as we have a short deadline because they have an important marketing event!” Ok, how fast do we need to build an app? “It needs to be ready for yesterday. And it needs to be real-time and scalable!”

The new project is a big challenge for our hero, as he never did that kind of project. Can he even do it?

“You can do it,” his boss says. “I also hired a famous consultant to help you.” That’s awesome! Challenge accepted.

After a full-day meeting with the consultant, and a whiteboard full of weird diagrams, the plan was simple: “Just use Kubernetes!”

But our hero doesn’t know Kubernetes. And there’s no time to learn it now. What should he do?

He started wondering if he is the only one who doesn’t know Kubernetes. Is he good enough for this job?

Our hero spent a sleepless night in front of his computer with his faithful sidekick, a rubber duck. He tried to learn as much as he can about this new technology. But he ended up more confused and tired.

You should try Serverless GraphQL

In the middle of the night, our hero’s faithful sidekick said, “you should try serverless GraphQL.”

Was he dreaming? And what the heck is serverless GraphQL? He knows what serverless is, but what’s GraphQL?

What’s GraphQL

Do you remember when Mark Zuckerberg said, “our biggest mistake was betting too much on HTML5?” It was a long time ago, back in 2012, when HTML5 was in its early days.

At that moment, the Facebook mobile app was an HTML5 web app embedded in the native mobile shell. They served all the news feed updates as HTML data from the server. However, HTML5 was in its early days, and the mobile web views were not performant enough, so the app wasn’t stable and scalable enough.

In 2012, Facebook’s engineering team started rebuilding their mobile and switching to the native iOS and Android apps. They evaluated different options for delivering the news feed data, including RESTful services and Facebook Query Language (FQL).

In the “GraphQL: A data query language” article in 2015, Lee Byron wrote:

We were frustrated with the differences between the data we wanted to use in our apps and the server queries they required. We don’t think of data in terms of resource URLs, secondary keys, or join tables; we think about it in terms of a graph of objects and the models we ultimately use in our apps like NSObjects or JSON.

This frustration led the Facebook engineering team to rethink the way they serve data to their mobile application. Instead of returning a full model with a lot of unnecessary data, they tried to develop a new system to return only the data the application needed.

In 2015, they announced GraphQL, an open-source data query language. The idea behind GraphQL was simple, the client defines the data structure, and the server provides a JSON response with precisely the same format.

For example, the client wants to get the user with a specified ID. However, the application needs only the user’s name, a profile photo with a specific size, and the first five friend connections. Instead of sending two or three different requests to the RESTful API, with GraphQL, you can send a request similar to the one in the image below. And the response will be the JSON with the same structure, as you can see on the right side of the same image.

That sounds nice and smart. But why should our hero care about GraphQL? He doesn’t have the same problem Facebook had.

The problem Facebook’s engineering team had was the leading cause for inventing GraphQL. However, that’s not the only problem GraphQL solves. If you have one of the following symptoms, GraphQL might be the cure for the problems your application faces, too:

• Distinct front end clients for multiple platforms, such as web and mobile, have different data requirements.
• Your back end serves data to your client apps from different sources. For example, your app has SQL and NoSQL databases, and it connects to some external systems.
• Your app has a complex state and caching managements for both front end and back end.
• Slow pages, especially on mobile, caused by multiple dependant HTTP requests.

This list is not complete, and GraphQL can bring even more benefits to your application. Some of the main characteristics of GraphQL are:

• It defines a data shape. The request always specifies the response’s form, which makes requests more predictable and easier to use.
• It’s hierarchical. Its strict relation between objects with graph-structured data simplifies getting data from multiple sources.
• It’s strongly typed. It can give you descriptive error messages before you run a query.
• It’s a protocol, not storage. Each GraphQL field is backed by a function on the back end, which allows you to connect it to any storage you want in the background.
• It’s introspective. You can query the GraphQL server for the types it supports. This gives you built-in documentation and also a base for a powerful toolset.
• It’s version free. The shape of the data is always defined by the client’s request, which means adding additional fields to your model will not affect your client application until you change the query itself.

To combine data from multiple sources using RESTful API, you often send multiple HTTP requests and then connect data on the client-side. This works fine in perfect conditions. However, users don’t always use your app in ideal conditions. They are often on mobile with a limited or unstable network. Or they live in Australia, and each request is a few hundred milliseconds slower.

With GraphQL, you can archive the same with a single request. This will push a bit more load to the server-side, but that works just fine in most cases. It’s even better when you don’t own the server.

#serverless #aws #cloud #developer #graphql