Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgREST – REST API from any PostgreSQL database

github.com

Post reply on HN
Print view View original

21–30 of 210 posts

Re: PostgREST – REST API from any PostgreSQL database

#21

Post by wilsonfiifi »

CloudLeaper wrote: post #17

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.

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

Re: PostgREST – REST API from any PostgreSQL database

#22

Post by sz4kerto »

You should be aware that this is a _bad_ pattern for anything more serious than a university homework. Instead of exposing functionality that you can guarantee and that's required by the clients, you expose your database schema, essentially tightly coupling the DB with the clients.

I know it's tempting to do that, but spend some time thinking of your data and what do you want to expose.

Re: PostgREST – REST API from any PostgreSQL database

#23

Post by jawr »

perlgeek wrote: post #19
CloudLeaper wrote: post #17

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

Re: PostgREST – REST API from any PostgreSQL database

#25

Post by jawr »

sz4kerto wrote: post #22

You should be aware that this is a _bad_ pattern for anything more serious than a university homework. Instead of exposing functionality that you can guarantee and that's required by the clients, you expose your database schema, essentially tightly coupling the DB with the clients. I know it's tempting to do that, but spend some time thinking of your data and what do you want to expose.

Aren't a lot of endpoints essentially bound to the database anyway? If you were to do any sort of major schema change, chances are you would have to create a new endpoint (i.e. /api/v2/) to handle the new schema changes. Also this handles versioning.

Re: PostgREST – REST API from any PostgreSQL database

#26

Post by CloudLeaper »

jawr wrote: post #23
perlgeek wrote: post #19

Earlier quoted context omitted.

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.

Re: PostgREST – REST API from any PostgreSQL database

#27

Post by vog »

sz4kerto wrote: post #22

You should be aware that this is a _bad_ pattern for anything more serious than a university homework. Instead of exposing functionality that you can guarantee and that's required by the clients, you expose your database schema, essentially tightly coupling the DB with the clients. I know it's tempting to do that, but spend some time thinking of your data and what do you want to expose.

I share this sentiment, but this is mostly a question of organization, and not so much about whether the code is inside or outside the DB.

I personally used some prefix for that, such as "service_" or "public_". All stored procedures (in PostgreSQL speak: "user-defined functions") that have this prefix are accessed from the client. Everything else is internal. Of course, it would be even nicer if the REST framework would enforce that convention.

This is especially nice with JSON aggregation and SUB SELECTs, where you can directly aggregate your objects and lists of sub objects within the DB query, and generate the whole JSON result directly in the DB.

Re: PostgREST – REST API from any PostgreSQL database

#28

Post by jawr »

CloudLeaper wrote: post #26
jawr wrote: post #23

Earlier quoted context omitted.

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.

Re: PostgREST – REST API from any PostgreSQL database

#29

Post by devnonymous »

benkant wrote: post #12

This is good work and if I ever did web development, it would be like this. Why people in the web world don't use stored procedures and constraints is a mystery to me. That this approach is seen as novel is in itself fascinating. It's like all those web framework inventors didn't read past chapter 2 of their database manuals. So they wrote a whole pile of code that forces you to add semantics in another language else…

...and it's not just databases. OS capabilities (eg: vm tuning, bumping up the default sysctl limits, etc) are ignored and the problems arising of such disregard are then dealt with by adding layers to the application like distributed caches and other ^scaling^ solutions.

Re: PostgREST – REST API from any PostgreSQL database

#30

Post by fulafel »

CloudLeaper wrote: post #17

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).
Post reply on HN