Photo by charlesdeluvio on Unsplash
AWS Amplify introduced me to Appsync and I was aware of GraphQL. Not that I have spent a lot of time in actually implementing GraphQL in various projects, but I knew about the advantages it offered as far as API calls were concerned. However, I did not know about the process of implementing them as the core of the application.
Thanks for reading Let's Do Tech! Subscribe for free to receive new posts and support my work.
What happened?
Appsync is a GraphQL service provided by AWS. When I said Amplify wraps all of this to support frontend developers with backend, it does make use of Appsync as well. This was my first time using GraphQL, and owing to the good words, I went all in to implement the same.
One fundamental thing which I missed while doing so was that GraphQL inherently is a frontend-driven technology. It provides a sleek way of querying for the backend data by providing the frontend apps with meaningful APIs. Query only the data you need - they said.
All of it sounds great, but the actual implementation of GraphQL requires a lot of learning as compared to simple REST APIs, with minimal to no advantage, depending on the scale of the project.
Database schema based on frontend requirement?
In a way, incorporating GraphQL requires us to also drive the decisions related to database schema. Not being biased, but this is an inconvenience to database designers and architects. From the frontend’s perspective, data comes from the other extreme end. While from the backend perspective, data is the first thing to worry about.
There are so many reference architectures dedicated only to manage data processing and ETL processes are designed around the same. It is insane for people to design it as per the frontend’s priority - no matter the scale of the application. In my opinion, this just does not fit well.
One may argue, that the schema generated by GraphQL and the core data are two different things. Well, I get your point, but does that mean we add another step in processing the core application data, to be “suitable” for GraphQL? Bi-directionally?
Perhaps, GraphQL/Appsync might be a good solution for those don’t want to worry much about the data and its relevance.
Resolvers and the work to implement them
For those who are uninitiated, the CRUD operations in GraphQL are basically called queries (R) and mutations (CUD). To perform any of these operations, GraphQL requires “resolvers”. Resolvers understand what is needed to be queried, talk to the database, process the returned data in a format expected by the asking application, and finally present the results.
If GraphQL is being used, no application - both frontend and backend - developed in any language, are capable of consuming the same without using the SDKs, or libraries. This is where the learning curve comes into play. I agree, the purpose of SDKs is to reduce the learning curve. But I see little advantage of using this over REST APIs, with all that resolving logic in between.
I read somewhere that one of the advantage of using GraphQL is that the clients query only the data that is required by them - this reduces the network usage and improves performance. In 2023, by how much? including the transport of required libraries in browser based apps?
More work on the backend
Quite a lot depends on the way GraphQL is implemented on the backend. “Implementing GraphQL” - sounds like a task in itself. Additionally, in order to talk to the underlying data sources, additional customisation is always required. GraphQL is not a magic wand in that way.
Again, what is wrong in using REST API with some caching mechanism? Don’t even get me started on authentication and authorisation for protected APIs. :)
Where should business logic go?
The backend applications, now have 2 options to CRUD the data - GraphQL APIs, and direct Database connections internally. If the applications are residing internally, it would be easier to run SQL/NoSQL queries using database connection pools.
Even if we have to go via the GraphQL route, we cannot do without SDKs and libraries. Plus the additional code required to execute queries and mutation logic.
Final question
If we go the GraphQL route, would it be possible for the teams to completely ignore or not rely on API Gateway/REST APIs? I highly doubt. REST APIs are used for other purposes as well. Not all API calls are made only to CRUD the data.
Conclusion
This was a bit of a rant and I may be wrong. But at this point, I do feel GraphQL is overhyped. It does not hurt to have use-case crafted REST APIs and a Swagger documentation around it. To think of it from another side, if GraphQL was so good, it should have replaced REST APIs today.
Sumeet N.
Thanks for reading Let's Do Tech! Subscribe for free to receive new posts and support my work.
Top comments (0)