Ladies and Gentlemen, let me introduce you GraphQL. Dragons’ and gnomes’ slayer. I will be honest, GraphQL is in my opinion much better than REST and SOAP. Usually, I don’t follow trends I’m waiting when a technology grow up and solidify. I won’t be tester the newest solutions, especially when it’s related to JavaScript. As you know, frameworks in JavaScript are published every hour. I have no time for it.
GraphQL was published two years ago, Wikipedia said. I didn’t hear about it until I was looking through the agenda 4Developers, polish conference. Few speakers made presentations about it. I wasn’t on any. Just the organizer published videos on YouTube I had a chance to see them.
Why GraphQL is so cool?
This is probably the wrong question. Correctly should sound more like why REST and SOAP suck? Technology is discovered because something doesn’t work as we supposed. REST and SOAP have different approach to solve communication problem between two or more applications. SOAP is typical corporation overengineering. What is worst it was designed as a cross-platform tool. Everyone who tried integration i.e. PHP application with i.e. Java application knows it’s a lie. On other side is REST, simply as possible and based only on HTTP documentation (RFC). This is the biggest problem with REST. You easily can find thousands of developers who understand HTTP documentation different. How to create two communicated application when you are not sure what float, int or something else means.
One GraphQL to rule them all
GraphQL is communication framework no more, no less. The documentation describes how GraphQL Server should be implemented to cooperate with GraphQL Client and how GraphQL Client should talk to GraphQL server. There is no place for mistake.
Let’s check the main differences between GraphQL and REST/SOAP and why GraphQL bit them.
One endpoint
There is only i.e. /graphql. You don’t have to manage a thousand endpoints created by ten years developing an application by hundreds of software developers. You have only one endpoint to fetch, and to persists your data.
No versioning
You don’t need to think about how long you should support old endpoints or old resources. You have one endpoint which does all dirty job. You can focus on important stuff.
Strong Typing
Int is always Int, Object XYZ is always XYZ there is no place for exceptions. You don’t think about situation what if some resource sometimes returns Int and sometimes Null. You have all information in …
Documentation
Because everything in GraphQL is strong typed, it’s easy to create documentation automatically. GraphQL is quite popular now, so it means…
3rd-party software
You need a tool to test your GraphQL? It exists.
You need a tool to generate well-look documentation? It exists.
You need ….? It exists.
If you implemented GraphQL server correctly, you can use libraries in other programming languages to cooperate with your server. Everything that you need is put the path to your /graphql endpoint to a configuration that tool. It never was easier.