31–40 of 210 posts
I find it intriguing, but maybe I am just one generation behind and you were to say:
"Been there done that. This strong dependency on the database was really not a good idea in the long run because... "
And what happens when you start applying complex business rules that needs to scale? So many questions about this approach...
What is the use case of wrapping Postgres with REST? I can't think of many apps that don't require custom logic between receiving an API request and persisting something to the database. Is PostgREST trying to replace ORM by wrapping Postgres in REST? Or am I missing something. When would one use this tool. My naive perspective needs some enlightening.
You implement any custom logic in PostgreSQL mechanisms (permissions, triggers, constraints, views, stored procedures etc).
Could maybe somebody of the older experienced people comment whether this is a good idea? I find it intriguing, but maybe I am just one generation behind and you were to say: "Been there done that. This strong dependency on the database was really not a good idea in the long run because... "
I'm sorry but why would I go through HTTP to query data? Why can't I just hit the database directly without the overhead of HTTP? Does a cleaner and being more standards-compliant worth the overhead of passing through HTTP? And what happens when you start applying complex business rules that needs to scale? So many questions about this approach...
More here in the value of services (Yegge's rant): https://plus.google.com/+RipRowan/posts/eVeouesvaVX
Could maybe somebody of the older experienced people comment whether this is a good idea? I find it intriguing, but maybe I am just one generation behind and you were to say: "Been there done that. This strong dependency on the database was really not a good idea in the long run because... "
In my experience (and I'm older these days...) databases are a much rarer migration than programming languages. I deal with stuff that's still in (heaven help us) VSAM files, accessed a mix of assembler, COBOL, C, Java, TCL, C#, C++, Pascal, and so on and so forth.
What is the use case of wrapping Postgres with REST? I can't think of many apps that don't require custom logic between receiving an API request and persisting something to the database. Is PostgREST trying to replace ORM by wrapping Postgres in REST? Or am I missing something. When would one use this tool. My naive perspective needs some enlightening.
I do. Most apps we write (government stuff) are CRUD apps that mostly handle data from the user, and then apply some logic to that data.
You can write custom logic in stored procs no problem. It's even a lot faster than doing it in java/php/ruby/.net or whatever because there are a lot less layers between you and the data, and the procedural language you use inside the the db is explicitly made and optimized for this purpose.
Could maybe somebody of the older experienced people comment whether this is a good idea? I find it intriguing, but maybe I am just one generation behind and you were to say: "Been there done that. This strong dependency on the database was really not a good idea in the long run because... "
In the old days, DB vendor independence was considered important, because the Free databases were not considered good enough for Enterprise use. It had to be Oracle or IBM. Even if you were starting out on MySQL, you wanted to retain portability for when you moved to Oracle. Hence building ORMs as an abstraction layer allowing vendor independence and more Enterprise-y Java.
There's also the "demarcation" issue. Traditionally databases were administered by change-averse DBAs who didn't want you stealing their CPU cycles to run your stored procedures, and were generally extremely averse to change.
Earlier quoted context omitted.
You implement any custom logic in PostgreSQL mechanisms (permissions, triggers, constraints, views, stored procedures etc).
...and be locked in for life, joy.
Earlier quoted context omitted.
You implement any custom logic in PostgreSQL mechanisms (permissions, triggers, constraints, views, stored procedures etc).
...and be locked in for life, joy.