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.
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.
However, if your GraphQL endpoint is used by consumer/public/external clients I feel like we need to give everyone permission to make a Schema matching the View Model, not the Model (proper). In practice GraphQL works quite nicely as a layer to translate the model proper into the view model. This makes MVVM much more attractive for SPA's than in object->relational worlds prior.
See: https://github.com/apollographql/apollo-link-persisted-queri... https://blog.apollographql.com/improve-graphql-performance-w...
Caching per user is still going to mean tons of cache misses. Caching based on the query hash means you're going to cache subsets of the same data over and over as separate entries.
With resources over HTTP, you can separate the user specific part from the generic resource part and cache accordingly.
Plus, I like the option of caching somewhere else than the app server, like a distributed Varnish.
I'm not saying you can't cache with graphQL, it's just less natural and mature.
Security doesn’t seem like a problem unique to GraphQL. Traditional REST APIs also need to be just as careful about authentication and access control.
Rarely good enough and in general a dangerous mindset that just adding layers around is an acceptable solution to essentially giving the world a query builder (internal use only is different of course).
> Security doesn’t seem like a problem unique to GraphQL
It's about surface area of permutations as much as the data. Sure you can auth property paths, but many GraphQL setups can be gamed by malicious callers to strain systems in ways you never expected those client side devs to do when you gave it to them. If the only reason for this flexibility is because they can't be bothered to do a bit of server side tailoring, you have a dev fragmentation problem and a vertical integration problem that will cause security concerns one day anyways.
That's baloney. GraphQL can have just as locked down code paths as any non-GraphQL API. Facebook does exactly this.
That you can do it right is not at issue, it's whether you do, and over time IME it's unaudited data proliferation and even when data is controlled, often unaudited permutations of all the possible queries that can be built.
For example the Github GraphQL API has a restriction on the amount of nodes an unauthenticated requests can query. Because of the deterministic nature you know the query complexity before execution time.
As a result you can come up with simple to implement mechanisms for restricting query complexity. This is far superior to any mechanism I have ever seen in REST APIs which are inherently far more restrictive because of the limitations of the design and much harder to predict. e.g. it's easy to exploit O(N) DOS type attacks in REST APIs that expose queries that are relational.
GraphQL supersedes REST in every way. For those who haven't realized that yet are simply missing context or experience.
What is false? Who said anything about determinism? Unless by deterministic you mean the ability to tell the future about what will be called. I'm talking about giving clients the flexibility instead of having predictability in the call. I'm saying that flexibility has costs especially as systems grow. It's not just GraphQL, lots of systems that are essentially query languages serialized to HTTP requests have this problem. Whether, once you know the call it's deterministic, or whether you can theoretically map all permutations doesn't absolve the practice of giving the clients so much free will.
I've seen so many times GraphQL implementations or ad-hoc equivalents with user supplied property and filter requests, that regret giving the caller so much flexibility. IME, flexibility is a bad thing because in the API world, often once you cross a feature bridge, there's no going back. I say be very restrictive in your API for many reasons. And for that UI use case, I disagree with a complete client-side/server-side dev separation. Unlike data APIs, backend data requests for frontend use should be tightly tailored to what is used. GraphQL is just another way to forget what you've exposed and also allow clients to hit never before seen code paths to your backend. There are security, bloat, and maintenance concerns...keep the UI backend thin and light and inflexible and strict and limited yet agile and volatile and you'll be so happy you did a couple years down the road.