This article sums up my experience with GraphQL perfectly. I was an early adopter back in the mid 2010s, and I was all over it for a while but quickly ran into pretty much every downside the...
This article sums up my experience with GraphQL perfectly. I was an early adopter back in the mid 2010s, and I was all over it for a while but quickly ran into pretty much every downside the author covers. I'm back to plain old REST API stuff in all my projects now.
A lot of my dev friends went deep into GraphQL and I tried it... and I immediately went back to writing REST. GraphQL just seemed like such a perverse security issue and while the systems...
A lot of my dev friends went deep into GraphQL and I tried it... and I immediately went back to writing REST. GraphQL just seemed like such a perverse security issue and while the systems community is going hard (rightfully) into type-safe development, the webdev community decided to leave all requirements alone and let open-ended search queries into the service.
I am also all for open-source development, but for many reasons I am not particularly fond of allowing anyone to see on a plain surface my internal query streams (if you have source code access, great, look at it in a repo, not the web interface), I much prefer obfuscating them to an API that can do a lot more than just query and do some magic without the end user even noticing. GraphQL attempts to sidestep this onto the client which just opens so many issues, and while I am, dreadfully, a proponent of SPAs, but this is just a step to far.
I can see how cool a DSL-lite client query language can be, but I would never want to give that access to a user directly, especially with the way web-extensions can embed anything and do large brute-force payload checks from a single entry point. The security ramifications are just terrifying if you don't set up heavy guards on the backend... and then you just end up recreating REST APIs with more layers of spaghetti code for security purposes.
I'm on a tangent, sorry about that, should have probably just thrown this as a parent comment.
tl;dr: Yeah, REST APIs are cool and right. I don't see an alternative that's any better other than piping them into a websocket as a message transfer (usually JSON) to be sorted on the server, back into basically internal REST calls.
This article sums up my experience with GraphQL perfectly. I was an early adopter back in the mid 2010s, and I was all over it for a while but quickly ran into pretty much every downside the author covers. I'm back to plain old REST API stuff in all my projects now.
A lot of my dev friends went deep into GraphQL and I tried it... and I immediately went back to writing REST. GraphQL just seemed like such a perverse security issue and while the systems community is going hard (rightfully) into type-safe development, the webdev community decided to leave all requirements alone and let open-ended search queries into the service.
I am also all for open-source development, but for many reasons I am not particularly fond of allowing anyone to see on a plain surface my internal query streams (if you have source code access, great, look at it in a repo, not the web interface), I much prefer obfuscating them to an API that can do a lot more than just query and do some magic without the end user even noticing. GraphQL attempts to sidestep this onto the client which just opens so many issues, and while I am, dreadfully, a proponent of SPAs, but this is just a step to far.
I can see how cool a DSL-lite client query language can be, but I would never want to give that access to a user directly, especially with the way web-extensions can embed anything and do large brute-force payload checks from a single entry point. The security ramifications are just terrifying if you don't set up heavy guards on the backend... and then you just end up recreating REST APIs with more layers of spaghetti code for security purposes.
I'm on a tangent, sorry about that, should have probably just thrown this as a parent comment.
tl;dr: Yeah, REST APIs are cool and right. I don't see an alternative that's any better other than piping them into a websocket as a message transfer (usually JSON) to be sorted on the server, back into basically internal REST calls.