We are digital explores. We love to work on cutting-edge technologies & new frameworks. That's a fact. GraphQL is definitely one of those but when it comes to implementing new tech in commercial projects you need to convince your team or Lead Developer that it's worth giving a shot.
How to do it? It obviously not that easy. First of all, you need to explain what exactly is GraphQL and how your project would benefit from it. Then you need to answer some questions ... a lot of questions!
Let's begin with "What's GraphQL?" part...
What's GraphQL?
GraphQL is a data query language and execution engine open-sourced by Facebook in 2015. Its main benefit is that it works with any backend service. GraphQL API is a new architectural approach that heavily reduces the size of your API & the number of API calls.
If you want to read more about the GraphQL check graphl.org or howtographql.com.
Now let's move to "You probably will hear that" part ...
Why don't stick to REST?
REST no longer gets it done. This observation was made by the Facebook team back in 2012 working on Facebook mobile apps. Standard REST APIs require the frontend team to call multiple URLs to fetch all the data they need, GraphQL uses only one endpoint which results in better performance on slow cellular connections which is still a very important issue.
Why should we use it?
Where to start? GraphQL is an interesting approach with much to offer. There are a lot of pros of GraphQL you can pitch to your team. These should do the job:
Performance - with GraphQL you don't have to define dozens of service end-points to fetch data. GraphQL lets you request the amount of data you actually need it, which is difficult to achieve with REST-based services. This greatly improves performance, reduces the number of round trips to the server & reduces the amount of data transferred over the wire.
Faster prototyping - GraphQL reduces the amount of code you need to write to achieve simple features. Less code means fewer bugs.
Great tooling - GraphQL's popularity created an ecosystem of different supplementary tools bridging the implementation gap & making GraphQL easier to adopt.
Is GraphQL secure?
GraphQL is no different from any other service end-point. As long as you will follow some of the basic security good-practices you can sleep soundly.
Is it production-ready?
Let's not beat around the bush - YES#1, YES#2, YES#3.
Not enough? Here are a couple more ...
Source: graphql.org
Speed up your GraphQL API development
GraphQL Editor is a supportive tool for both advanced GraphQL users as well as those taking their first steps with GraphQL APIs. Our all-in-one development environment for GraphQL will help you build, manage & deploy your GraphQL API much faster thanks to dozens of built-in micro features.
Top comments (9)
Hey Tomek!
While I really like GraphQL – damn, in my recept app it's the only possible way to communicate – I totally understand when people want to stick with REST. It's old, and by this, it's battle-tested. It's easier to find someone that knows about HATEOAS than data graphs. It's easier to find developers than can read Swagger and consume the endpoints with Axios than people that'll write a query, even using an external tool (like yours GraphQL Editor).
It's not really true that REST cannot get the job done. It can, and it can be very performant, when properly constructed. It all depends on the use-cases. All in all, it's all data, and there is no solution that will make my payload smaller than it physically is.
The biggest issues with REST in my opinion are under- and over- fetching, meaning that you get too little and too much data respectively.
For example, if you want to build a website like dev.to and use REST, on the front page you can read the user's details (one API call), a list of posts (another call), and their notifications (third call).
Each call receives incomplete data, which is underfetching.
Each endpoint defines what data it returns. Sometimes, you can return too much data (e.g. serialize all the comments, when we just want a count), which results in overfetching... Getting more data than we need.
You can limit that data, but then you need to define more endpoints, or pass them parameters.
GraphQL is very elegant in that it can fetch all related data in one call, rather than three (and it could be much more than three in some websites), and only returns the data you explicitly ask for, so it can definitely reduce the amount of data you send in many cases.
Which doesn't mean that you can't / shouldn't use REST, especially if you already have a running codebase... Don't go nuking the repo all of a sudden, but if you're starting a new project, GraphQL is worth a consideration.
Of course, it's newer, not as well supported as solutions that have been around for years (e.g. the django rest framework, which is gorgeous and well documented), etc. There are arguments in favour of both technologies.
In GraphQL, you need to write queries, which is far more verbose than passing a parameter or picking another endpoint. For example, for news list, an endpoint might look like
/news?truncated=true, while a query would be far larger.And this may sometimes be an issue. Let's assume you want to build a dev.to clone. You should design your REST endpoints in a manner that'll mirror the view. Then, you should leverage, what resources are needed first (post list), what are secondary (sidebar lists) and so forth. Then, you can fetch those accordingly.
This solution is also valid for GraphQL. Here it would be less API-based discussions, but like I've said previously, finding people fluent in GQL on both front- end back-end side is way harder than for REST.
All that said, I really like GraphQL and it is my go-to choice as of recently, but REST is also a great standard, and will be there for years and years.
To me, writing queries is not much of an issue. You can share them with the backend if you use Ariadne and
.graphqlfiles, and like The Zen of Python says, "explicit is better than implicit."Plus I like having them all in one directory... Oftentimes, you can see single file components with hard-coded API endpoints. With GraphQL, you can import the queries you need, and reference them. (Of course, you could make an endpoints object, import that, and reference it, but it's not as obvious / common, I think).
Fully agree. Pragmatism is important - use whatever works. I'd rather use GraphQL in new projects, but I wouldn't turn down a REST job, and I wouldn't bother converting an existing API unless its REST implementation has too many pain points.
Thanks for Ariadne – I didn't know that!
As for structure, imports etc, this all can be achieved with REST. Keeping hardcoded endpoints is just as poor practice as keeping queries hardcoded (the exception may be a single-time-use thing).
The problem with queries is, while you don't mind writing them, and I don't either, there will be people that won't see it that way. And I totally understand a seasoned developer that worked with REST for 10 years that don't have the time to learn a new way to query the data, given the fact how little GQL is there in the market, comparing to REST.
"Is GraphQL secure?"
Unlike frameworks for RESTful services, I haven't come across a single graphql library or framework that provides input validation and access control support. You have to write and wire all the security controls yourself.
GraphQL will be great, but for the moment it moves security controls backwards on API services significantly.
Here's a decent talk that goes into more depth on some of this: irongeek.com/i.php?page=videos/der...
I like the idea of GraphQL, but found that it required lots of boilerplate to use (such as templating). I also couldn't use it with TypeScript easily because there was no way to get GraphQL queries statically type-checked. Finally, some data types can't be serialized without a heavy library such as Apollo. When using URQL, I was disappointed that dates got transformed into strings and files couldn't be sent.
I am here to save you
I also couldn't use it with TypeScript easily because there was no way to get GraphQL queries statically type-checkedgithub.com/graphql-editor/graphql-...
What an awesome tool. Thanks for sharing!