5 ms·

Coming from a traditional layered approach I can see why this "de-layered" approach can seem wrong. After all I had to ditch the knowledge I had about Django OR

Coming from a traditional layered approach I can see why this "de-layered" approach can seem wrong. After all I had to ditch the knowledge I had about Django ORM, Sequelize, HIbernate(I wish I could forget entirely about Spring/JPA books I've read but I still remember some parts). But as mentioned in other comments if you give it 5 minutes—and embrace the db—perhaps you'd see the advantages of this approach over more traditional ones. > There is no ORM that you can control You don't need an ORM to control your database. If you treat the database as the source of truth(this would be the architecturally defined place) you can do data transformations with plain and short SQL. The great thing about this is that you can leverage PostgreSQL rich functionality and extension ecosystem and you don't have to worry if your ORM supports a pg type or if you need a plugin for that. > by sending strangely formatted HTTP requests according to the doc The "strangely formattted request" wouldn't be so strange if you note that PostgreSQL cast operator is "::"(e.g. `select col::json from table`). > Python ORM would take care of having the same performance on the database level for you. That's just false. ORMs have to point to the lowest common denominator of databases. They don't use the full potential of pg(things like LATERAL joins, json_agg, etc). PostgREST queries are specifically tailored for pg and they're being constantly improved. > No testability I've shared this before, but by using pgTAP[1] you can get native SQL tests. HNers have shared migration tools in other comments. [1]: https://pgtap.org/ https://pgtap.org/

fogetti 7y ago
This is still a horrible idea. No IDE support, no debugging support, poor language choice. It's just simply screaming NO NO NO NO NO NO NO on every level of the framework. Not to mention that these days it is more important than ever to make the code also executable in cloud environments like GCP Cloud SQL or AWS RDS. > You don't need an ORM to control your database. You are actually wrong about that and you are basically the living proof that I was right. You didn't even try to address what I was writing about object relational impedance mismatch and inheritance. > you can leverage PostgreSQL rich functionality I think this is a slightly outdated world-view. As I mentioned above these days the most important driving factors are not what a specific DB vendor supports but mostly what the cloud providers do. And many of the cool things are only supported by plugins in Postgres anyway. > you can do data transformations with plain and short SQL You guess what? You can do the same in ORMs too! In any language which has a Postgres DB driver! No one is stopping you from that.
- steve-chavez 7y ago
  > object relational impedance mismatch and inheritance Can you elaborate on that? PostgreSQL is an object-relational dbms btw, it supports inheritance[1]. Though I don't know exactly what impedance are you referring to since PostgREST doesn't use an ORM. [1]: https://www.postgresql.org/docs/12/tutorial-inheritance.html https://www.postgresql.org/docs/12/tutorial-inheritance.html
AdieuToLogic 7y ago
> Coming from a traditional layered approach I can see why this "de-layered" approach can seem wrong. One of the most significant architectural defects of this approach is by demanding the persistent store provide functionality beyond solely managing data, it both conflates disparate concerns (business logic + data management) as well as unduly complicates system evolution. > If you treat the database as the source of truth(this would be the architecturally defined place) you can do data transformations with plain and short SQL. And if you treat the database as the source of truth for managing data, then the idea of making it an application engine would be anathema.
- steve-chavez 7y ago
  > disparate concerns (business logic + data management) We argue that all "business logic" is in fact "data logic" and they're the same concern. There are several comments on this post on how to evolve this approach(only use VIEWs/sps in a single schema and expose this to clients). > And if you treat the database as the source of truth for managing data, then the idea of making it an application engine would be anathema. Why? Could you elaborate more on that?
  - AdieuToLogic 7y ago
    > > And if you treat the database as the source of truth for managing data, then the idea of making it an application engine would be anathema. > Why? Could you elaborate more on that? Sure. Your previous declaration of: > We argue that all "business logic" is in fact "data logic" and they're the same concern. Is both the source of my position and your question. For at least the last 50 years of which I am aware, the idea of "data rules all" has inextricably lead to migrating system logic closer to where the data resides. In the last 35-ish years, this meant defining application logic in stored procedures executed in an RDBMS (such as what you describe). This architectural philosophy is commonly know as "client/server", or "two-tier systems," and has been studied extensively (as I am sure you are aware). What makes this relevant to the argument found in the "Motivation" section on the PostgREST site is: Using PostgREST is an alternative to manual CRUD programming. And then: The PostgREST philosophy establishes a single declarative source of truth: the data itself. To achieve that, the logic must reside within the RDBMS in order to fulfill the project goal set forth in the very first line of the site's home page: PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. For all intents and purposes, PostgREST could be considered an RDBMS connection pool, with the connection protocol being HTTP. Note that this is not a judgement, only an observation. Now, consider a different system architecture commonly known as "three-tier" or "multi-tier." The philosophy of this type of system is largely defined by separation of concerns. This is to say, have each tier be responsible for a single "layer" involved in system definition. In multi-tier systems, the persistent store (RDBMS) is solely responsible for ensuring data integrity. It may, in fact, service disparate components as well as disparate components may use more than one persistent store. An example of the latter is PostgreSQL and Redis deployed in concert. Programs, components, and/or systems which interact with a persistent store are responsible for providing the behaviour expected by their clients whilst the persistent store is expected to enforce rules regarding the relationships it manages. Since the persistent store is only asked to fulfill a data integrity contract, having it also attempt to be an application engine would clearly conflate concerns, limit what persistent stores could be used, as well as result in assumptive implementations. Hence anathema to those who would treat the persistent store (database) as the source of truth strictly for the one concern which it was designed to address: Managing data.

fogetti 7y ago

This is still a horrible idea. No IDE support, no debugging support, poor language choice. It's just simply screaming NO NO NO NO NO NO NO on every level of the framework. Not to mention that these days it is more important than ever to make the code also executable in cloud environments like GCP Cloud SQL or AWS RDS. > You don't need an ORM to control your database. You are actually wrong about that and you are basically the living proof that I was right. You didn't even try to address what I was writing about object relational impedance mismatch and inheritance. > you can leverage PostgreSQL rich functionality I think this is a slightly outdated world-view. As I mentioned above these days the most important driving factors are not what a specific DB vendor supports but mostly what the cloud providers do. And many of the cool things are only supported by plugins in Postgres anyway. > you can do data transformations with plain and short SQL You guess what? You can do the same in ORMs too! In any language which has a Postgres DB driver! No one is stopping you from that.

steve-chavez 7y ago
> object relational impedance mismatch and inheritance Can you elaborate on that? PostgreSQL is an object-relational dbms btw, it supports inheritance[1]. Though I don't know exactly what impedance are you referring to since PostgREST doesn't use an ORM. [1]: https://www.postgresql.org/docs/12/tutorial-inheritance.html https://www.postgresql.org/docs/12/tutorial-inheritance.html

AdieuToLogic 7y ago

> Coming from a traditional layered approach I can see why this "de-layered" approach can seem wrong. One of the most significant architectural defects of this approach is by demanding the persistent store provide functionality beyond solely managing data, it both conflates disparate concerns (business logic + data management) as well as unduly complicates system evolution. > If you treat the database as the source of truth(this would be the architecturally defined place) you can do data transformations with plain and short SQL. And if you treat the database as the source of truth for managing data, then the idea of making it an application engine would be anathema.

steve-chavez 7y ago
> disparate concerns (business logic + data management) We argue that all "business logic" is in fact "data logic" and they're the same concern. There are several comments on this post on how to evolve this approach(only use VIEWs/sps in a single schema and expose this to clients). > And if you treat the database as the source of truth for managing data, then the idea of making it an application engine would be anathema. Why? Could you elaborate more on that?
- AdieuToLogic 7y ago
  > > And if you treat the database as the source of truth for managing data, then the idea of making it an application engine would be anathema. > Why? Could you elaborate more on that? Sure. Your previous declaration of: > We argue that all "business logic" is in fact "data logic" and they're the same concern. Is both the source of my position and your question. For at least the last 50 years of which I am aware, the idea of "data rules all" has inextricably lead to migrating system logic closer to where the data resides. In the last 35-ish years, this meant defining application logic in stored procedures executed in an RDBMS (such as what you describe). This architectural philosophy is commonly know as "client/server", or "two-tier systems," and has been studied extensively (as I am sure you are aware). What makes this relevant to the argument found in the "Motivation" section on the PostgREST site is: Using PostgREST is an alternative to manual CRUD programming. And then: The PostgREST philosophy establishes a single declarative source of truth: the data itself. To achieve that, the logic must reside within the RDBMS in order to fulfill the project goal set forth in the very first line of the site's home page: PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. For all intents and purposes, PostgREST could be considered an RDBMS connection pool, with the connection protocol being HTTP. Note that this is not a judgement, only an observation. Now, consider a different system architecture commonly known as "three-tier" or "multi-tier." The philosophy of this type of system is largely defined by separation of concerns. This is to say, have each tier be responsible for a single "layer" involved in system definition. In multi-tier systems, the persistent store (RDBMS) is solely responsible for ensuring data integrity. It may, in fact, service disparate components as well as disparate components may use more than one persistent store. An example of the latter is PostgreSQL and Redis deployed in concert. Programs, components, and/or systems which interact with a persistent store are responsible for providing the behaviour expected by their clients whilst the persistent store is expected to enforce rules regarding the relationships it manages. Since the persistent store is only asked to fulfill a data integrity contract, having it also attempt to be an application engine would clearly conflate concerns, limit what persistent stores could be used, as well as result in assumptive implementations. Hence anathema to those who would treat the persistent store (database) as the source of truth strictly for the one concern which it was designed to address: Managing data.