3 ms·

You haven't really looked into postgrest, it does not force the database schema on to the client. You expose a schema with views that are tailored for the front

You haven't really looked into postgrest, it does not force the database schema on to the client. You expose a schema with views that are tailored for the frontend and can be totally different from the underlying tables that hold the actual data

jayd16 7y ago
I admit I haven't but I totally agree with you. I'm attempting to say that postgrest and graphQL are _not_ examples of apis from 'a single schema definition' in that they are not the previous incarnation of that desire where an ORM would tightly couple your imperative types to your normalized schema. These new technologies have a wholistic/referential public API but they allow client, server and DB to all have different schemas and I just want to highlight the difference.
dathinab 7y ago
Yes, but the constrains sql has wrt. how you represent certain datatypes can lead to problems. Sure in postgres you can fix that by a variety of compound types, and fully new types implemented as pg extension, which can scare people of. Still there are a tone of applications for which just the basic types are good enough and the server is just a thin wrapper. In the end the main requirement for efficiency using it is you skill with not basic SQL/plpgSQL (stored procedure, trigger functions, views and knowledge about the effects of the used isolation level). All well documented in postgres.
- striking 7y ago
  > In the end the main requirement for efficiency using it is you skill with not basic SQL/plpgSQL Another way I've heard this phrased is "It's much easier to hire JS devs than PL/pgSQL devs."
  - yen223 7y ago
    There's a postgres extension called plv8 that essentially allows one to write database functions in JavaScript, instead of plpgsql.
    - striking 7y ago
      Oh, absolutely. Same with Python, Tcl, Perl... but that's not the part I'm talking about. The business logic being encoded as pgpl/* is just fine. But having to write complex triggers that wrap pgpl functions and making sure the state of the functions is as expected and all of the other wiring stuff is just not something most people are used to. I've recently seen an uptick in "Postgres-native" stuff being built, though. So maybe there's hope for the future.
  - bni 7y ago
    Yes, this is the true reason why these elegant solutions don't see so much adoption. Worse is better. Cheap JS devs to solve everything with heaps of imperative code is cheaper than elegant solutions. Even long term this is true. Tech debt with code that people can understand and modify is cheaper than tech debt with an elegant DSL that require learning and mental ability beyond if then else.
- ruslan_talpa 7y ago
  what do datatypes have to do with this. For both PostgREST and any other api layer the situation is the same. The data sits in the db/tabes (so both parties are restricted to the types available in pg) and on the other end you need to output json. The fact that you can have some "smart" internal datatypes in other api layers has 0 advanteges, both systems have to basically take data from the db and display it as json, the intermediate types are irelevant
- ruslan_talpa 7y ago
  you can write your stored procedures in JS of Python if you don't like plpgsql that much :)

jayd16 7y ago

I admit I haven't but I totally agree with you. I'm attempting to say that postgrest and graphQL are _not_ examples of apis from 'a single schema definition' in that they are not the previous incarnation of that desire where an ORM would tightly couple your imperative types to your normalized schema. These new technologies have a wholistic/referential public API but they allow client, server and DB to all have different schemas and I just want to highlight the difference.

dathinab 7y ago

Yes, but the constrains sql has wrt. how you represent certain datatypes can lead to problems. Sure in postgres you can fix that by a variety of compound types, and fully new types implemented as pg extension, which can scare people of. Still there are a tone of applications for which just the basic types are good enough and the server is just a thin wrapper. In the end the main requirement for efficiency using it is you skill with not basic SQL/plpgSQL (stored procedure, trigger functions, views and knowledge about the effects of the used isolation level). All well documented in postgres.

striking 7y ago
> In the end the main requirement for efficiency using it is you skill with not basic SQL/plpgSQL Another way I've heard this phrased is "It's much easier to hire JS devs than PL/pgSQL devs."
- yen223 7y ago
  There's a postgres extension called plv8 that essentially allows one to write database functions in JavaScript, instead of plpgsql.
  - striking 7y ago
    Oh, absolutely. Same with Python, Tcl, Perl... but that's not the part I'm talking about. The business logic being encoded as pgpl/* is just fine. But having to write complex triggers that wrap pgpl functions and making sure the state of the functions is as expected and all of the other wiring stuff is just not something most people are used to. I've recently seen an uptick in "Postgres-native" stuff being built, though. So maybe there's hope for the future.
- bni 7y ago
  Yes, this is the true reason why these elegant solutions don't see so much adoption. Worse is better. Cheap JS devs to solve everything with heaps of imperative code is cheaper than elegant solutions. Even long term this is true. Tech debt with code that people can understand and modify is cheaper than tech debt with an elegant DSL that require learning and mental ability beyond if then else.
ruslan_talpa 7y ago
what do datatypes have to do with this. For both PostgREST and any other api layer the situation is the same. The data sits in the db/tabes (so both parties are restricted to the types available in pg) and on the other end you need to output json. The fact that you can have some "smart" internal datatypes in other api layers has 0 advanteges, both systems have to basically take data from the db and display it as json, the intermediate types are irelevant
ruslan_talpa 7y ago
you can write your stored procedures in JS of Python if you don't like plpgsql that much :)