PostgREST – REST API from any PostgreSQL database • Hacker News Board

Re: PostgREST – REST API from any PostgreSQL database

#71

Post by glogla » Wed, Jul 22, 2015, 11:01 AM UTC

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.

That's why the "official" way to deploy postgrest is to run it on views in different schema than your data is.

Re: PostgREST – REST API from any PostgreSQL database

#72

Post by spdionis » Wed, Jul 22, 2015, 11:03 AM UTC

kijin wrote: post #47

adamors wrote: post #43

Earlier quoted context omitted.

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

The latest version of WordPress is still compatible with PHP 5.2.4 and above, so anyone who builds a WordPress site is effectively shipping a PHP 5.2 app.

They do recommend php 5.4 though, and afaik they do try to push the community to upgrading.

Re: PostgREST – REST API from any PostgreSQL database

#73

Post by dijit » Wed, Jul 22, 2015, 11:06 AM UTC

wisty wrote: post #64

msane wrote: post #8

Earlier quoted context omitted.

Correct answer. The demo is doing everything right, parent seems confused. Browsers also don't have any special regard for '.json' in the path. The path can be anything; the path doesn't suggest anything about content-type or caching.

Yes, but if / returns a html file, and /.json returns the json, it's impossible for a browser to display the json by accident (no matter what the header is). And yes, the header seems correct, Checking, that's the API demo, the GUI is separate. Thus the confusion. Yeah, headers are the right way to do it, but a different path is also the right way to do it, and extensions like .json can make that simpler in some case…

/ being an index which points to a .html file is completely arbitrary though.

there's no specification that says it must be so.

Re: PostgREST – REST API from any PostgreSQL database

#74

Post by jacques_chester » Wed, Jul 22, 2015, 11:09 AM UTC

glogla wrote: post #69

bni wrote: post #52

What about when changes are made to the schema, wont the API just be changed in that case? Wont this lock you in with very hard coupling between your db schema and public REST API?

You can do that using SQL views. That means you can provide consistent api of your choosing no matter how the original tables look like. Postgrest docs also describe how you should use this feature to version you API.

And, in fact, it's best practice to never expose your physical schema to applications.

Re: PostgREST – REST API from any PostgreSQL database

#75

Post by jacques_chester » Wed, Jul 22, 2015, 11:10 AM UTC

cies wrote: post #57

gizmodo59 wrote: post #55

With Data Virtualization providers like Denodo you can create a REST web service with any relational database very easily.. https://community.denodo.com/tutorials/browse/dataservices/2...

I'd be interested to see a benchmark. PostgREST is fast! And it is also a piece of software that tries to "do one thing really well". It deploys as a binary, which is also a big plus compared to these "first install this list of dependencies at these ranges of versions before using our product". Last thing: is Denodo open source? It is not listed at "why use Denodo", so I guess not...

I've found that Spring Data REST makes wrapping a database pretty easy.

Re: PostgREST – REST API from any PostgreSQL database

#76

Post by jacques_chester » Wed, Jul 22, 2015, 11:11 AM UTC

cube00 wrote: post #33

fulafel wrote: post #30

Earlier quoted context omitted.

You implement any custom logic in PostgreSQL mechanisms (permissions, triggers, constraints, views, stored procedures etc).

...and be locked in for life, joy.

The classic fear of lock-in was vendor lock-in.

Does Oracle or Sybase own Postgres? Nope.

There's nobody with a legal hand on your throat.

Re: PostgREST – REST API from any PostgreSQL database

#77

Post by LunaSea » Wed, Jul 22, 2015, 11:12 AM UTC

kitd wrote: post #63

batou wrote: post #51

Earlier quoted context omitted.

That is quite frankly horse poop. We use stored procedures. Not by choice; this is a legacy we're stuck with. It is nothing but an unadulterated disaster of a technology regardless of what you use it for. I'm talking 45,000 stored procedures here. 2000 tables. TiB of data. 50,000 requests/second across SOAP/web/desktop etc. It's hell. Problems with stored procedures: 1) Performance. More code running in the hard to s…

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.

Re: PostgREST – REST API from any PostgreSQL database

#78

Post by McElroy » Wed, Jul 22, 2015, 11:14 AM UTC

Between this (yes, I know it's 3rd party) and the support for JSON, PostgreSQL seems to be eating into the market of the NoSQL databases every day. I like that. I like that because the fewer new things I must learn, the more time I can spend on the things I find interesting.

Re: PostgREST – REST API from any PostgreSQL database

#79

Post by kijin » Wed, Jul 22, 2015, 11:19 AM UTC

spdionis wrote: post #72

kijin wrote: post #47

Earlier quoted context omitted.

The latest version of WordPress is still compatible with PHP 5.2.4 and above, so anyone who builds a WordPress site is effectively shipping a PHP 5.2 app.

They do recommend php 5.4 though, and afaik they do try to push the community to upgrading.

It still means they can't depend on any feature introduced in PHP 5.3 or later. No closures, no namespaces.

Ditto for any theme or plugin that tries to be compatible with all versions of PHP that WordPress itself supports.

Re: PostgREST – REST API from any PostgreSQL database

#80

Post by tomchristie » Wed, Jul 22, 2015, 11:24 AM UTC

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

Perfectly expressed.