In true JavaScript fashion, I decided to learn PHP again by building a framework to put all the pieces together in my brain.
I absolutely love Hono.dev, and decided to base the PHP framework on that. Dumbo isn't intended to compete with Laravel, Symphony or Slim, if anything, it's something people can use in production, but also contribute to and be used as a learning resource for others.
e.g the market was wrong on graphQL.
btw Hono is cool, but found the api surface area insufficient for my node.js usecases.
I ask a a REST turned GraphQL advocate to be clear but criticisms I hear tend to be opinions or issues with specific implementations but not ones based on the technical shortcomings of the technology
None of that is inherent to the technology but it’s a common folly among developers. This is an issue with REST too but it can be more obfuscated
This isn’t a technical issue with GraphQL. It’s a culture issue among developers who shoehorn GraphQL and don’t use it appropriately
As someone who works on very database intense application GraphQL saves me more work than its ever caused.
That is a good implementation of it, called GraphQL Yoga[0]
However I'm concerned there is a slight disconnect here. I'm saying that the technical specification of GraphQL does not lend itself to being bad, rather its the failure of developers to really understand its purpose and what its for (its a giant aggregator, with various ways to optimally aggregate things together, depending on what is optimal for a given problem set)
For that, I recommend becoming more familiar with the specification itself[1] because thats what I'm talking about. The specification (and thus its technical nature) doesn't prescribe anything regarding how you get data on to the graph. Many people equate GraphQL with database problems[2]
This doesn't mean I don't understand that GraphQL has shortcomings, but all approaches to APIs have short comings. I have found GraphQL has the least amount
[0]: https://github.com/dotansimha/graphql-yoga
[2]: Common complaint I see all the time. I find it stems from a failure to understand how the entirety of GraphQL is meant to work, and some of the mechanics within. Like when to appropriately leverage DataLoader[3], for instance.
I prefer it over SOAP, but I think it's far too easy to ignore:
N+1 issues
Security (found that we had our entire schema open including internal data routes at my last job), also we had to refactor from patients being company -> patient to company -> pharmacy -> patient... that was fun
Overcomplicating resolvers
Not implementing pagination upfront
Dead end schema designs, since you need to plan much further ahead it really hurts when you mess it up. In REST you can make a V2 of a route and move on. Especially since many people ignore modules at first. Even large corporations get stuck with UserEntity_V2, updateUser_V2.
IMO if you are going "wow if only we had GraphQL" and your team only knows REST you are always better off improving your REST tooling and standards. For example, when adding a new entity/resource you can just plan to understand how your own teams intend to query for this data, rather than guessing with GraphQL or implementing every search pattern.
By your own admission it’s sloppy developer work that causes issues it’s not the tech.
REST APIs actually do have an inherent problem, which is they’re one call == one source. Everything has to be bespoke to the endpoint, where as GraphQL as a technology allows one to not have to do that.
Versioning APIs is a code smell. With GraphQL you can combine queries by using Fragments for example. You could also perform concurrent resolution with resolvers and merge data results if if it’s appropriate for the scenario to resolve a single query. There is far more flexibility in the model but you as a developer are 100% in charge of performance and such, no different than REST. GraphQL gives far more flexibility in finding a solution for any given scenario, where as REST is an extremely rigid 1 == 1 resource coupling.
As for pagination isn’t built into REST. Anything “standard” about that was bolted on and varies quite a lot. Where as GraphQL does address this[0] on an implementation reference level.
Regarding exposing schema, while I question if there is the security risk you're implying it to be (lots of organizations expose their GraphQL schemas, like Salesforce and GitHub) but never the less, any good implementation will have a single line option for turning it off. Apollo does (arguably the most popular of the implementations) but so does GraphQL Yoga and even implementations in other languages.
As far as developers go, the biggest mistake developers make is creating schema that is simply a clone of their database schema at the end of the day, and this is the absolute worst way to go about implementing GraphQL. Its explicit purpose is to have a middle layer that lets you express APIs for intended purpose, not to be coupled to your database schema
Ideally, a technology needs to solve as many problems as possible while introducing as few problems as possible. That is why I am not sure every organization should use GraphQL.
If someone came to me from an SMB and asked "should we switch to GraphQL" I would first ask what problems they have, and what they believe GraphQL will solve. Then make an informed decision, the answer is not "yes, you should always use GraphQL".
REST has at least 1 inherent flaw in its model, which is 1-1 API resource coupling.
Now, if we want to talk about perhaps skill threshold? Yeah, GraphQL requires a higher level of confidence and experience to use correctly.