Hacker News Reader

Comment by CloudLeaper | Hacker News Reader

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.

View on HN

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

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

...and be locked in for life, joy.

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.

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?

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.

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.

> ...and be locked in for life, joy.

"The argument that you don't want to write any code that locks you to a database is some stunning lack of awareness, as you decide to lock yourself into the tsunami of unpredictability that is web frameworks to ward off the evil of being locked into a 20 year database product built on some pretty sound theoretical foundations."

https://news.ycombinator.com/item?id=9928321

The classic fear of lock-in was vendor lock-in.

Does Oracle or Sybase own Postgres? Nope.

There's nobody with a legal hand on your throat.

I have presided over a couple of to-PostgreSQL migrations but I've only heard of one away-from-PostgreSQL migration, and it was Skype when MS bought it.

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/overvi...

[1] https://cloud.google.com/sql/docs/introduction

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.

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.

So my server side code will now become a collection of triggers, views etc? That doesn't sound too appealing.

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.

Reply on news.ycombinator.com