What if the schema / view has breaking changes ?
What if serverless meant no backend servers?
41–50 of 138 posts
Re: What if serverless meant no backend servers?
#42What we need is updates that only include security patches.... FEATURE CHANGES SHOULD BE OPTIONAL. Because all software tend to decrease in quality overtime.
RHEL and many other companies offer that. It's called long term support, extended long term support and so on. And costs a fortune. Most people wouldn't want to buy it.
Re: What if serverless meant no backend servers?
#43Earlier quoted context omitted.
I often think we should have a separation of concern between storing/syncing data and application code. That syncing app files should be an OS level feature, with many different available data stores, and sync well across different platforms.
Conflict resolution logic is typically application specific so it would be hard to get something like this working in practice.
If it is a solo user, latest data would be enough to sync. Asuming the blog post tackles personal need app, single user.
Re: What if serverless meant no backend servers?
#44Earlier quoted context omitted.
I often think we should have a separation of concern between storing/syncing data and application code. That syncing app files should be an OS level feature, with many different available data stores, and sync well across different platforms.
Conflict resolution logic is typically application specific so it would be hard to get something like this working in practice.
iCloud already supports this, and from what I gather it works decently well:
https://developer.apple.com/documentation/uikit/uidocumentst...
https://developer.apple.com/library/archive/technotes/tn2336...
Essentially there's an OS mechanism for getting the different versions of the file, your app can detect conflicts and choose how to resolve them, including by displaying arbitrary UI to the user. IIRC This UI can even be integrated with the file open dialog. As a last resort fallback if the app doesn't resolve it Finder/Files will let you keep either version or both (as separate files)
Re: What if serverless meant no backend servers?
#45What about installation and updating/patching? Or is the intention here to still serve this package of web code, db, etc over the net (via cdn maybe), and then execute locally?
What about operational recovery? How does a user of this protect their infomation against device failure / theft / fire ?
This goes together with the solution to "a way to export/import the database".
Export/import is a usability dead end. What we need is syncing. There should be a serverless way to sync data. On a LAN there are several ways to do it: databases, files. With possibly untrusted devices (phones) on different networks (PC on home LAN, phone on the operator network) the solution is... I don't know.
Re: What if serverless meant no backend servers?
#46I'm always glad to see people experimenting with different approaches to building and deploying apps. That said, the general idea of this Serverfree approach doesn't appeal to me. On any given day, I'll use 4 different devices. I need my data to synchronize seamlessly. I wouldn't use a program (in-browser or traditionally installed application) unless I can synchronize that data either by storing files in a Dropbox-l…
Not to mention what if I spill my coffee all over my laptop or otherwise lose access
Re: What if serverless meant no backend servers?
#47I'm always glad to see people experimenting with different approaches to building and deploying apps. That said, the general idea of this Serverfree approach doesn't appeal to me. On any given day, I'll use 4 different devices. I need my data to synchronize seamlessly. I wouldn't use a program (in-browser or traditionally installed application) unless I can synchronize that data either by storing files in a Dropbox-l…
Same here,
Every single product or service I pay for, needs to work on Linux and on Android.
Like Spotify. I love that the music plays on Linux with the big speakers, but I am choosing the songs on the Android pocket device.
Re: What if serverless meant no backend servers?
#48Tldr: Ship the entire app in the browser.
This may sound a bit snarky, but here is a serverfree app for your enjoyment as well:
serverfree
Re: What if serverless meant no backend servers?
#49I'm always glad to see people experimenting with different approaches to building and deploying apps. That said, the general idea of this Serverfree approach doesn't appeal to me. On any given day, I'll use 4 different devices. I need my data to synchronize seamlessly. I wouldn't use a program (in-browser or traditionally installed application) unless I can synchronize that data either by storing files in a Dropbox-l…
Exactly, initially we try to ditch data storage, lets say we do it by encrypting db and syncing to a cloud service, then expect it syncs on other devices when we're about to use the app. This would be just CRUD. Background processes would be a whole different problem to tackle with. I still can't envision a self-hosted decentralized backend on trivial devices.
I think that’s what Veilid aspires to be. Have you looked into it? If so, please let me know what you think about it in this context.
https://en.wikipedia.org/wiki/Veilid
> Veilid is a peer-to-peer network and application framework released by the Cult of the Dead Cow on August 11, 2023, at DEF CON 31. Described by its authors as "like Tor, but for apps", it is written in Rust, and runs on Linux, macOS, Windows, Android, iOS, and in-browser WASM. VeilidChat is a secure messaging application built on Veilid.
Re: What if serverless meant no backend servers?
#50These ideas are some of the founding principles of "local-first software": https://www.inkandswitch.com/local-first/
As I like to put it - Local-first is the real serverless. Your user's device is the real edge.
I think the future of the web needs to be that the server is optional, we need our data (albeit personal or our companies) to be on our own devices.
We are all carrying around these massively powerful devices in our pockets, let use that capability rather than offload everything to the cloud.
One of the things I find most exciting about local-first (and I'm very fortunate enough to be working on it full time), is the sync tech thats being developed for it. 2024 is I think going to be the year local-first goes mainstream.