React, GraphQL and Relay: A match made in Facebook
--
Do you organize your code with the MVC standard? Are your APIs RESTful?
If so, Facebook engineers have a surprise for you. They believe MVC and REST are not suited for big applications, and that there are some alternatives that you should learn.
React.js was a huge revolutionary hit from Facebook, it’s simple and effective, and it changed the way we design our views for good.
We now have two other libraries from Facebook that are positioned to do a follow up revolution! GraphQL and Relay.
Just like how React sounded crazy and awesome at the same time, GraphQL and Relay are on a similar path. React challenged all other frameworks with the crazy idea of putting HTML inside JavaScript (when everyone else was doing exactly the inverse), and the mental and performance benefits for that idea were far too good. Everyone let their guards down and accepted the idea. React has already won that battle.
Relay has a new battle to fight, and that is mainly the new crazy idea of putting the data requirements inside the view itself, which is a violation of MVC!
Will this crazy idea convert into something that we accept eventually? Maybe! Facebook engineers, as usual, have the wonderfully worded reasons to push it forward.
Only a view component knows exactly the data elements it needs to render correctly, why separate it from its data requirements at all? Let’s actually couple them close together and have them join their powers!
More importantly, since we know everything about the data requirements in the view, can’t we just ask the server a single question to answer with ALL the data we need?
That is the idea behind a GraphQL query, let me explain it with a simple example:
Let’s say we have a view that renders the first 100 contact’s names and addresses, along with their phone numbers and emails
You can’t get all this information in one request with REST, unless you write a customized endpoint and with custom logic on the server, something like:
/contacts?first=100&include=names,addresses,phone_numbers,emailsFair enough, now we have another view that renders the last 10 contacts, and it displays their social profile links.
We need another custom REST endpoint:
/contacts?last=10&include=names,social_profile_linksDo you get the picture? Clearly, the view knows what it needs and it CAN always ask for it accurately. With Relay, we’ll always express what data we need in the view itself, but now, these custom endpoints are not going to scale, we need another Facebook radical solution here! GraphQL
What if, the server is smart enough to always parse what requirements you send it, and respond with whatever data that requirements expressed? Basically a very smart custom endpoint with lots of if statements! that is more or less what you get with GraphQL (without the if statements though).
A GraphQL server will define a tree of everything it can respond with, and then using a GraphQL query, it can reply to any custom request. No further customization needed, no under fetching, no over fetching. One endpoint to rule them all
More or less, this is going to be, I think, the killer of REST APIs, or, as I like to call them now, REST-In-Peace APIs.
I believe React, GraphQL, and Relay together will form an amazingly strong stack, that will potentially blow REST away — for good — and push the MVC pattern to the edge of extinction. In few years, writing MVC applications on REST endpoints might be a thing from the past.
Samer Buna is the author of “React.js: Getting Started”, “Building Data-driven React Applications with Relay, GraphQL, and Flux” and multiple other courses on Pluralsight.
