Stop looking hard into graphql — Sails/Waterline solves it all
Let’s be frank this time — REST is not gonna be replaced anytime soon.
Everyone is over heated by “this” new technology buzzing everywhere in the tech town, for some time now it has already gained tractions by top companies in the world and everybody seems to be ok with the new renovation of how we send and recieve data.
What is Graphql?
GraphQL is a specification that aims at “easing” the communication between frontends and backends. It mainly consists of a “Schema Language” for the server and a “Query Language” for the client.
notice the emphasized text? good!
What does it fix?
- One endpoint
- Query only for what you need
- Restructure your client’s data the way you want.
Now lets look into those one at a time.
One endpoint
Graphql has only one endpoint in which queries and mutation are sent and served from — that’s ok but there’s a lie underneath
There’s no much difference between them all go down to one place, the only thing to listen to is the HTTP verbs.
Sailsjs can do a lot of what GraphQL does
GraphQL is an alternative to REST for developing APIs, not a replacement.
The main feature of GraphQL is to be able to send a query specifying only the information you need and get exactly that.
But you can also achieve this using Sailsjs, from passing the name of the fields you want to use in the URL and letting sails handle the main logic
This is a typical “GET /user” request in sailsjs
might yield:
2) Query only for what you need
Developers often describe the major benefit of GraphQL with the fact that clients can retrieve exactly the data they need from the API. They don’t have to rely on REST endpoints that return predefined and fixed data structures. while this may be true of REST by sails comes handy in solving this problem for example:
A RESTFUL endpoint with
https://localhost:1337/user/?select=emailAddress,fullName,phone
might yield this result, you see? clients now can retrieve exactly the data they need from the Sails API
Lets say that you want to omit the password, photo and emailStatus field from the whole user data
Remember that i don’t need to write any single “controller” before i can run CRUD operations
Sailsjs REST is self validating
Imaging that you sent an incorrect parameter to the server, you’ll see a nice error message right from your response.
Restructure your client’s data the way you want.
i don’t see any sense anyone would like to do that
GraphQL will make some tasks more complex
Using GraphQL in a simple application (for example, one that uses a few fields in the same way, every time) is not recommended because it adds more complexity because of things such as:
- Types
- Queries
- Mutators
- Resolvers
- High-order components
Which is not good from a maintenance perspective.
But even if the use of GraphQL is justified, there may be some complications.
Sailsjs model queries are the best
A model represents a set of structured data, called records. Models usually correspond to a table/collection in a database, attributes correspond to columns/fields, and records correspond to rows/documents.
module.exports = {
attributes: {
nameOnMenu: { type: ‘string’, required: true },
price: { type: ‘string’, required: true },
percentRealMeat: { type: ‘number’, defaultsTo: 20, columnType: ‘FLOAT’ },
numCalories: { type: ‘number’ },
},
};GraphQL schemas could be a problem
By allowing you to define a schema, GraphQL gives you a lot of benefits, like automatic validation and introspection.
But schemas are static and the response the clients are going to get depends on the schema definition and the query they make.
For example, you cannot have more depth than what is specified in the schema or in the query, schemas that you can modify at runtime, or dynamic type definitions.
The GraphQL specification doesn’t cover dynamic features like these, so you have to rely on hacky solutions or custom server implementations.
Some libraries like GraphQL Ruby have mechanisms to define your schema dynamically programmatically. This may solve some requirements.
On the other hand, I have seen people create very generic schemas to try to resolve more complex requirements:
Conclusion
GraphQL is a powerful tool, and there are many reasons to choose GraphQL over REST. But don’t forget to choose the right tool for the right job.
The points I have presented here may not always apply, but it is worth taking them into account to see if they can be addressed. There are still use cases where REST is a valid approach.
