[gjsman-1000]

Great; now all we need is client side integrity verification with super strong DRM and virtualization techniques; and companies will finally start eliminating most of their compute bills by running the server on the client. Bookmark this comment, we’ll see where we are in 2045; I wouldn't rule out WebAssembly becoming a hardware feature at that point. (I never said I like this - but stupider things have happened, like Electron apps; this would just be the finishing of the circle with web development becoming the new native.)

[JohnBooty]

For all "typical" web apps (and certainly the ones for which you'd use RoR) you still need some kind of server providing some kind of central database.

Assuming you don't want to just leave 5432 open and expose your Postgres server for the world to rawdog, you are going to need some authentication and other auth logic on the server side.

So, I don't see companies really rushing to deploy apps this way.

[mdaniel]

Fun fact, PG supports TLS auth[1] which one could import[2] into a browser context to hypothetically expose it to WASM. I am waving hands here, because I've never used the Web Crypto API in anger, and for sure am not the target audience to run RoR in the browser

I hear you about purposefully leaving 5432 open to the Internet, because "C is gonna C" but I just meant much like its "PasswordAuthentication no" friend, sending passwords over the wire is not the only form of auth nowadays. There's a very real chance putting pgbouncer in front of it[3] would reduce the blast radius of exposing C to the Internet. I was hoping pgcat (written in rust) would be a suitable alternative but it does not seem to allow TLS auth

1: https://www.postgresql.org/docs/11/auth-cert.html (it's the earliest version still linked on their site)

2: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...

3: https://www.pgbouncer.org/config.html#authentication-setting...

[JohnBooty]

And you could theoretically just have Postgres be the app server -- you can even write pg stored procedures in friendly languages like Python.

(Tangent: In fact, I sort of used to develop that way with SQL Server back in the early 2000s. VBScript and PHP sucked, and databases in my apps were sometimes shared between different apps, so I liked to put a lot of the data-level logic in stored procedures. You need a migration strategy of course but that was honestly a perfectly fine way to develop. I was productive and remember those days fondly. I didn't expose SQL Server to the net directly, but it was sort of the app server, and stored procedures can be extremely performant since there's no round-trip)

But I mean...

Still. You need private application code somewhere. At a minimum you need it to ensure that users aren't doing and seeing things they're not supposed to do and see. And also to connect to auxillary services e.g. payment processors -- you need to store the credentials somewhere private.