[eyelovewe]

We had Meteor with “mini mongo” and you locally subscribed to streams and it was all a quite bloated PÓS IIRC. At some point someone will make a virtual browser that runs in the browser, or maybe a kubernetes that runs in the browser and the circle of ironic self referencing will be complete. Just replace the browser and use ports 80 and 443 and be done with it, instead of pretending that cpu cycles and RAM are free. The browser is not the app platform of the future, it’s the current bandaid solution is all. I also don’t agree that this article is well written. It exclusively addresses the world according to front end dev, mulch as graphql does. I’m sorry that coding elaborate stuff requires you to keep track of your elaborate stuff. Set your global var equal to the parsed xhr.result and redraw your GUI and get over it, IMO

[hootbootscoot]

Backend devs, meanwhile, wonder where their Frontend as a service is...

"backend as a service" = "can you just, like, do that magic CRUD stuff or whatever you do"

[yawnxyz]

I've always thought of apps like Retool as a Frontend as a service, and even as a mostly-front-end-person I've started using those more

[hootbootscoot]

anyway, Postgrest already existed before GraphQL Here's a frontend devs BAAS, replete with soup and desert. (if you don't mind using db users, you even get user-auth per route...)

https://postgrest.org/en/stable/

[hootbootscoot]

But hey, now I'm suspicious... are there Meteor dev's here?

IIRC, right on the heels of Meteor we got Apollo from the same folks...

The thing is, I'm puzzled, given the insane unnecessary complexity all this ES2030 and "build toolchains" (who knew javascript needed to be compiled, are we making binary bitstreams? is this an embedded microcontroller? is this an FPGA?) and other esoteric "let's replicate all of comp-sci in the browser" frontend tech, why on earth do such smart folks need the backend as a service? surely such folks who can deal with webpack build scripts can write a little php or ruby or java or something...? What is with this desire to completely neutralize and gut the backend stack? why on earth invert what a webserver is? Request=> Response (which might possibly be a rendered webpage) do folks actually think any of this is necessary and/or good?

Look, I'm all for web API's, web audio, webrtc, etc... I just don't see where a database in the browser is anything but 'cruisin for a bruisin'...

it's not like databases get their own dedicated servers or anything..

or do you mean something like a mobile app using pouchdb? "offline first and syncing to a single real database in the cloud as soon as one rejoins the network"

because a browser-based database can only ever be a compromise, such that a compelling reason could force it, but that's something akin to "DB per user" aka the Couch/Pouch ecosystem.

[atatatat]

Is Couch more secure than what I've come to expect from other Apache stuff?

[dangoor]

> or maybe a kubernetes that runs in the browser and the circle of ironic self referencing will be complete

https://blog.stackblitz.com/posts/introducing-webcontainers/

[hootbootscoot]

Wow! it just goes to show... something or other... How many recursive levels of that do you reckon are required to grind your average dev portable workstation to a halt? (let's say 32gb ram, presuming no actual program load, just overhead plus 'hello world') I suppose the real question is: how many engineers will a major corp throw at aforementioned wall/problem in order to make us not care and follow unwise engineering paths?)

I'm going to go with a unikernal wrapping a process before this stuff makes it's way through my intestines, color me skeptical of the notion that slippy couplings in between multiple impedance mismatches will be excusable much longer in a world that increasingly cares about power consumption (and battery life) as well as carbon footprints...

[cblconfederate]

> a virtual browser that runs in the browser

I think there s an app for that

[canadianfella]

> instead of pretending that cpu cycles and RAM are free.

Don’t pretend security is free either.

[hootbootscoot]

is our non-browser (that happens to piggyback on 80 & 443) a single-purpose application? What are the presumed security vulnerabilities of a bespoke non-browser that happens to listen on 2 ports, and either negotiate a transfer from http(s) to our kustom-protocol or utilize existing protocols starting from http(s) (any version of your choice...)

I'm saying that we cannot presume the insecurity of a general purpose browser in a custom application that just happens to take advantage of open ports and an existing distribution network (upgrading/crossgrading connection or not...)

How uncommon is it to open a Zoom link from a browser source into the Zoom app, and countless other examples... not presuming any particular tech stack, which would imply it's own particular vulnerabilities or advantages...

Just curious...I think the "cram it all into a megabrowser from a megacorp and make it run" approach is rather 2021, is all, not necessarily the way of the still as yet undetermined future.