Hacker News Reader

Comment by jayd16 | Hacker News Reader

I actually think the one schema to rule them all approach is a bad one. Different parts of the stack have different use cases and require different data representations. I think it's a fundamental flaw many ORMs fall into.

As for postgrest and graphQL, queries and data transformations are proof that your DB schema shouldn't be forced the the stack and onto the clients. I would argue that graphQL strived for the exact opposite of single schema and tends to 'clients should choose their own API' approach.

View on HN

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

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.

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.

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

There's a postgres extension called plv8 that essentially allows one to write database functions in JavaScript, instead of plpgsql.

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.

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.

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

you can write your stored procedures in JS of Python if you don't like plpgsql that much :)

Reply on news.ycombinator.com