4 ms·

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

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.

perlgeek 11y ago
I think it's nice if you want to build some kind of web application that explores a database. I wouldn't use it a for a "normal" web app, for exactly the reasons you state.
- jawr 11y ago
  I had this initial response, but you can have another service running tasks on and in to the database, or more complicated views for interacting with more complex models. PostgREST is just a service for interacting with your data, logic has to be done client side/in another service.
  - CloudLeaper 11y ago
    So my server side code will now become a collection of triggers, views etc? That doesn't sound too appealing.
    - jawr 11y ago
      Writing boilerplate to turn rows in to objects is also not appealing. As with many things I suspect there is a valid use case either side.
wilsonfiifi 11y ago
One use case would be with Google App Engine. Other than it's Datastore [0] or CloudSQL [1], you don't have access to other databases. So this would be a great way to have Postgresql as a backend to your app. [0] https://cloud.google.com/appengine/articles/datastore/overview https://cloud.google.com/appengine/articles/datastore/overvi... [1] https://cloud.google.com/sql/docs/introduction https://cloud.google.com/sql/docs/introduction
fulafel 11y ago
You implement any custom logic in PostgreSQL mechanisms (permissions, triggers, constraints, views, stored procedures etc).
- cube00 11y ago
  ...and be locked in for life, joy.
  - jeena 11y ago
    How are you not locked in by Ruby on Rails if you chose to use it for your business logic? With the disadvantage of it being really slow.
  - bdcravens 11y ago
    Is it a common circumstance to completely switch your data layer without having a massive rewrite of your application? Do people frequently flip from pg to Oracle, or from SQL Server to MongoDB, and it was super-easy because that layer was abstracted?
    - deleted 11y ago
      [deleted]
    - markbernard 11y ago
      Not frequently, but yes. Was forced to move from Oracle to Postgres, not that I mind Postgres. Very little software changes were required to get up and running. If everything was in views or stored procedures the change would have taken months instead of weeks.
      - CHY872 11y ago
        On the other hand, I had to write for some software that supported both Oracle and Postgres (many deployments, new using Postgres and old migrating over time to Postgres) and it was a chore. All tests had to be run in both, SQL was 'same but different' with different types, and for perf reasons there was tonnes of hinting, which obviously pg ignores so overall performance was very different.
y0ghur7_xxx 11y ago
> I can't think of many apps that don't require custom logic between receiving an API request and persisting something to the database. 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.

perlgeek 11y ago

I think it's nice if you want to build some kind of web application that explores a database. I wouldn't use it a for a "normal" web app, for exactly the reasons you state.

jawr 11y ago
I had this initial response, but you can have another service running tasks on and in to the database, or more complicated views for interacting with more complex models. PostgREST is just a service for interacting with your data, logic has to be done client side/in another service.
- CloudLeaper 11y ago
  So my server side code will now become a collection of triggers, views etc? That doesn't sound too appealing.
  - jawr 11y ago
    Writing boilerplate to turn rows in to objects is also not appealing. As with many things I suspect there is a valid use case either side.

wilsonfiifi 11y ago

One use case would be with Google App Engine. Other than it's Datastore [0] or CloudSQL [1], you don't have access to other databases. So this would be a great way to have Postgresql as a backend to your app. [0] https://cloud.google.com/appengine/articles/datastore/overview https://cloud.google.com/appengine/articles/datastore/overvi... [1] https://cloud.google.com/sql/docs/introduction https://cloud.google.com/sql/docs/introduction

fulafel 11y ago

You implement any custom logic in PostgreSQL mechanisms (permissions, triggers, constraints, views, stored procedures etc).

cube00 11y ago
...and be locked in for life, joy.
- jeena 11y ago
  How are you not locked in by Ruby on Rails if you chose to use it for your business logic? With the disadvantage of it being really slow.
- bdcravens 11y ago
  Is it a common circumstance to completely switch your data layer without having a massive rewrite of your application? Do people frequently flip from pg to Oracle, or from SQL Server to MongoDB, and it was super-easy because that layer was abstracted?
  - deleted 11y ago
    [deleted]
  - markbernard 11y ago
    Not frequently, but yes. Was forced to move from Oracle to Postgres, not that I mind Postgres. Very little software changes were required to get up and running. If everything was in views or stored procedures the change would have taken months instead of weeks.
    - CHY872 11y ago
      On the other hand, I had to write for some software that supported both Oracle and Postgres (many deployments, new using Postgres and old migrating over time to Postgres) and it was a chore. All tests had to be run in both, SQL was 'same but different' with different types, and for perf reasons there was tonnes of hinting, which obviously pg ignores so overall performance was very different.

y0ghur7_xxx 11y ago

> I can't think of many apps that don't require custom logic between receiving an API request and persisting something to the database. 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.