Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dbdev – A database package manager for PostgreSQL trusted language extensions

database.dev

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Dbdev – A database package manager for PostgreSQL trusted language extensions

#51

Post by refset »

mike_hearn wrote: post #14

At KotlinConf today I gave a talk on designing apps with two-tier architecture, where you implement your entire app without the web stack appearing anywhere at all. Instead you publish desktop and mobile apps that connect directly to an RDBMS like PostgreSQL via its native protocol, and use server extensions for any logic that is inconvenient to do with SQL. This approach might seem horrifyingly outside-the-box but h…

Omnigres, "Postgres as a platform", is very much in the same vein: https://github.com/omnigres/omnigres

Re: Dbdev – A database package manager for PostgreSQL trusted language extensions

#52

Post by jchmbrln »

mike_hearn wrote: post #14

At KotlinConf today I gave a talk on designing apps with two-tier architecture, where you implement your entire app without the web stack appearing anywhere at all. Instead you publish desktop and mobile apps that connect directly to an RDBMS like PostgreSQL via its native protocol, and use server extensions for any logic that is inconvenient to do with SQL. This approach might seem horrifyingly outside-the-box but h…

This approach is very appealing, but when I put my SRE hat on my first concern is observability. Has anyone implemented tracing for Postgres with a span for each procedure call?

When I put my dev hat on, I want the option of attaching a debugger and adding breakpoints. Anything there?

Re: Dbdev – A database package manager for PostgreSQL trusted language extensions

#53

Post by spullara »

mike_hearn wrote: post #14

At KotlinConf today I gave a talk on designing apps with two-tier architecture, where you implement your entire app without the web stack appearing anywhere at all. Instead you publish desktop and mobile apps that connect directly to an RDBMS like PostgreSQL via its native protocol, and use server extensions for any logic that is inconvenient to do with SQL. This approach might seem horrifyingly outside-the-box but h…

My first job in SF was with WebLogic and at the time their #1 product was a JDBC driver that let applets talk directly with databases proxied through a Java server, looked something like AppletJDBCHTTPServerJDBCOracle (most of the time).

Re: Dbdev – A database package manager for PostgreSQL trusted language extensions

#54

Post by mike_hearn »

jchmbrln wrote: post #52
mike_hearn wrote: post #14

At KotlinConf today I gave a talk on designing apps with two-tier architecture, where you implement your entire app without the web stack appearing anywhere at all. Instead you publish desktop and mobile apps that connect directly to an RDBMS like PostgreSQL via its native protocol, and use server extensions for any logic that is inconvenient to do with SQL. This approach might seem horrifyingly outside-the-box but h…

This approach is very appealing, but when I put my SRE hat on my first concern is observability. Has anyone implemented tracing for Postgres with a span for each procedure call? When I put my dev hat on, I want the option of attaching a debugger and adding breakpoints. Anything there?

With PL/Java you can at least debug stored procedures, because the Java Debug Wire Protocol is a protocol so you can run it over the network. There are instructions for how to attach a debugger in the PL/Java docs.

For debugging SQL remotely, I don't know what's available, if anything. Though if you only use SQL for short things, you can just run it and debug the query interactively I guess.

Most databases have tools for logging query timings and doing auditing. PGAudit is one for Postgres.

Re: Dbdev – A database package manager for PostgreSQL trusted language extensions

#55

Post by mike_hearn »

refset wrote: post #51
mike_hearn wrote: post #14

At KotlinConf today I gave a talk on designing apps with two-tier architecture, where you implement your entire app without the web stack appearing anywhere at all. Instead you publish desktop and mobile apps that connect directly to an RDBMS like PostgreSQL via its native protocol, and use server extensions for any logic that is inconvenient to do with SQL. This approach might seem horrifyingly outside-the-box but h…

Omnigres, "Postgres as a platform", is very much in the same vein: https://github.com/omnigres/omnigres

That's cool. Seems they're focused on writing apps in SQL though.

Re: Dbdev – A database package manager for PostgreSQL trusted language extensions

#56

Post by yrashk »

mike_hearn wrote: post #55
refset wrote: post #51

Earlier quoted context omitted.

Omnigres, "Postgres as a platform", is very much in the same vein: https://github.com/omnigres/omnigres

That's cool. Seems they're focused on writing apps in SQL though.

Omnigres author here.

While it's definitely possible (and perhaps even advisable) to build many application in sql (especially if your traditional backend is mostly just slinging sql queries), Omnigres by no means limits users to that. Any other postgres PL can handle request.

Support for proxy proxying requests to Postgres-managed containers is coming, too.

The core idea here is less about using SQL or any other PL but increasing mechanical sympathy and decreasing integration, devops and network overhead of the traditional architecture.

Feel free to ask questions or stop by our Discord!

Re: Dbdev – A database package manager for PostgreSQL trusted language extensions

#57

Post by mike_hearn »

benatkin wrote: post #45
mike_hearn wrote: post #14

At KotlinConf today I gave a talk on designing apps with two-tier architecture, where you implement your entire app without the web stack appearing anywhere at all. Instead you publish desktop and mobile apps that connect directly to an RDBMS like PostgreSQL via its native protocol, and use server extensions for any logic that is inconvenient to do with SQL. This approach might seem horrifyingly outside-the-box but h…

> This approach might seem horrifyingly outside-the-box but has a lot of advantages You don't need to worry, there are a lot of people who are into stored procedures. If there weren't, there wouldn't be people disagreeing with them, like the author of Rails: http://web.archive.org/web/20060418215514/http://www.loudthi... The slippery slope of liking stored procedures a whole lot means them taking over the rest of the…

I think DHH's perspective makes a lot of sense from the perspective of a web framework author. If you're going to buy into Rails it makes sense to buy in all the way, and not try to split your app logic across two very different languages and execution environments. Naturally he wants everything to be in Rails and for the DB to be treated as dumb as possible, it is always the way for a platform to want to subsume and abstract its lower layers.

In two-tier architecture there is no web framework, however, because there is no web server to begin with. All the UI logic runs client side and is written in the same language as the stored procedures. In this design there's nothing that's competing to be the place where app logic is implemented because you can't trust the client, so all trusted logic has to be in the database. In that case you buy into the RDBMS all the way, and really lean on its capabilities. The tension is resolved in a different direction.

Post reply on HN