Do you have a sweet tooth?
A bakery analogy is what’s kneaded this week for this talk to rise to its potential. Apollo GraphQL VS REST – it’s time to kill 2 birds with one scone and see which language is the thorough-bread you knead to get on board with – no more loafing around…
So, crack a rye smile – because this one sure will take the cake.
Time to baguette and tag it – REST is toast.
This week we’re cooking up some synonym rolls that would make grammar proud. All jokes aside, we promise that’s the last pun you’ll hear from us – it’s all business from here on out.
Some big-name companies are putting substantial resources into evaluating how Graph QL can help in their operational efficiency, and investing big money into their staff to learn and implement GraphQL into their systems.
New can be scary. But it can also be exciting to sink your teeth into the gooey, jam filled centre of a budding technology – tasting the bold flavor that comes with a new concept, a new programming language, and different conventions than what you’re used to.
What Is It:
What sets GraphQL apart from REST is its declarative nature. The language itself was designed to communicate between applications and servers in a certain unique way. Picture a customer walking into the bakery, and placing an order with the cashier – this is exactly how an app, program, or developer requests data from a backend database.
At its heart, GraphQL is a data query and manipulation language for application programming interfaces, and a runtime environment for matching up those queries with the relevant existing data, in the way the user query requests. It was developed by tech giant Facebook in 2012, and was made available as open source in 2015.
Nodes of data or rows in the database can best be described as boxes of pastries on display in this server bakery. Each attribute of that row of data represents a particular kind of baked treat, be it donuts, eclairs, croissants – take your pick. These can also be thought of as the types within the Graph QL schema.
The variety of pastry, as the attribute of that row in the database, would represent whether the data correlates to ID, Name, Emails, etc. Each variety of a particular pastry, for this example let’s use a strawberry donut to denote the ID of a suer, represents an attribute or a column and the data that contains. These flavors can be thought as fields in GraphQL.
What Is It Used For?
In the real world, GraphQL is a web service architecture that prevents large volumes of data being returned to the server by letting the client define parameters around the structure of the required data.
In our bakery, the customer or app can walk in and choose from a massive menu showing all the available varieties of pastries. This vast menu is the schema of the programming language. Once the customer makes the order, the cashier or back-end logic will confirm that the items in fact do appear on the menu, and are in stock or available at the time of request.
The menu, Graph QL query or query type in our example, has to be written in a specific font and format, and must be always kept up to date so the customer can make an informed decision – the same way that a user app needs an accurate list of what data can be accessed in the server.
Instead of being limited to ordering just a box of donuts, or eclairs, or croissants, they are given the option of making a mix and match box – able to fill with any assorted blend of pastries.
How It Works:
Let’s say the donut box contains all the user information, and the éclair box contains all the user’s posts. Instead of having to buy both boxes containing all the varieties of pastries, we can pick and choose.
Say we want user ID, that’s a strawberry donut. User name, a chocolate donut. User email, and an original cinnamon donut will do. But we also want their post count stats – so we can chuck in an almond éclair, without having to request a full éclair box full of attributes relating to the user’s posts.
When data in the database needs to be modified or re-written to update, delete or create data, this is the same as a customer having the ability to add custom toppings and flavors onto their pastries. In this case, mutations would be like adding sprinkles or nuts on top of that strawberry donut. But they can only add toppings defined by the menu or schema – it’s not like they can add anchovies on top. The cashier has to verify that this mutation or custom flavor order is possible based on what the menu says the bakery can provide.
The real power of GraphQL becomes apparent when you look into how resolvers provide the instructions that turn queries or mutations into the requested data – these are the bakers in our bakery. Provided the order checks out against the menu, the bakers will make whatever flavor or variety pastry the app customer wants, in a combination box of their choosing.
Subscriptions in Graph QL provide access to real time data to resolve queries on the fly. When the data changes, the user app updates to reflect the change. This is the equivalent to an online ordering service for our bakery, where the customer can order their box of mixed pastries only according to what is in stock at the time, or relative to what baking supplies the bakers have to work with.
Great for Microservices:
There is a shift from traditional monolithic architecture to microservices architecture, and it just so happens that GraphQL is very well suited for the latter. GraphQL unifies multiple systems threads behind its application programming interface, and hides their complexity by fetching only the data requested by the user.
Great for Crossing Over:
The migration from monolithic or microservices architecture can be a headache. GraphQL has the ability to handle communications between microservices by consolidating them into one GraphQL schema which can then be used by the monolithic server being replaced to drastically reduce downtime during the upgrade.
Making It Simple:
GraphQL fetches data based on a single query, without having to be centered around individual endpoints needed to collect data. Its task focused, so the user can request all the data they require from just one application programming interface call.
There are no problems associated with over or under fetching of data using GraphQL. The exact data required is clearly defined in a single request.
GraphQL comes with validation and type checking as standard. Apps can only ask for what’s possible, in the appropriate format. If new fields need to be added to existing data, then this data doesn’t need to be validated – Graph QL does it automatically.
A Bit Slow:
The ability for the user to request exactly what they need can sometimes hinder the system, if they ask for too many fields at once the performance of GraphQL can take a hit. Using rate limiting mechanisms can cut down inefficient queries from the user side of things, and prevent recurring or persistent queries.
While Graph QL is brilliant for microservices architecture, it can be overkill for smaller servers.
As GraphQL doesn’t utilize HTTP caching methods, the storing of the content of a request is kept on the server itself instead of keeping frequently accessed information on the client side. Each subsequent query can’t draw on a cache for common data – it all has to come over again from the server side.
So, to put it plainly – GraphQL doesn’t understand file uploads. In order to do this, you have to make a separate application programming interface using base64 encoding using a library specific to this purpose. A tad annoying.
Steep Learning Curve:
Because Graph QL works so differently, it does take a while to get your head around the concepts and schema. The time taken by your team to learn and become efficient in GraphQL may be time you simply don’t have.
How Does It Compare:
So, let’s take a look at the stalwart and former crowned king – REST. It’s the industry standard for companies deploying application programming interfaces and dev platforms.
The great advantage here is that REST can work with another application programming interface and not need any special libraries – requests can be made using simple software like cURL and even web browsers.
It uses standard HTTP concepts like get, post, put, and delete – keeping it simple by working with HTTP conventions instead of against them. The problem is that REST is server selection driven, needing to fetch multiples resources first before sifting through them to resolve the user query and get them the data they’ve requested.
Back to the bakery example, the REST system provides customers with reduced menu options and stringent rules. The flexibility is now gone, as you have to line up to order a box of donuts, then get back in the queue for a box of eclairs, and enter the queue a 3rd time for your box of eclairs.
Each box comes sealed and pre-packaged with a set number of predetermined flavors. The bakery is the one here making the orders for the customer, and if they want a mix of donuts for example, they have to buy 2 boxes to get their mix with undesired flavors left over. In this way, REST brings data over from the server to the user that was not requested, but had to be included based on the wanted items in the data node.
If it seems ridiculous to have to keep lining up over and over and over again to get all the assorted pastries you want, and end up with a whole heap of unwanted ones, well… that’s because it is.
Unlike GraphQL, with REST you have to follow this regimented, cascading order of request events full of useless data until you get the data that you require. With GraphQL, you can cherry pick the data you want as just a single user query.
Who’s Using It:
Well for starters, Facebook is still using it. But look at who else has taken the system on board: Instagram, Twitter, PayPal, Shopify, StackShare, The New York Times, GitHub – just to name a few.
REST or GraphQL?
It’s true – REST is old news.
If you want to order the pastries you want, in one fell swoop, go with Graph QL. If you want to waste time and let the bakery order for you, and have a ton of unwanted pastries sitting on the bench going moldy, then continue using REST.
It’s a no brainer really.
It looks like it pays to be proficient in the new kid on the block. Have the necessary GraphQL skillset, and you can earn $70k as a software developer, $97k as a software engineer, and $127k as a senior software engineer.
Compare that to REST specialized, and it’s $74k for a software developer, $92k for a software engineer and $117k for a senior software engineer.
GraphQL is the future, best hop on that train now.
We hope this blog helped you learn more about the Pros and Cons of Apollo Graph QL!
If you enjoyed this blog you may also enjoy our other blogs like, Erlang and 5 Things You Need to Know About It or Golang Vs Python: Which Programming Language is Best.
Kofi Group is proud to be a source of knowledge and insight into the startup software engineering world and offers a multitude of resources to help you learn more, improve your career, and help startups hire the best talent. If you are interested in learning more about what we do and how we can help you then get in touch or watch our Youtube videos for additional information.