No, and thinking in absolutes like this is what green lights extreme flexibility exposed to the public internet.
In general, all query possibilities from the public internet should be accountable and eagerly tested/auditable. And don't let complaints about stodgy seniors or flexibility make you do otherwise, development efficiency and tight public internet predictability are not mutually exclusive.
Again, to put it simply, it is very rare to need extreme flexibility in publicly accessible APIs. And articles like this one foolishly refuse to make that clear. In the meantime, super flexible data access schemes are lauded for their help to client side developers, scary. The org can be tightly integrated, don't let the ridiculous idea of having some devs not allowed to do any server side code force these loose-lipped systems on your users.
No.
> How are you generating that list of queries?
I believe the queries in the device UI code are replaced with identifying hashes as part of the build and those prebaked queries are deployed to the GraphQL server.
> Unless the surface is sufficiently small at which point no prob, my issue is with flexible GraphQL systems.
This is still as flexible for UI developers since this is simply a build time optimization / limitation.
For publicly accessible GraphQL APIs I believe the common approach is to calculate a cost for the query and limit what users / queries can do that way.
But for that common approach for APIs you mention, that cost calculator is a bit scary vs limiting the caller. Now if you're a big shop and you need to essentially expose a query language, ok. But for most, the flexibility is really not necessary and bites later with all the possible combinations of requests.
If it's a few lines of configuration in GraphQL, it's going to be a few lines of configuration or code in the "traditional MVC framework".
If it's a lot of code in the "traditional MVC framework", then it's going to be a lot of code in GraphQL as well.
The issue with using terms like "traditional MVC framework" is that you will have a hard time making statements that apply to all.
> That's a slippery slope leading towards a culture where nothing ever gets done because all the senior engineers default to saying "no" to everything
They can just say no to GraphQL then. You shouldn't be mixing culture/politics and technology arguments in one context.
…assuming the presence of the equivalent of a complete enough SQL engine in the server, and often not even then, because adding a new stored procedure that can be called may mean extensive rethinking of the indexes you maintain, the way tables are partitioned, etc.
So assuming the feature is going to get built, the implementation might involve sticking the extra attributes in an existing route, or might involve creating a new custom route just for this use. Both of these options have pro's and cons that need to be weighed in the given situation based on usage patterns. And both are possible with or without GraphQL. But they should require just a few lines of configuration in GraphQL vs more lines custom boilerplate code in your controller in a traditional MVC framework, which is a nice win for GraphQL.
The problems can arise whenever people start thinking some tool is basically magic where there's no wrong way to use it and it'll solve all your problems, instead of thinking criticially about how to use the tool and what tradeoffs involved. And this tends to happen much more easily with a hot, new tool like GraphQL than a more established one where people have more experience with the downsides.