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

141–150 of 210 posts

Re: PostgREST – REST API from any PostgreSQL database

#141

Post by _yy »

snarfy wrote: post #129
3pt14159 wrote: post #65

Earlier quoted context omitted.

You are speaking from ignorance with the voice of authority. I worked on a rails app that handled a billion requests per day. The problem isn't performance of the web framework, those are easy to load balance and split into C or cache when you need it. The problem is scaling your database, keeping your data secure, and iterating to meet business goals with a growing codebase and infrastructure. A mess of stored proce…

> The problem is scaling your database There is only one database for everything in the business? Of course it doesn't scale. The problem you describe stems from solving every business request by adding yet another table to 'the' database. It's a monolithic solution. It doesn't matter if you use database features or not. There is no difference between a mess of stored procedures and a mess of business logic classes.…

Web servers usually scale better than (traditional) databases, so it makes sense to not offload computation to the database, even if it means that there's an overhead.

Re: PostgREST – REST API from any PostgreSQL database

#142

Post by giaour »

batou wrote: post #109
nunwuo wrote: post #94

Earlier quoted context omitted.

> Avoid state at all costs. Stored procedures are stateful. Schema and migrations is pain enough already. What do you mean by that? How is having a bunch of queries in a stored procedure more "stateful" than having the same queries in the application? > Write me a check constraint that validates an email address being put in a varchar column and reports back a sensible message which can be bound to an entry field wit…

Stateful: If I have to load the stored procedure into the persistence engine then that step is required. This is no more stateful than queries in the application but it means that the relevant state in both the application and the database engine needs to be reloaded and constantly sychronised. Ergo, two times the work. CHECK constraint violated is no good for humans. Prevention is better than cure here. Why shouldn'…

> Why shouldn't I enforce unique constraints in the application?

This tightly couples your database to your application. You can no longer guarantee that your database is reliable when used otherwise.

Re: PostgREST – REST API from any PostgreSQL database

#143

Post by GrinningFool »

kijin wrote: post #106
mark_sz wrote: post #92

Earlier quoted context omitted.

I'm guessing you are not developer, because that kind of comment wouldn't come from someone who's thinking logically. We don't need another flame war here. And yes, most of the web is build on Wordpress/PHP - but you don't need to be a developer to install Wordpress.

What does logic have to do with it? I'm just stating what I believe to be a fact: that the majority of web developers in this world never think of PostgreSQL as an option. I don't care whether that's a logical thing for them to think. It's just a fact, whether I like it or not. If you think I'm wrong about the facts, please feel free to open a phone book in any part of the world other than the Bay Area, call up a dec…

So you start off ok here:

    I'm just stating what I believe to be a fact...
But then you move on to say:

    It's just a fact, whether I like it or not.
So which is it? Do you believe it to be a fact, or is it a fact? And if it is, where's your evidence?

(I happen to agree with your opinion, but the semantics here bug me.)

Re: PostgREST – REST API from any PostgreSQL database

#144

Post by psaintla »

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…

Around 2005 I worked for a fairly large company that did exactly what you're suggesting with Postgresql and it was a complete disaster. Have you ever tried implementing sharding with all of your business logic in stored procedures? Have you ever tried hiring people who understand pl/sql and WANT to work with it? I have done both and it is a nightmare, once you get to the point of having to shard data you end up in one of two places:

1.) The sprocs become insanely complex because they have to be shard aware.

2.) You slowly start moving more of your code that was in sprocs to your application so now you've got two problems.

As for hiring, put out an ad for an engineer with pl/sql knowledge better yet put out an ad for someone who wants to learn and use pl/sql. Good luck finding enough of those people to get any significant work done.

Re: PostgREST – REST API from any PostgreSQL database

#145

Post by tracker1 »

pilif wrote: post #6

Contrary to many other "expose a RDBMS schema as an API" solutions, this one is interesting due to its very close tie-in with postgres. It even uses postgres users for authorization and it relies on the postgres stats collector for caching headers. I also very much liked the idea of using `Range` headers for pagination (which should be out-of-band but rarely is). I'm not convinced that this is the future of web devel…

