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

91–100 of 210 posts

Re: PostgREST – REST API from any PostgreSQL database

#91

Post by jeletonskelly »

wslh wrote: post #86
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…

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.

Re: PostgREST – REST API from any PostgreSQL database

#92

Post by mark_sz »

kijin wrote: post #15
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. 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.

Re: PostgREST – REST API from any PostgreSQL database

#93

Post by jeletonskelly »

glogla wrote: post #49
adamors wrote: post #44

Earlier quoted context omitted.

For one, stored procedures are hard to test, debug, maintain and check into source control. But don't let that get in your way of ignorantly generalising about web developers.

Stored procedures may be all of those things, but they don't have to - it's just that most of the time, developers don't really care, so they have fancy versioning, deployment and continuous integration for all their code, except for stored procedures. Here is interesting talk about database migrations and stored procedures and unit tests: http://www.pgcon.org/2013/schedule/events/615.en.html Also, DB procedures are…

> so they have fancy versioning, deployment and continuous integration for all their code, except for stored procedures.

Exactly, because those things are extremely important to how code gets shipped and delivers value to the business. Stored procedures become a huge risk to future development which ultimately means it's a risk to the businesses ability to deliver value. What happens when you need to change DB vendors because the business has been so successful that you've outgrown a relational database? You have to rewrite the ENTIRE MC portion of your MVC application. Why would someone ever do this?

Re: PostgREST – REST API from any PostgreSQL database

#94

Post by nunwuo »

batou wrote: post #54
glogla wrote: post #49

Earlier quoted context omitted.

Stored procedures may be all of those things, but they don't have to - it's just that most of the time, developers don't really care, so they have fancy versioning, deployment and continuous integration for all their code, except for stored procedures. Here is interesting talk about database migrations and stored procedures and unit tests: http://www.pgcon.org/2013/schedule/events/615.en.html Also, DB procedures are…

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 with metadata about the error.

Postgres gives you metadata about the error, though the error message will still be a generic "CHECK constraint violated" or some such.

> Write me a constraint and key arrangement which is unique across two and three columns in separate groups.

I'm not sure what you want to see based on that description, but surely you're not advocating enforcing unique constraints in the application?

Re: PostgREST – REST API from any PostgreSQL database

#95

Post by AlisdairO »

batou wrote: post #87
spdionis wrote: post #70

Earlier quoted context omitted.

You had me until your last sentence. Database are very important to (and very good at) store your data. And data is important (duh). All the issues you described above are related to working with the data, which should not happen in the database.

That's a poor argument because we're not discussing the arbitraty boundary of storing versus working with data as the lines between those are very blurred. This is even more the case when you use stored procedures which work with data close to the storage. While we're on this subject, RDBMS are no better at storing data than any other technology out there[1]. In fact when you start thinking abstractly like this, othe…

Riak makes sense for some workloads. For the vast majority of workloads out there, you will save time and money with an ACID system. Good ACID systems are mostly RDBMSs, so I would say, for now at least, that typical RDBMSs do have a leg up on other technologies out there.

Re: PostgREST – REST API from any PostgreSQL database

#96

Post by batou »

AlisdairO wrote: post #95
batou wrote: post #87

Earlier quoted context omitted.

That's a poor argument because we're not discussing the arbitraty boundary of storing versus working with data as the lines between those are very blurred. This is even more the case when you use stored procedures which work with data close to the storage. While we're on this subject, RDBMS are no better at storing data than any other technology out there[1]. In fact when you start thinking abstractly like this, othe…

Riak makes sense for some workloads. For the vast majority of workloads out there, you will save time and money with an ACID system. Good ACID systems are mostly RDBMSs, so I would say, for now at least, that typical RDBMSs do have a leg up on other technologies out there.

Definitely. Which is why we still use one. It's cheap, already there and does the job.

Re: PostgREST – REST API from any PostgreSQL database

#97

Post by caseysoftware »

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.

Re: PostgREST – REST API from any PostgreSQL database

#98

Post by jasonlotito »

adamors wrote: post #44
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…

For one, stored procedures are hard to test, debug, maintain and check into source control. But don't let that get in your way of ignorantly generalising about web developers.

I tell that to our DBAs who test, debug, maintain, and check into source control our SPs.

Re: PostgREST – REST API from any PostgreSQL database

#99

Post by arethuza »

adamors wrote: post #58
bni wrote: post #48

Earlier quoted context omitted.

"hard to test, debug, maintain and check into source control." Why? I have never had problem with any of these. SPs is just imperative code like any other imperative code.

Well, you cannot isolate the code, you cannot unit test it, you cannot use a debugger, cannot set breakpoint, have stack traces etc. You are tied to the database at all times. In my experience, every stored procedure that is larger than 2-3 lines is a headache.

I'm not a huge fan of stored procedures - but I'm pretty sure you can debug stored procedures in SQL Server pretty easily from Visual Studio - I think you can "step into" the call to SPs while debugging client code.

Re: PostgREST – REST API from any PostgreSQL database

#100

Post by kitd »

LunaSea wrote: post #77
kitd wrote: post #63

Earlier quoted context omitted.

Sorry but databases are just a hole to put your shit in when you want it out of memory. You've got to be joking, right? Data is an enterprise's single biggest asset. A robust, consistent and performant store is vital. SPs can be written as garbage like any other logic, but in the right hands they are a perfectly valid tool for providing useful access to complex data.

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

I'd definitely give you that. SPs are the last place you want business logic.
Post reply on HN