3 ms·

> Are there other reasons this hasn't seen more widespread adoption? This approach had widespread adoption in the 1990's, most notably via PowerBuilder[0]. >

> Are there other reasons this hasn't seen more widespread adoption? This approach had widespread adoption in the 1990's, most notably via PowerBuilder[0]. > Is there some inherent architectural flaw or just not enough incremental benefit? Yes, there is an inherent architectural flaw with two-tiered systems in that they force a system to choose to place complexity either in the GUI or in the RDBMS. This often leads to "Jenga Programming" maintenance techniques which cause the code base to take a life of its own. It turns out that this does not scale. 0 - https://en.wikipedia.org/wiki/PowerBuilder#History https://en.wikipedia.org/wiki/PowerBuilder#History

ruslan_talpa 7y ago
Why do you think this is a two tier system? Even here [1] i count 4 places to put logic into besides frontend 1. https://github.com/subzerocloud/postgrest-starter-kit/blob/master/README.md https://github.com/subzerocloud/postgrest-starter-kit/blob/m...
- AdieuToLogic 7y ago
  > Why do you think this is a two tier system? The first sentence of site reads thusly: > PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. If there is a database on one end and a client on the other, with no intervening system between them, that is the definition of a two-tiered system.
  - ruslan_talpa 7y ago
    Sure you can use it as two tier if that does the job but it does not mean you are forced to, you can very well have logic in the proxy layer and then have logic below the db layer (workers reacting to database changes). If i apply the same logic (two tier bad) that i can say every other way of building an api is two tier since you have the frontend and then the rest of the code in php/node... the db would not really count as a later since in those scenatios ppl use it as a dumb store
    - AdieuToLogic 7y ago
      > Sure you can use it as two tier if that does the job but it does not mean you are forced to ... The project home page declares this to be its raison d'être. > ... you can very well have logic in the proxy layer and then have logic below the db layer ... Why have a "proxy layer" to "then have logic below the db layer"? Why not just let PostgreSQL manage the data and have... wait for it... A system which defines the application logic? I mean, that is what you described in a roundabout way. > If i apply the same logic (two tier bad) that i can say every other way of building an api is two tier since you have the frontend and then the rest of the code in php/node... the db would not really count as a later since in those scenatios ppl use it as a dumb store No, what you describe as "an api" (which assumes an external client that interacts with it) and "then the rest of the code" (which is colloquially known as application logic) using PostgreSQL (what you call "a dumb store"), is known in the industry as a "three-tiered system." Not a "two-tiered" system. This is because there are three significant actors involved in system operations: 1 - something that requests the service provided (browser, phone, desktop binary, etc.). 2 - something that provides the service (application logic). 3 - something that persists relevant state as determined by #2. See what happened there? Three distinct things; a client, something that does stuff, and something that stores stuff.
steve-chavez 7y ago
PostgREST's approach is not like PowerBuilder's. PowerBuilder didn't encourage you to know your DB ins-and-outs and use all of its features. It was DB agnostic and through its DataWindow you got a RAD way of doing CRUD for a desktop app but you still needed to add application logic in PowerScript. PostgREST on the other hand pushes you to know PostgreSQL. A more suitable analogy would be to something like Oracle Apex[1]. [1]:https://en.wikipedia.org/wiki/Oracle_Application_Express https://en.wikipedia.org/wiki/Oracle_Application_Express
- AdieuToLogic 7y ago
  > PostgREST's approach is not like PowerBuilder's. My intent was not to equate PostgREST with PowerBuilder, but instead to use the latter as a well-known example of a two-tier system. > PowerBuilder didn't encourage you to know your DB ins-and-outs and use all of its features. While PowerBuilder was "DB agnostic", as you identified, non-trivial applications relied heavily on RDBMS logic (stored procs, views, etc.). So while PB may not have "encouraged" RDBMS specific implementations, those which I encountered were never without. Granted, the client connection protocol vastly differs between the two offerings. Yet the system architecture is shared IMHO.

ruslan_talpa 7y ago

Why do you think this is a two tier system? Even here [1] i count 4 places to put logic into besides frontend 1. https://github.com/subzerocloud/postgrest-starter-kit/blob/master/README.md https://github.com/subzerocloud/postgrest-starter-kit/blob/m...

AdieuToLogic 7y ago
> Why do you think this is a two tier system? The first sentence of site reads thusly: > PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. If there is a database on one end and a client on the other, with no intervening system between them, that is the definition of a two-tiered system.
- ruslan_talpa 7y ago
  Sure you can use it as two tier if that does the job but it does not mean you are forced to, you can very well have logic in the proxy layer and then have logic below the db layer (workers reacting to database changes). If i apply the same logic (two tier bad) that i can say every other way of building an api is two tier since you have the frontend and then the rest of the code in php/node... the db would not really count as a later since in those scenatios ppl use it as a dumb store
  - AdieuToLogic 7y ago
    > Sure you can use it as two tier if that does the job but it does not mean you are forced to ... The project home page declares this to be its raison d'être. > ... you can very well have logic in the proxy layer and then have logic below the db layer ... Why have a "proxy layer" to "then have logic below the db layer"? Why not just let PostgreSQL manage the data and have... wait for it... A system which defines the application logic? I mean, that is what you described in a roundabout way. > If i apply the same logic (two tier bad) that i can say every other way of building an api is two tier since you have the frontend and then the rest of the code in php/node... the db would not really count as a later since in those scenatios ppl use it as a dumb store No, what you describe as "an api" (which assumes an external client that interacts with it) and "then the rest of the code" (which is colloquially known as application logic) using PostgreSQL (what you call "a dumb store"), is known in the industry as a "three-tiered system." Not a "two-tiered" system. This is because there are three significant actors involved in system operations: 1 - something that requests the service provided (browser, phone, desktop binary, etc.). 2 - something that provides the service (application logic). 3 - something that persists relevant state as determined by #2. See what happened there? Three distinct things; a client, something that does stuff, and something that stores stuff.

steve-chavez 7y ago

PostgREST's approach is not like PowerBuilder's. PowerBuilder didn't encourage you to know your DB ins-and-outs and use all of its features. It was DB agnostic and through its DataWindow you got a RAD way of doing CRUD for a desktop app but you still needed to add application logic in PowerScript. PostgREST on the other hand pushes you to know PostgreSQL. A more suitable analogy would be to something like Oracle Apex[1]. [1]:https://en.wikipedia.org/wiki/Oracle_Application_Express https://en.wikipedia.org/wiki/Oracle_Application_Express

AdieuToLogic 7y ago
> PostgREST's approach is not like PowerBuilder's. My intent was not to equate PostgREST with PowerBuilder, but instead to use the latter as a well-known example of a two-tier system. > PowerBuilder didn't encourage you to know your DB ins-and-outs and use all of its features. While PowerBuilder was "DB agnostic", as you identified, non-trivial applications relied heavily on RDBMS logic (stored procs, views, etc.). So while PB may not have "encouraged" RDBMS specific implementations, those which I encountered were never without. Granted, the client connection protocol vastly differs between the two offerings. Yet the system architecture is shared IMHO.