4 ms·

None of these problems are GraphQL-specific though. Say someone wants to build a feature that requires some attribute or joined model we weren't exposing before

None of these problems are GraphQL-specific though. Say someone wants to build a feature that requires some attribute or joined model we weren't exposing before. Maybe someone else tells them no for all the caching/performance/complexity reasons mentioned above. 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, which isn't a place people want to work and probably isn't great for the longterm outlook of the company. 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.

kodablah 8y ago
> 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, which isn't a place people want to work and probably isn't great for the longterm outlook of the company. 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.
- foota 8y ago
  There are graph ql build systems where you can generate a list of queries used on the frontend, which should help with your concerns over total flexibility, while still allowing easier use of new queries.
  - kodablah 8y ago
    If the frontend can use the API, can I, the guy with a curl command or headless browser, use it too? How are you generating that list of queries from my machine? Unless the surface is sufficiently small to get all permutations at which point no prob, my issue is with flexible GraphQL systems.
    - laurencerowe 8y ago
      > If the frontend can use the API, can I, the guy with a curl command or headless browser, use it too? 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.
      - kodablah 8y ago
        In the case of turning flexibility at compile time to a fixed set at runtime and the server side only accepts that fixed set, I'd say that's definitely a lot less of a concern than the literal GraphQL queries I've seen in use at runtime by UIs. At that point, your only major concern is how many of those devs use those sans review by person familiar with the storage that could optimize it. After that, your fixed hash request hasn't improved things from a runtime standpoint over a fixed URL request. The disappointing internal team segregation that makes this a required path to go from actual query and programming languages to pseudo ones is concerning. 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.
voidr 8y ago
> 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. 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.
Someone 8y ago
”But they should require just a few lines of configuration in GraphQL” …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.

kodablah 8y ago

> 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, which isn't a place people want to work and probably isn't great for the longterm outlook of the company. 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.

foota 8y ago
There are graph ql build systems where you can generate a list of queries used on the frontend, which should help with your concerns over total flexibility, while still allowing easier use of new queries.
- kodablah 8y ago
  If the frontend can use the API, can I, the guy with a curl command or headless browser, use it too? How are you generating that list of queries from my machine? Unless the surface is sufficiently small to get all permutations at which point no prob, my issue is with flexible GraphQL systems.
  - laurencerowe 8y ago
    > If the frontend can use the API, can I, the guy with a curl command or headless browser, use it too? 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.
    - kodablah 8y ago
      In the case of turning flexibility at compile time to a fixed set at runtime and the server side only accepts that fixed set, I'd say that's definitely a lot less of a concern than the literal GraphQL queries I've seen in use at runtime by UIs. At that point, your only major concern is how many of those devs use those sans review by person familiar with the storage that could optimize it. After that, your fixed hash request hasn't improved things from a runtime standpoint over a fixed URL request. The disappointing internal team segregation that makes this a required path to go from actual query and programming languages to pseudo ones is concerning. 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.

voidr 8y ago

> 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. 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.

Someone 8y ago

”But they should require just a few lines of configuration in GraphQL” …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.