The issue of shifting away from REST to GraphQL has been interested me for a very long time. Still, being a backend developer, I had disputes with Frontend developers about the need to implement this technology. But now, after 2 years, I have already began to act as a speaker and talk about the features of the transition from REST to GraphQL. It all started well - the opportunities that GraphQL provides out of the box pleased us so much that we, at wormsoft.ru, began to gradually transfer the current projects of our clients to this technology.
Abstracts for publication
Dreaming of unloading Backend developers as much as possible, I decided to try to delegate the logic of grouping data in server requests to Frontend developers. GraphQL was chosen as the final solution. First, we made a couple of test projects on it and, after the checks, we started using GraphQL in customer projects. A lot of water under the bridge and knowledge about the features of the translation which could be shared has accumulated. In the process of transition, we encountered many features of this technology and the experience gained, at the moment, allows us to reveal the following points:
- Pros and Cons of Switching to GraphQL
- How to gradually switch to GraphQL
- How to safely delegate data assembly logic to Frontend
- How you can get the maximum effect from connecting GraphQL to a project with microservices
- The disadvantages of technology that we realized only when we had faced with them
- What you need to know in order not to shoot yourself in the foot while connecting GraphQL
Videos of the speeches on this topic
- PHPRussia 2019 youtu.be/VsbiuFzILRM
- RITFest 2019 (Backendconf) youtu.be/iiI5L6b0Uvo
- Ufadevconf youtu.be/rTPDC6P9yx8
There was also a presentation on the related topic called "GraphQL load resistance versus REST load resistance". Part of the report coincides with the base speech, but there is a separate part about what you need to monitor while under load.
Video of the speech on Highload++ Siberia: youtu.be/_L_2HNXrTbI