| >Am I alone in thinking this is a ridiculous solution to replace traditional REST endpoints? You're not alone. I went down the GraphQL path a year and a half ago. I was telling everyone it was going to be the future, then I got tired. GraphQL requires a lot of configuration and setup to get working right. The decent implementations of GraphQL are all proprietary solutions like Apollo. When you feel like you're spending half your time setting up a simple backend and API, it's a red flag. Despite efforts made to improve GraphQL, things like caching are still a nightmare are in comparison to the out-of-the-box browser caching you get with a traditional REST endpoint (because GraphQL implementations all use POST by default). No plugin I tried for Apollo gave me proper caching, I even tried to hack something together at one point. The smaller payloads are definitely great and being able to query for specific pieces of data is fantastic, but it's a lot of work and it's not perfect. I found using it can make a simple app incredibly complex, then you have to maintain the schemas, implementing data loaders requires some work to get done right. There is a reason a lot of backend developers push back against the suggestion of using GraphQL. Don't get me started on things like authentication, file uploads and protecting your server from being DDoSed or driving up your cloud computing bill by someone creating expensive queries. There are solutions to these things, but they require more configuration and work to get right. The fact out-of-the-box someone can create a GraphQL server and essentially make themselves vulnerable to a big AWS bill or have their app brought to its knees trying to fulfill an intentionally complicated query is kind of concerning, these things should be default settings. I went back to REST about six months ago and never looked back. |