5 ms·

Maybe this is a dumb observation but at this point whats the point of even having a backend or graphql (except for maybe authentication). If you are mapping the

Maybe this is a dumb observation but at this point whats the point of even having a backend or graphql (except for maybe authentication). If you are mapping the graphql to sql why not just send direct sql commands. If you arent adding anything extra whats the point of even using it. Just query SQL from frontend

theogravity 4y ago
Because sometimes writing the equiv SQL can be a pain in the ass. Pagination is such an example. PostGraphile does a good job of it that I don't need to reason about it.
FrancoisBosun 4y ago
This is called PostgREST: https://postgrest.org/ https://postgrest.org/. Never used it in production, but PostgREST leverages multiple PostgreSQL features: row-based security, schemas, authorizations, etc. I quite like PostgREST, and I'd use it for internal stuff.
- spoiler 4y ago
  We used PostgREST in a project at my previous company, and it's the most horrendous thing imaginable. The project is a meme in the company and nobody wants to work on it, including its author (who decided to switch teams becaus of how much he hated it). I don't know if this was because of PostgREST or because all the logic was encoded in grotesque looking SQL that nobody understood (and changing some things requires dropping and readding things). It is an extremely cool project, don't get me wrong, but it's one of those things that's "I know this already and I'll use it for a weekend/poc project to not deal with writing a backend" and not for something important. And again, I don't know if this was just poor usage or something that manifests itself in every project that relies on it. Also the DSL is very much it's own thing, so migrating away from it is painful, especially if you inherited the project and don't want to read the document. But again, sample size is 1, so it's anecdotal.
  - nick__m 4y ago
    I tried PostgREST for a small internal and it was a decent experience. I followed the following rules: 1- Don't expose your real database but expose a database consisting of view on your real database so you can refactor. 2- Wrap your bussines logic in stored proc to keep your sql readable 3- Use jwt for authentication That said, I would not recommend it for a large scale application. I consider it, maybe wrongly, as the MSAccess of the backend.
ricardobeat 4y ago
GraphQL is the extra. It's usually a lot easier to reason about a graphQL query and the necessary data for a frontend component, than to write a one-off SQL query for the same purpose.
mdaniel 4y ago
There are existing frontend tools that can compose GraphQL but only string builders can compose SQL, AFAIK; it also seems to act as a "paper over the underlying database specifics" by using what seems to be MongoDB-esque criteria: https://github.com/dosco/graphjin/wiki/Guide-to-GraphQL#other-conditions https://github.com/dosco/graphjin/wiki/Guide-to-GraphQL#othe... meaning the consumer need not know the postgres-vs-mysql-isms (in theory, of course) Also, don't overlook the whiz-bang of the GraphQL introspection tooling -- it's super handy for just kicking the tires on something in ways that "dump the SQL schema to the browser" likely wouldn't do The related pg_graphql posted a while back (https://news.ycombinator.com/item?id=29430720 https://news.ycombinator.com/item?id=29430720) actually mentions GraphJin positively, and talks about a bunch of competing implementations, although it's not one-to-one with GraphJin because it seems to support mysql whereas pg_graphql is of course a PG extension
- cyanydeez 4y ago
  The iql tool is pretty amazing for coding up a query and intro.
- gsvclass 4y ago
  Also GraphJin is the only one built in Go and therefore can be used as a library within your own Go app allowing you to use it while also adding any business logic you might need.
