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

Re: PostgREST – REST API from any PostgreSQL database

#191

Post by WorldWideWayne » Thu, Jul 23, 2015, 2:45 AM UTC

curiousjorge wrote: post #190

chrismarlow9 wrote: post #154

Earlier quoted context omitted.

Best advice I ever got from any engineer that actually caused me to start completing projects was "complicate as necessary, not as desired..."

can you elaborate what that quote means?

It means do only what is needed. If you do anything extra, you could be wasting your effort and/or causing problems. Doing just what is needed is sometimes difficult for developers.

I have made the mistake of spending too much time slavishly implementing some pattern only to figure out later that it was just serving my need to implement the pattern, versus just getting the job done with a simple procedural script.

Re: PostgREST – REST API from any PostgreSQL database

#192

Post by sitkack » Thu, Jul 23, 2015, 3:17 AM UTC

tracker1 wrote: post #145

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

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

It is up to the developer to use this responsibly. I don't think the creator is suggesting to drop PostgreSQL instances directly onto the net. This would be ideal in a layered backend, and in fact, makes systems way more composable.

Re: PostgREST – REST API from any PostgreSQL database

#193

Post by sitkack » Thu, Jul 23, 2015, 3:22 AM UTC

bpicolo wrote: post #146

mooreds wrote: post #35

Earlier quoted context omitted.

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.

Not true, I now can get read only data using curl inside of a cronjob. This is really powerful. Someone now needs to make a similar system for Redis.

Re: PostgREST – REST API from any PostgreSQL database

#194

Post by spopejoy » Thu, Jul 23, 2015, 3:57 AM UTC

rodgerd wrote: post #34

weitzj wrote: post #31

Could maybe somebody of the older experienced people comment whether this is a good idea? I find it intriguing, but maybe I am just one generation behind and you were to say: "Been there done that. This strong dependency on the database was really not a good idea in the long run because... "

In my experience (and I'm older these days...) databases are a much rarer migration than programming languages. I deal with stuff that's still in (heaven help us) VSAM files, accessed a mix of assembler, COBOL, C, Java, TCL, C#, C++, Pascal, and so on and so forth.

Agree, the received wisdom has always been database vendor choice as a ten-year commitment, as opposed to almost anything else. It's a reason to avoid databases :)

Re: PostgREST – REST API from any PostgreSQL database

#195

Post by spacemanmatt » Thu, Jul 23, 2015, 6:40 AM UTC

jacques_chester wrote: post #76

cube00 wrote: post #33

Earlier quoted context omitted.

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

I have presided over a couple of to-PostgreSQL migrations but I've only heard of one away-from-PostgreSQL migration, and it was Skype when MS bought it.

Re: PostgREST – REST API from any PostgreSQL database

#196

Post by spacemanmatt » Thu, Jul 23, 2015, 6:44 AM UTC

spopejoy wrote: post #194

rodgerd wrote: post #34

Earlier quoted context omitted.

In my experience (and I'm older these days...) databases are a much rarer migration than programming languages. I deal with stuff that's still in (heaven help us) VSAM files, accessed a mix of assembler, COBOL, C, Java, TCL, C#, C++, Pascal, and so on and so forth.

Agree, the received wisdom has always been database vendor choice as a ten-year commitment, as opposed to almost anything else. It's a reason to avoid databases :)

Strongly disagreed that it's a good reason to avoid databases. If you are going to collect data of any value over a long period of time, pick a horse and stay on it. Over time, technology and business needs might force a re-evaluation of that position, but you don't want to build around unmeasured plans to maybe switch databases at random some day.

Re: PostgREST – REST API from any PostgreSQL database

#197

Post by spacemanmatt » Thu, Jul 23, 2015, 6:46 AM UTC

bdcravens wrote: post #36

rodgerd wrote: post #34

Earlier quoted context omitted.

In my experience (and I'm older these days...) databases are a much rarer migration than programming languages. I deal with stuff that's still in (heaven help us) VSAM files, accessed a mix of assembler, COBOL, C, Java, TCL, C#, C++, Pascal, and so on and so forth.

I work on a system has has iterated through 3 distinct languages while relying on the same database.

Integrating at the database is a powerful pattern. I see some value for larger organizations to go a step further and integrate at a higher service layer, because one database could never support the entire enterprise. But for orgs that fit in one database, it's great, IMO.

Re: PostgREST – REST API from any PostgreSQL database

#198

Post by spacemanmatt » Thu, Jul 23, 2015, 6:48 AM UTC

kelseydh wrote: post #128

glogla wrote: post #69

Earlier quoted context omitted.

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.

Implementing SQL views is not exactly trivial if you are operating under an existing Ruby on Rails app. I suspect most RoR developers don't use SQL views unless they absolutely need to for a certain query that's heavy on performance. As a result, the coupling to the schema does seem to be concerning as moving everything to SQL views appears to be a high amount of overhead if you're already successfully relying on an…

When I did PG performance work as an application-DBA, Rails and its usage by users fairly unfamiliar with SQL was a constant source of aggravation.

Re: PostgREST – REST API from any PostgreSQL database

#199

Post by spacemanmatt » Thu, Jul 23, 2015, 6:50 AM UTC

jacques_chester wrote: post #74

glogla wrote: post #69

Earlier quoted context omitted.

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.

So true. A good remote facade decouples the usage interface from the physical schema, giving you quite a bit of flexibility.

Re: PostgREST – REST API from any PostgreSQL database

#200

Post by spacemanmatt » Thu, Jul 23, 2015, 6:53 AM UTC

McElroy wrote: post #78

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.

That is entirely on purpose, too.