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

101–110 of 210 posts

Re: PostgREST – REST API from any PostgreSQL database

#101

Post by javaJake »

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

Incredible read. Thank you for sharing that post.

Re: PostgREST – REST API from any PostgreSQL database

#102

Post by arethuza »

batou wrote: post #89
LunaSea wrote: post #77

Earlier quoted context omitted.

It is but NO database has the chops to help you handle the business logic.

Despite many attempts by people to prove otherwise. Literally every "enterprise" product I've seen tried to do this and fucked it up royally.

Interestingly some very enterprise products don't even try and use database features like foreign key relationships - it can be a bit of a shock to open a database with many thousands of tables and realise that there is no obvious way to work out how they relate without looking at application level structures.

Re: PostgREST – REST API from any PostgreSQL database

#103

Post by jasonlotito »

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…

> Why people in the web world don't use stored procedures and constraints is a mystery to me.

We do. At least some of us, and honestly, it's not something I think about as being exceptional. I don't always use them, but I much prefer having a nice API of SPs to use rather than having to have custom SQL all over the place. DRY applies to writing queries just as much.

Re: PostgREST – REST API from any PostgreSQL database

#104

Post by Mahn »

caseysoftware wrote: post #97

APIs require more than database access, security, and nice routes. Those are all necessary but a good API also includes flows linking things together so you can progress through higher order processes and workflows. You need to make sure that you're actually providing user value. CRUD over HTTP (or an "access API") should be a first step, not your end goal.

I would not put a direct DB to HTTP REST API front-facing to the public, but it has its use-cases, I can imagine using it server-to-server for instance.

Re: PostgREST – REST API from any PostgreSQL database

#105

Post by batou »

arethuza wrote: post #102
batou wrote: post #89

Earlier quoted context omitted.

Despite many attempts by people to prove otherwise. Literally every "enterprise" product I've seen tried to do this and fucked it up royally.

Interestingly some very enterprise products don't even try and use database features like foreign key relationships - it can be a bit of a shock to open a database with many thousands of tables and realise that there is no obvious way to work out how they relate without looking at application level structures.

Yes that's true as well. JIRA does that in some configurations. Does my head in.

Re: PostgREST – REST API from any PostgreSQL database

#106

Post by kijin »

mark_sz wrote: post #92
kijin wrote: post #15

Earlier quoted context omitted.

> Why people in the web world don't use stored procedures and constraints is a mystery to me. You can blame MySQL 4.1 for that :( Most people who call themselves "web developers" haven't even heard of PostgreSQL, or even if they've heard of it, have no use for it because their usual clients are stuck with MySQL-only web hosts who have only just managed to upgrade to PHP 5.3.

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 decent sample of people who self-identify as web developers, and find out what percentage of them have ever heard of, let alone used, PostgreSQL.

Re: PostgREST – REST API from any PostgreSQL database

#107

Post by sergiosgc »

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…

> 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 preventing scale, security and effectiveness.

The original post is right. Web developers treat their databases poorly[1]. A database is an interface to your data that maintains integrity. Maintaining integrity almost always means stored procedures, as some validation is not expressible as relational integrity and basic type validation.

Now, if you are at the point where your database fully guarantees integrity of data going in and coming out, a REST interface is a small step away. This project is very welcome.

[1] The typical web developer treats a database as a data store. It is also a data store, but a well designed database is much more than than.

Re: PostgREST – REST API from any PostgreSQL database

#109

Post by batou »

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…

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't I enforce unique constraints in the application?

1. Open a transaction

2. Get a user by name from the ORM.

3. Exists? Tell user that the username is already registered.

4. Doesn't exist? Save new User instance.

5. Commit transaction.

Steps 2 and 3 can be as arbitrarily complicated as you need them to be, are fully testable and cheap with anything that uses MVCC.

Re: PostgREST – REST API from any PostgreSQL database

#110

Post by swah »

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

Those are big organizations, though. Maybe smaller orgs / single devs should start with a monolith?

http://martinfowler.com/articles/microservices.html

http://martinfowler.com/bliki/MonolithFirst.html

http://martinfowler.com/articles/microservice-trade-offs.htm...

Post reply on HN