Agreed, even though I don't care for exposing the database quite this directly, it is a very interesting approach...

I'm also unsure of using the DB's authentication system. While approachable, I'm at a place where imho, for most systems there is a conflation of users, accounts, and logins. IMHO, a user may only have a single account, but a modern system should support multiple logins... Supporting social/jwt/oauth style logins in addition to local database backed logins is generally the best option for public facing sites/applications.. and even then jwt/oauth will allow for more seamless integration with internal SSO options.

Then again, this type of approach may work well if you want to be able to use it as an additional abstraction of your database access from a UI backing API.

Re: PostgREST – REST API from any PostgreSQL database

#146

Post by bpicolo »

mooreds wrote: post #35
jister wrote: post #32

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

To force yourself to go through a service. To abstract away underlying implementation details. More here in the value of services (Yegge's rant): https://plus.google.com/+RipRowan/posts/eVeouesvaVX

And by doing so you remove all the performance from what's hopefully the most-performant part of your stack. =/

A database IS a service. It's just not a 'restful web service'. Making it one doesn't gain you any useful abstraction for SOA.

Re: PostgREST – REST API from any PostgreSQL database

#147

Post by scottschulthess »

_yy wrote: post #141
snarfy wrote: post #129

Earlier quoted context omitted.

> The problem is scaling your database There is only one database for everything in the business? Of course it doesn't scale. The problem you describe stems from solving every business request by adding yet another table to 'the' database. It's a monolithic solution. It doesn't matter if you use database features or not. There is no difference between a mess of stored procedures and a mess of business logic classes.…

Web servers usually scale better than (traditional) databases, so it makes sense to not offload computation to the database, even if it means that there's an overhead.

Web server codebases are typically also way easier to modify, unit test, with better tools and languages.

Re: PostgREST – REST API from any PostgreSQL database

#148

Post by curiousjorge »

The comments are unbelievably negative considering the quality and the range of features this offers. This is extremely useful because I won't have to spend time writing out REST api in order to expose the Postgre data. Often a client just wants to access the data with REST api and to write an entire stack just to serve a few doesn't make sense. There's no expectation that this is going to serve a gazillion requests per minute out of the box, and that's totally fine with me since you shouldn't rely on off the shelf solutions anyways if you were building an architecture of that size, but really question if you are going to have that many requests per second. It reminds me of the customer who claims 'I need this done in node.js to support 10,000 concurrent users' and when asked how many users he has now he replies 'none, but I hope I can reach the number', solving problems he doesn't have yet and complaining that 'php is too slow'.

Some of the best ideas and tools on HN are met with so much negativity it reminds me of Reddit, where the small percentage of people who get off on putting others down so they can feel good about themselves dominate the comments.

Good on you cdjk, this is exactly what I was looking for. Thank you!

Re: PostgREST – REST API from any PostgreSQL database

#149

Post by kaikokaur »

framp wrote: post #81
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…

I don't think using stored procedures should be the focus of the project. PostgREST is great because it lets you kickstart a CRUD application with ease. I'm mainly a node.js developer nowadays and I'm using some frameworks to kickstart APIs for my clients - and then I jump in and add features. What I really want is a solution to build a API server which deals with authentication, exposing my models through REST and o…

You may want to see http://www.zazler.com/ or https://www.npmjs.com/package/zazler

Re: PostgREST – REST API from any PostgreSQL database

#150

Post by cbau »

pilif wrote: post #6

Contrary to many other "expose a RDBMS schema as an API" solutions, this one is interesting due to its very close tie-in with postgres. It even uses postgres users for authorization and it relies on the postgres stats collector for caching headers. I also very much liked the idea of using `Range` headers for pagination (which should be out-of-band but rarely is). I'm not convinced that this is the future of web devel…

Resources only map 1-to-1 with database models for trivial applications, so certainly not the future. Still, useful for getting up and running.
Post reply on HN