3 ms·

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

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

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.