I was an engineer at Linkedin from 2010 and had a chance to see and help its tech stack evolve to match the growing engineering challenges of a fast growing web product. I also spent several years building my own startup Socialwok which was a Techrunch50 winner. I'm currently building an automagical GraphQL to SQL compiler called GraphJin and a popular community 42papers.com around top trending research papers in CS/ML/AI. Over the years I've built many products with various languages and frameworks but until now mostly with REST APIs.
I have a love-hate relationship with REST APIs. Having spent years consuming APIs from building startups to helping move Linkedin to EmberJS and with various apps in React and Vue. And as a producer of APIs external and internal APIs as part of Linkedin's Ads Engineering and other teams. The key takeaway I have from all this experience is if a technology is slowing you down then it's the wrong choice.
REST
In the REST world building an API first required you to name it and think up the URL structure. I found that even these simple things are really hard since neither quite fit. Should it be /users/3/products, /products?user_ids=3,4,5 or something entirely different /products_page?q=user:3. Does it make sense to use PUT, POST or PATCH, etc. While REST and GraphQL are both just de-facto standards with REST even the basics are over the place.
Most of REST world focuses on building resource specific APIs while in the real world your needs are more view or action specific. This is also why backend rendering like in Rails makes so much sense as opposed to firing tens of API calls.
Let me tell you a story that you'll find familiar. Say you're working at your job and the product team decides that a profile image and a full-name should be added to each comment on the page. The current API only returns the first name so the PM adds a ticket on the backend team. The backend developer now has to change the SQL and the JSON structure to return these new fields this takes a day or more blocking the React, Android and IOS developer. And with smaller teams it turns into a massive context-switch into the backend stack to make this change. In short it's not great we wasting time, money and productivity. And This happens over and over again.
So what's good about REST? Well its popular cause it was simple to start with and it native to browsers. All the good-ness of ETags, Cache-Control, etc comes out of the box. you can use GET, POST, DELETE. All you need is an HTTP client.
What seems simple to start with has an added cost that you pay as long as you continue to use it. I've even sat in meetings to decide the url path of an API. I can bet like me you'd like that hour of your life back. REST APIs are too limiting and too restrictive for the fast and data rich applications of today.
But REST is not all bad there are several use-cases where REST continues to be the best choice. For OAuth based auth flows, file upload or download endpoints, sharable links and web hooks to name a few.
GraphQL
Life has shown me that the best products are built by teams that value the developers experience as much as the customers experience. Technology that allows your team the freedom to move fast will provide you the highest return on investment. This is exactly why Github, Shopify, Twitch, etc were all built on Rails. A complex stack that came with all common requirements included and minimizes context switching. It allowed the developer to do focused work faster.
Yes, the infrastructure required to use GraphQL is more than REST but it gives more back by helping developers to do more focused work faster.
Frontends today, mobile or web are increasingly complex and designed to provide rich experiences to your customers. It's a highly specialized skill. A React developer has to juggle the state management, user-experience, javascript tooling and the same with Android or IOS developers. The last thing you want is for him to be blocked or have to also fix APIs.
GraphQL gives power back to the person building the customer facing apps. He can query for the data he needs when he needs it. He does not have to remember complex REST APIs semantics and or if to use a POST, PUT, GET or whatever. He just writes out his query in GraphQL and the data just shows up. It's simple.
Almost 90% of all apps require fetching complex related data to render page views. GraphQL allows your frontend devs to fetch all the data they need in a single query without waiting on anyone else. This results in faster apps for your customers and to iterate on for your devs.
GraphQL has many more useful capabilities for example subscriptions. Once your initial view is rendered you can then subscribe to the same view query to get instant updates over web-sockets. This is much more efficient and nicer than the long polling that you'd have to do with REST.
People often bring up caching as a weak point of GraphQL. And I'll agree somewhat since it's not easy to leverage browser caching with POSTGraphQL endpoints. However GraphQL client libraries like Apollo and URQL have come far and have quite sophisticated caching capabilities that even go further than what browser provide REST APIs. Additionally GraphQL now has features like automatic persisted queries or APQ that allow you to use GraphQL over REST APIs leveraging that browser caching you wanted.
In short GraphQL is a querying language that when done right can help your team build data rich modern app experiences quicker leaving you more room to iterate towards a product your customers love.
Conclusion
You'll probably need both. REST APIs will continue to play their part in your stack and GraphQL will take on the job of the primary driver for fetching and changing the data that your app deals with.
Getting started with GraphQL is very easy there are several open source options out there all of which are pretty solid. While I'm a little biased I'll recommend checking out GraphJin a GraphQL backend in GO that will save you countless hours. Just point GraphJin at your Postgres or MySQL database and start writing your GraphQL queries, it will automagically convert them into an efficient SQL query and fetch the data needed from your database. It also learns the schema and relationships in your database on its own so no config or code required.
I'd love to hear what your thoughts are on this debate. Would you pick GraphQL and if not then why? And if you are using GraphQL currently then what is your stack made up of?
You can find me at twitter.com/dosco.
Top comments (3)
Nice to put these two side-by-side. I do think however that mapping a datamodel directly onto an API is an anti-pattern and hardly ever leads to something useful. So, automatically translating a datamodel to a Graphql API implementation is no good and leads to inefficient transactions and business logic in the browser. Do you have different experiences?
Thats a great point. I do agree in theory it could be an anti-pattern but in my opinion it depends. For example with 42papers.com there were several places where business logic dictated the API response in short it was decoupled from the data-model. The way I handle this requirement is to use database views which behave exactly like other tables but could just as easily be called an internal API. The line between what is a data-model and what is an API is pretty blurred.
Another common case is when using "remote joins" with internal APIs (aka microservices) GraphJin can use data from the initial response to fan out and join responses from other APIs into the final response.
And finally for most startups adding this level of abstraction unless it's really needed is overkill and the data in the database maps pretty nicely to exactly what the needs of the UI.
Views are good indeed, implementing auto-api endpoints where there are no database tables. Read-only though. Thx for going into this.