3 ms·

The author makes a case for just sending sql queries from the frontend. For public APIs you can probably make a case. But for a normal application it doesn't ma

by kabes 7y ago

The author makes a case for just sending sql queries from the frontend. For public APIs you can probably make a case. But for a normal application it doesn't make much sense. You only have a fixed amount of queries to run. So why would you implement the hassle and huge exploit surface of validating queries from the frontend. So once you realize this, you'll just give every query some identifier and send the identifier + some parameters instead of the query. Et voila, you have created RPC

lilyball 7y ago
Because the "frontend" might be a native application that can't be updated on the fly and would break when the query changes out from under it. Or maybe it's a web app anyway but people have the web app open while you're deploying the new version, and their old instance of the web app starts getting responses back it doesn't understand. You'd have to do something like change the identifier (or add a version number to it) every time you modify the query, and retain all of the old query versions as well. The argument the author is making is that you expose a carefully designed read-only view, not your whole database, so it doesn't really matter what queries the frontend sends as long as they stay within your resource quota. No validation necessary. But of course as with the identifier approach, you can't remove or change columns in your view if you have any clients querying it that aren't guaranteed to receive live updates to their code. But in a sense that's just like GraphQL, where you have to be careful to keep all of your changes backwards-compatible if you don't want to break older clients.
- tcgv 7y ago
  > Because the "frontend" might be a native application that can't be updated on the fly and would break when the query changes out from under it. From my experience that would be an extremely naive decision to make: change the underlying behavior of an API endpoint with disregard for its impact on client apps. Backwards compatibility and API versioning strategies can easily handle this kind of situation.
  - lilyball 7y ago
    > From my experience that would be an extremely naive decision to make: change the underlying behavior of an API endpoint with disregard for its impact on client apps. Which is precisely one of the reasons GraphQL exists, so you can change the data queryable in your API without changing the data existing clients receive. If we're talking about moving from GraphQL to SQL then we shouldn't be throwing away this capability. What's more, if we just offer a set of pre-baked queries, there's no way to measure how many clients are actually using a given column in the query. If we're the developer of both the frontend and backend then we can try to keep track of it internally, and rev the identifiers with each change so we can determine when a given query is no longer being used by any clients. But this requires a lot of bookkeeping internally (e.g. your mobile team bothers to let you know that they're no longer using a given column) and doesn't work at all if you're vending this API to third parties. If you vend a view, then you could track which columns of your view are actually being used by queries, and once a given column is no longer being used by anyone you can remove it (e.g. because you added a new column that obsoletes it). Though there's no formal way to deprecate the column in order to move people off of it, so that's a step backwards from GraphQL.
    - brillout 7y ago
      > Which is precisely one of the reasons GraphQL exists, so you can change the data queryable in your API without changing the data existing clients receive. If we're talking about moving from GraphQL to SQL then we shouldn't be throwing away this capability. If you many different clients consuming the API then yes it makes sense. But if you have only one client (usually a modern frontend or a mobile app) and you can deploy client+backend at the same time, than you don't need that anymore. You can then use RPC without much of a drawback.
      - lilyball 7y ago
        You can't deploy a mobile app at the same time as your backend. Even if publishing a mobile app update was instantaneous, it takes time for people to update, and some people never will.
  - 7y ago
fizx 7y ago
There's a difference if the client developers can register stored procedures. Typically, you can't do that with RPC, and it's a big value-add of GraphQL. If that happens, then SQL and GraphQL look a lot alike. SQL would be more powerful, which also means that it'd probably be somewhat harder to implement, though there are so many SQL engines existing. I can't imagine people implementing from scratch. I can't wait for Hasura SQL-to-GraphQL-to-SQL.
- tango12 7y ago
  Believe it or not, but it has come up in a bunch of conversations with enterprise users! :) Can you do everything you do with graphql, but also with sql?
throw_m239339 7y ago
Furthermore, your "view models", whether their are displayed as json payload or transformed through HTML templating server-side are not and should not be your "database models". This is to me where just using SQL from the front-end doesn't really make sense.

by kabes 7y ago

lilyball 7y ago

Because the "frontend" might be a native application that can't be updated on the fly and would break when the query changes out from under it. Or maybe it's a web app anyway but people have the web app open while you're deploying the new version, and their old instance of the web app starts getting responses back it doesn't understand. You'd have to do something like change the identifier (or add a version number to it) every time you modify the query, and retain all of the old query versions as well. The argument the author is making is that you expose a carefully designed read-only view, not your whole database, so it doesn't really matter what queries the frontend sends as long as they stay within your resource quota. No validation necessary. But of course as with the identifier approach, you can't remove or change columns in your view if you have any clients querying it that aren't guaranteed to receive live updates to their code. But in a sense that's just like GraphQL, where you have to be careful to keep all of your changes backwards-compatible if you don't want to break older clients.

tcgv 7y ago
> Because the "frontend" might be a native application that can't be updated on the fly and would break when the query changes out from under it. From my experience that would be an extremely naive decision to make: change the underlying behavior of an API endpoint with disregard for its impact on client apps. Backwards compatibility and API versioning strategies can easily handle this kind of situation.
- lilyball 7y ago
  > From my experience that would be an extremely naive decision to make: change the underlying behavior of an API endpoint with disregard for its impact on client apps. Which is precisely one of the reasons GraphQL exists, so you can change the data queryable in your API without changing the data existing clients receive. If we're talking about moving from GraphQL to SQL then we shouldn't be throwing away this capability. What's more, if we just offer a set of pre-baked queries, there's no way to measure how many clients are actually using a given column in the query. If we're the developer of both the frontend and backend then we can try to keep track of it internally, and rev the identifiers with each change so we can determine when a given query is no longer being used by any clients. But this requires a lot of bookkeeping internally (e.g. your mobile team bothers to let you know that they're no longer using a given column) and doesn't work at all if you're vending this API to third parties. If you vend a view, then you could track which columns of your view are actually being used by queries, and once a given column is no longer being used by anyone you can remove it (e.g. because you added a new column that obsoletes it). Though there's no formal way to deprecate the column in order to move people off of it, so that's a step backwards from GraphQL.
  - brillout 7y ago
    > Which is precisely one of the reasons GraphQL exists, so you can change the data queryable in your API without changing the data existing clients receive. If we're talking about moving from GraphQL to SQL then we shouldn't be throwing away this capability. If you many different clients consuming the API then yes it makes sense. But if you have only one client (usually a modern frontend or a mobile app) and you can deploy client+backend at the same time, than you don't need that anymore. You can then use RPC without much of a drawback.
    - lilyball 7y ago
      You can't deploy a mobile app at the same time as your backend. Even if publishing a mobile app update was instantaneous, it takes time for people to update, and some people never will.
- 7y ago

fizx 7y ago

There's a difference if the client developers can register stored procedures. Typically, you can't do that with RPC, and it's a big value-add of GraphQL. If that happens, then SQL and GraphQL look a lot alike. SQL would be more powerful, which also means that it'd probably be somewhat harder to implement, though there are so many SQL engines existing. I can't imagine people implementing from scratch. I can't wait for Hasura SQL-to-GraphQL-to-SQL.

tango12 7y ago
Believe it or not, but it has come up in a bunch of conversations with enterprise users! :) Can you do everything you do with graphql, but also with sql?

throw_m239339 7y ago

Furthermore, your "view models", whether their are displayed as json payload or transformed through HTML templating server-side are not and should not be your "database models". This is to me where just using SQL from the front-end doesn't really make sense.