3 ms·
> 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 b
by 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 agoIn 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.