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

111–120 of 210 posts

Re: PostgREST – REST API from any PostgreSQL database

#111

Post by fweespeech »

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…

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

Regardless of the other points people brought up...

Sharding a database with stored procedures and constraints as you advise is a nightmare because you now have a completely separate deployment process [deploying stored procedures, if you think this doesn't require a deployment process across a sharded infrastructure...I have no words].

Using an internal web framework is much, much easier than maintaining two separate deployment processes. Especially when one of those processes has to take down nodes to avoid some shards having different stored procedures than other shards.

Re: PostgREST – REST API from any PostgreSQL database

#112

Post by _lce0 »

adamors wrote: post #43
chx wrote: post #18

Earlier quoted context omitted.

Yes. HN is a bubble. There are ~700 PHP questions on SO a day and ~150 node.js. This is just one pair of numbers, you can mine your own whatever you like but you'll realize there are massive amounts of "web developers" with a ... low amount knowledge.

Thinking most web developers are still shipping PHP 5.3 apps on shared hosts is also a very outdated view.

While I do agree with you, I want to make a distinction between shipping and building an application.

IMHO the term "developer" should not be applied to those that can just ship but rather those who can also build.

It doesn't matter if they are web, desktop, nor low-systems developer actually

Most auto-called web developers are just "web masters"

Re: PostgREST – REST API from any PostgreSQL database

#113

Post by herge »

nunwuo wrote: post #94
batou wrote: post #54

Earlier quoted context omitted.

Hmm no. Avoid state at all costs. Stored procedures are stateful. Schema and migrations is pain enough already. 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 with metadata about the error. Write me a constraint and key arrangement which is unique across two and three columns in separate groups. No. You…

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

Not enforcing as the final line, but reporting the error back to the user in a way that can be handled/translated/etc.

Re: PostgREST – REST API from any PostgreSQL database

#114

Post by benkant »

3pt14159 wrote: post #65
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…

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…

I never mentioned performance or scaling as reasons for using a database's features- though they might be worth considering. The fact I never said those words and it fired you up says more about your experience than mine I imagine.

Re: PostgREST – REST API from any PostgreSQL database

#115

Post by ecopoesis »

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…

Because databases are a very poor fit for APIs? This is one of my biggest problems with high holy REST: it generally just means reimplementing your SQL API in HTTP semantics.

APIs should be about encapsulating business logic. Databases should be about storing data in a reliable, predictable way.

Re: PostgREST – REST API from any PostgreSQL database

#116

Post by bkeroack »

sergiosgc wrote: post #107
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, keeping your data secure, and iterating to meet business goals with a growing codebase and infrastructure. A mess of stored procedures would restrain you from doing all three. Your argument has a non sequitur right here. A mess of [foo] is a mess; the layer it is in does not matter; the language it is in does not matter. A mess of application layer code is equally effective in…

A mess is a mess, true, but some are easier to clean up than others.

GP is correct. Methods for scaling/optimizing the application layer are clear and well-known. Scaling the data layer is a huge challenge. This is why the market is filled with snake oil databases promising linear scalability and perfect consistency/reliability, etc.

Re: PostgREST – REST API from any PostgreSQL database

#117

Post by dragonwriter »

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'…

> CHECK constraint violated is no good for humans.

Well, sure, an application should respond to DB errors by presenting appropriate messages on the UI, just like any other errors it encounters. You should only see "CHECK constraint violated" if you are bypassing the app and using the DB. Otherwise, you should see something nice provided by the app.

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

Because you should do it in the database whether or not you do it in the application, and then once you have, well, DRY.

Re: PostgREST – REST API from any PostgreSQL database

#118

Post by wslh »

jeletonskelly wrote: post #91
wslh wrote: post #86

Earlier quoted context omitted.

If Facebook uses MySQL and PHP there is some truth in the comment.

To say that Facebook uses PHP and MySQL is to leave out the truth, honestly. They are a part of the stack, yes, but they aren't what makes the application scale to billions of requests. It would be like saying the local coffee shops website using Wordpress with a MySQL backend is using the same tech as Facebook. It's laughable.

They choose MySQL vs a lot of other alternatives for some reason and this reasoning can be applied to your use case.

> They are a part of the stack, yes, but they aren't what makes the application scale to billions of requests.

These are not just part of the stack, these are critical components within the stack.

Re: PostgREST – REST API from any PostgreSQL database

#119

Post by twistedpair »

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

Amen. Whatever happened to the binary driver? Calling a Prepared Statement over a binary driver to a localhost or in rack DB and we're talking microsec level query times possible. Always annoyed when I spin up Hello World examples of all the new Rest Hotness db's to discovered that a PK query on a fresh install with only 10 rows still takes 10ms!

Quite unclear why you'd layer all the HTTP and marshalling overhead on backend service calls, other than to ensure you always have slow requests.

Re: PostgREST – REST API from any PostgreSQL database

#120

Post by twistedpair »

caf wrote: post #45
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...

Presumably because browsers talk HTTP, but don't talk Postgres' native protocol.

Just don't forget to secure it. Reminds me of when people thought it was a good idea to expose the REST API of ElasticSearch directly as their API and then got p0wned. Using "REST as an abstraction layer" isn't the same as taking someone else's OTC API, calling it your own, and exposing it to the public.
Post reply on HN