siva7 4y ago
oh boy we got to the point were we’re wondering why we need a „backend“ anymore
nawgz 4y ago
In my opinion GraphQL is operating on an entirely different level to SQL in one meaningful way: manipulating structured data Manipulating rows in SQL is easy but doing nested joins and trying to represent one-to-many relationships correctly in the response is non trivial. I would say you have to be good at SQL to leverage the DB to make structured data, returning tables and rows is entry level. In GraphQL on the other hand, it’s seamless / entry-level to query for nested data and represent it really semantically, which is very appealing when doing presentational work (read: UIs, I suppose). Therefore, the purpose of constructs like this is to allow those working on the presentational layer to be able to construct queries for semantic, structured data themselves with no requirement for SQL / backend expertise. This is a pretty meaningful improvement to unblocking development for both sides of the stack, in my opinion, and is why I apply Hasura everywhere I can.
_query 4y ago
This is basically the idea behind [Thin Backend](https://thin.dev/ https://thin.dev/). Instead of exposing raw SQL strings we have a few high level functions to compose queries in a nice way and to do all kind of CRUD operations. These functions map 1:1 to SQL. We use a WebSocket connection to keep all queries fast. Auth is solved with row level security. It's even in the name: The backend layer is just a "thin" layer over the database. Most of the business logic is then implemented in a "rich" client/frontend.
fswd 4y ago
andrew_ 4y ago
Check out some of the generated queries this extension [1] pumps out and you might have an answer. [1] https://github.com/supabase/pg_graphql https://github.com/supabase/pg_graphql
gsvclass 4y ago
GraphJin does auto db discovery and hence builds a relationship graph which it then uses to write out a single efficient sql query for any Graphql query or mutation even nested ones. As GraphJin improves and uses new capabilities of newer versions of the db you get that for free. In the backend your query is compiled only the first time into a prepared statement and from then on requests pretty much go directly to db.

theogravity 4y ago

Because sometimes writing the equiv SQL can be a pain in the ass. Pagination is such an example. PostGraphile does a good job of it that I don't need to reason about it.

FrancoisBosun 4y ago

This is called PostgREST: https://postgrest.org/ https://postgrest.org/. Never used it in production, but PostgREST leverages multiple PostgreSQL features: row-based security, schemas, authorizations, etc. I quite like PostgREST, and I'd use it for internal stuff.

spoiler 4y ago
We used PostgREST in a project at my previous company, and it's the most horrendous thing imaginable. The project is a meme in the company and nobody wants to work on it, including its author (who decided to switch teams becaus of how much he hated it). I don't know if this was because of PostgREST or because all the logic was encoded in grotesque looking SQL that nobody understood (and changing some things requires dropping and readding things). It is an extremely cool project, don't get me wrong, but it's one of those things that's "I know this already and I'll use it for a weekend/poc project to not deal with writing a backend" and not for something important. And again, I don't know if this was just poor usage or something that manifests itself in every project that relies on it. Also the DSL is very much it's own thing, so migrating away from it is painful, especially if you inherited the project and don't want to read the document. But again, sample size is 1, so it's anecdotal.
- nick__m 4y ago
  I tried PostgREST for a small internal and it was a decent experience. I followed the following rules: 1- Don't expose your real database but expose a database consisting of view on your real database so you can refactor. 2- Wrap your bussines logic in stored proc to keep your sql readable 3- Use jwt for authentication That said, I would not recommend it for a large scale application. I consider it, maybe wrongly, as the MSAccess of the backend.

ricardobeat 4y ago

GraphQL is the extra. It's usually a lot easier to reason about a graphQL query and the necessary data for a frontend component, than to write a one-off SQL query for the same purpose.

mdaniel 4y ago

There are existing frontend tools that can compose GraphQL but only string builders can compose SQL, AFAIK; it also seems to act as a "paper over the underlying database specifics" by using what seems to be MongoDB-esque criteria: https://github.com/dosco/graphjin/wiki/Guide-to-GraphQL#other-conditions https://github.com/dosco/graphjin/wiki/Guide-to-GraphQL#othe... meaning the consumer need not know the postgres-vs-mysql-isms (in theory, of course) Also, don't overlook the whiz-bang of the GraphQL introspection tooling -- it's super handy for just kicking the tires on something in ways that "dump the SQL schema to the browser" likely wouldn't do The related pg_graphql posted a while back (https://news.ycombinator.com/item?id=29430720 https://news.ycombinator.com/item?id=29430720) actually mentions GraphJin positively, and talks about a bunch of competing implementations, although it's not one-to-one with GraphJin because it seems to support mysql whereas pg_graphql is of course a PG extension

cyanydeez 4y ago
The iql tool is pretty amazing for coding up a query and intro.
gsvclass 4y ago
Also GraphJin is the only one built in Go and therefore can be used as a library within your own Go app allowing you to use it while also adding any business logic you might need.

siva7 4y ago

oh boy we got to the point were we’re wondering why we need a „backend“ anymore

nawgz 4y ago

In my opinion GraphQL is operating on an entirely different level to SQL in one meaningful way: manipulating structured data Manipulating rows in SQL is easy but doing nested joins and trying to represent one-to-many relationships correctly in the response is non trivial. I would say you have to be good at SQL to leverage the DB to make structured data, returning tables and rows is entry level. In GraphQL on the other hand, it’s seamless / entry-level to query for nested data and represent it really semantically, which is very appealing when doing presentational work (read: UIs, I suppose). Therefore, the purpose of constructs like this is to allow those working on the presentational layer to be able to construct queries for semantic, structured data themselves with no requirement for SQL / backend expertise. This is a pretty meaningful improvement to unblocking development for both sides of the stack, in my opinion, and is why I apply Hasura everywhere I can.

_query 4y ago

This is basically the idea behind [Thin Backend](https://thin.dev/ https://thin.dev/). Instead of exposing raw SQL strings we have a few high level functions to compose queries in a nice way and to do all kind of CRUD operations. These functions map 1:1 to SQL. We use a WebSocket connection to keep all queries fast. Auth is solved with row level security. It's even in the name: The backend layer is just a "thin" layer over the database. Most of the business logic is then implemented in a "rich" client/frontend.

fswd 4y ago

andrew_ 4y ago

Check out some of the generated queries this extension [1] pumps out and you might have an answer. [1] https://github.com/supabase/pg_graphql https://github.com/supabase/pg_graphql

gsvclass 4y ago

GraphJin does auto db discovery and hence builds a relationship graph which it then uses to write out a single efficient sql query for any Graphql query or mutation even nested ones. As GraphJin improves and uses new capabilities of newer versions of the db you get that for free. In the backend your query is compiled only the first time into a prepared statement and from then on requests pretty much go directly to db.