Engineering Manager with a passion for web and application development. Speaker and writer on work experiences and software development. Dog dad and musician fueled by coffee.
I don't know why my notifications didn't let me know about your reply. I agree that my post is extremely brief in outlining REST API limitations as that wasn't the focal point. You are correct in saying it is an implementation problem and not necessarily a problem with REST itself. GraphQL is built upon REST so to say REST is problematic was not my intent. Classic implementations on the other hand can lead to the problems outlined. You do mention some possible solutions to the problems I've highlighted, but what I've found in several organizations is that it's more of an effort to accomplish proper communication and design across teams. I have heard of several of the tools you've mentioned, such as OpenAPI, and it does solve the problem mentioned. However, it's not something that ships out-of-the-box with the tool itself and leads to extra engineering effort to accomplish the same goals. My point with the "Traditional API Problems" section of this article was to highlight the utilities and problems that GraphQL can solve out-of-the-box without extra effort to help those looking to convince their teams identify some key argument points that may resonant. These same arguments were ones that some of my previous organizations had used to make the choice to opt into GraphQL and move away from traditional REST.
Depending on what your use case is and what you're trying to accomplish, GraphQL may not be the proper solution for you. My hope is this highlights some of the arguments for possibly adopting GraphQL with your teams and gives some insight into an approach you can take in order to possibly transition if that's something you're looking to do.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't know why my notifications didn't let me know about your reply. I agree that my post is extremely brief in outlining REST API limitations as that wasn't the focal point. You are correct in saying it is an implementation problem and not necessarily a problem with REST itself. GraphQL is built upon REST so to say REST is problematic was not my intent. Classic implementations on the other hand can lead to the problems outlined. You do mention some possible solutions to the problems I've highlighted, but what I've found in several organizations is that it's more of an effort to accomplish proper communication and design across teams. I have heard of several of the tools you've mentioned, such as OpenAPI, and it does solve the problem mentioned. However, it's not something that ships out-of-the-box with the tool itself and leads to extra engineering effort to accomplish the same goals. My point with the "Traditional API Problems" section of this article was to highlight the utilities and problems that GraphQL can solve out-of-the-box without extra effort to help those looking to convince their teams identify some key argument points that may resonant. These same arguments were ones that some of my previous organizations had used to make the choice to opt into GraphQL and move away from traditional REST.
Depending on what your use case is and what you're trying to accomplish, GraphQL may not be the proper solution for you. My hope is this highlights some of the arguments for possibly adopting GraphQL with your teams and gives some insight into an approach you can take in order to possibly transition if that's something you're looking to do.