What if serverless meant no backend servers?
subzero.cloud
subzero.cloud
Edit: forgot some words
This obviously works better for very simple things like a "play history" and not for complex things like collaborative document writing.
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)
Like GP said - app specific. If I have two different versions of a SQLite database, that started from a common revision but were both updated independently, and want the updates that were applied in each of them to be preserved - there is quite a lot of work left to do after Apple throws their hands up.
But the OFA is about databases, and this thread is about syncing databases. So you agree with me: the Apple feature is worthless for this use case. GGP was right that its a lot of work to build sync with conflict resolution into an application, and its application specifc.
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.
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.
A more interesting example: I use pCloud instead of MS OneDrive, or Google Drive. They don't have supported Linux clients.
I rejected Dropbox for other reasons, like the limitation to have only one synchronized folder, but technically it has an Ubuntu service and an Android app.
Icedrive seems to be a suitable service, but I found pCloud first.
And believe me: I will not use a browser based interface when I could simply save the files into several folders of my preference, and the sync happens in the background. Every single file storage service I mentioned has a browser based interface. I consider all of them unusable.
Meaning, the only cloud component should be “dumb” data storage, and it should remain entirely optional, only needed for use across multiple devices.
They are still working things out. But synchronization across devices controlled by a principal is doable with the primitives they have already come up with.
The author does mention privacy concerns — hence the appeal of storing the data locally on your device.
I work on PowerSync https://www.powersync.com/ — using embedded SQLite for local-first/offline-first which syncs with Postgres in the background.
I think using an architecture like that where an encrypted version of the data is synced to Postgres, and decrypted for access on the client, would balance the trade-offs well.
A websocket between all your devices and a server (or even webrtc between devices) could achieve this in parallel.
* Using SQL has clear benefits for writing an application. You can use existing stable tools for performing migrations.
* Using SQLite in a filesystem offers many advantages w.r.t performance and reliability. Do these advantages translate over when using WebAssembly SQLite over OPFS?
* How does SQLite / OPFS performance compare to reading / writing to localstorage?
* From what I know about web workers, the browser thinks it is making http requests to communicate with subzero, while the web worker proxies these requests to a local subzero server. What is the overhead cost with doing this, and what benefits does this give over having the browser communicate directly with SQLite?
* I remember seeing a demo of using [SQLite over HTTP](https://hn.algolia.com/?q=sqlite+http) a while back. I wonder if that can be implemented with web workers as an even simpler interface between the web and SQLite and how that affects bundle size...
I would say generally yes. SQLite is known for its performance, and with Wasm SQLite, performance is strongly related to how the file system operations are implemented. There have been some good advances in this area in the last couple of years. My co-founder wrote this blog post which talks about the current state of SQLite on the web and goes into performance optimizations:
https://www.powersync.com/blog/sqlite-persistence-on-the-web
* main thread <-> db vs main thread <-> worker <-> db:
- firstly, sqlite with OPFS has to run in a webworker
- even if it was possible to run in main thread, this approach allows for a code structure that is similar to a traditional architecture (frontend/backend split) and it's easy to route some request to the web worker while let over request fall through and reach backend server and not needing to worry about that in the "frontend code"I was expecting something different because it started with phrases like "no servers at all" and "entirely without any servers", but there's a regular web server serving static files.
I'm not a fan of the term "serverfree", though, since there is a web server. Also, the app and database servers from classic web apps continue to exist, albeit in a logical, local form. If this term somehow catches on for this style of app it will just cause endless confusion. I suppose it isn't a lot worse than some existing terms we've gotten used to (like "serverless"), but I'm always going to advocate to not repeat the mistakes of the past.
I've been thinking about making a web GUI over gmailctl for easy editing but want to make it very easy to use without hosting and without people sending me their keys.
Whether you're doing WASM or Javascript, you use fetch() and need to have your CORS ducks in a row. How exactly you call fetch() depends on your toolchain, but anything trying to be general-purpose will expose it somehow.
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.
I read your post some time back and feel it's been an organizing force for developers in this space — great job and thanks for the work you put into it.
I often wonder about terminology. What was the reason you chose "local-first" over "offline-first" (or even "serverfree" as in this case)?
They are an incredible bunch, as are so many people in the local-first / CRDT space, many I have had the opportunity to meet and collaborate with.
I also (personally) don't like "serverfree" because servers are good - they're not the problem! It's the "servers you don't and can't control" cloud dependencies that are the issue.
The thing that always bothered me about that article is:
> Notably, the object server is open source and self-hostable, which reduces the risk of being locked in to a service that might one day disappear.
It appears that the object server is neither open source and nor self-hostable. The repository that they link is mostly empty. It has a rich version history of "releases" that only change the changelog file.
I assume the article was accurate when written, and have always wondered what happened. So I suspect mongo rewrote the git history to remove the code when they bought Realm. Was it ever open source? Did they intimidate people into taking down forks or did nobody bother?
I do see an edit to the README around that time adding that a license is required to run the self-hosted server. It is dated about two months before the linked article, but they may not have noticed or it may be back-dated:
https://github.com/realm/realm-object-server/commit/fc0b399d...
The comparison list is very useful as a collection, thank you.
That costs battery life. With more powerful chips more time can be spent sleeping consuming minimal energy.
isn't users all that matters in the long term?
It can work well and easily when the features are relatively distinct, but as they start to interact it can become a huge burden.
I absolutely don’t understand the point of this. Just reading the intro, it reads about technology for its own sake, just because you can. But what is the value, what are the downsides?
If you store it on your phone, then it's not showing up on your other devices. If you lose or break your phone, then your data is gone. There are very few applications for which that's acceptable - basically just your calculator app.
If you don't store it on your phone, then it's stored on some kind of server, somewhere. Do you own and control that server, or does someone else? How does the application consume and update the data?
If that's you, and if privacy is important enough to you to want a local-only app, I think you'll find a solution to back up your data.
I don't think it's unreasonable to continue producing apps that do not require an internet connection to function and be useful.
On one hand, if I were to have the goal to make a bunch of money, and software just happens to be the means to an end, making a gated software portal where I control everything would suit me very well. You get nothing until I get the money, and I only maintain what I want to maintain. (pretty much the model every SaaS has)
On the other hand, if I know I have a very small customer base, and everyone is making a lot of money or because of my program, and I don't really care that much about the money above a certain number, I might as well distribute it as a static/stale build. You get a binary, or a virtual machine or something like that, and it just does everything. Maybe if piracy were a concern I would add some sort of hardware dongle, but I would also be aware that it's going to get cracked anyway and the only people that are annoyed/limited by it would be my actual paying customers.
On the other more different hand (third hand?): if my program has requirements about robustness, locality or longevity, I would make sure it depends on as few things as possible, make sure that it's documented well enough for future users and administrators to run it on future environments, and perhaps not sell the software in itself as much as I'd sell support. The risk and downside is that specialised and unique software tends to be quite annoying and costly to create while there isn't a lot of telemetry or feedback to figure out what's working well and what isn't, so that would drive up the price significantly. I'd say you're looking at two orders of magnitude vs. a SaaS thing.
You might like https://scifi.stackexchange.com/questions/392/what-is-the-or... - it's like "grok" tho, only (certain) other nerds will get it.
But, it's a nice phrase; IMHO it's less "third hand" and more "third option/perspective that renders the prior two moot".
Just try to look at a modern Emacs with org-mode and elisp: links. It's a DocUI, with some limits, but far more simpler than a WebApp in a local WebVM. And it's pretty local with full filesystem access and so on.
I'm curious how many more DECADES will be needed to reinvent the wheel discovering that classic local DocUIs are far superior and can be networked as we with technically. My own local fast GMail is notmuch-emacs, and it's not one, it's fully integrated and integrable by myself with few SLoC in my desktop. It's not so nice for some aspects not because of the model but because the little development base. If we invest a fraction of the effort put in modern web the classic desktop would outshine any other tech.
I've often thought, if I had the time and capability ... take it a step further. No server sync at all. Clients form a peer-to-peer network and sync data between themselves. (perhaps bluetooth or something like Apple's Bonjour etc)
Actually something like that, plus an optional server sync when server is available is really even better. I'm thinking specifically of a use case in large warehouses that often have no internet connectivity but in which there are multiple users performing inventory who are duplicating work because they don't know a peer already inventoried a specific area and neither of them can sync to server because no wi-fi.
dang even better. something like a bit-torrent swarm with something like an admin certificate for releasing code patches, and user-level certs for syncing app data.
It all sounds nice in theory until the device suddenly doesn’t want to talk over Bluetooth or your bonjour shares timeout. In 2024 they aren’t foolproof enough to handle constant data interchange, particularly if we are talking about a lot of devices.
Not to mention with BT it’s easy to hit radio interference unexpectedly
Some of these programs managed this better than others. NetnewsWire and 1Password seemed to just work. Byword and Scrivener had occasional sync conflicts that had to be resolved. In general, though, this seems like a nice system: if you (the user) are subscribed to cloud storage, then you get syncing without paying for an extra service. If not, you can still use the software without syncing.
Your server.ts (which uses express) runs in Vite or in a worker (which would require a lot of adaptations/might not even be possible)? If it runs using vite, that's a server. Then the distribution of your app is compromised: or people would run it locally having to start the server or they would need to spin up a server somewhere. How does it become ""serverfree"?
I wonder if there's some legal way of saying, "the web is critical communication infrastructure and all core comms devices need to support X standards"
standards are great but how can I guarantee 200x YoY return for investors? sounds like an unnecessary capx...
I've done user support with users in the mountains who don't have a reliable internet connection.
Being able to say 'don't worry, the app works offline, you can (optionally) sync when you're next in the city' is extremely rewarding, and vital for software to work for these people.
----
Offline-only is not enough either. Ideally users should be able to sync between devices when offline, and have the option to sync to the cloud when online
A huge blocker I didn't grok at the beginning is API keys. Unless the app interacts with 0 services, at all, you need edge functions that essentially just add an API key header to a request from the client.
It offends me because I don't want people to have to trust me, but...there isn't anyone who will recommend otherwise. :/
If an app does that...
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.
Or something like bisq (https://bisq.network) when the program runs locally peer to peer and hosts all user data locally, but still pings oracle servers for outside market price data?
Upgrades don't have to be required. EVER!
1. https://github.com/subzerocloud/my-way-track/blob/main/src/s...
Porting this type of application could take a lot of work! So at some point, somebody invented a programming language called Java, which used a thing called a Virtual Machine, so that one application could run the same way on any computer that could run the Java Virtual Machine. They called this A Portable Desktop Application.
Unfortunately, this obscure language was somewhat difficult to use, so this paradigm was abandoned for simpler languages, and with it, so went the idea of A Portable Desktop Application.
Decades later, somebody reinvented the idea. But it required a much more limited application platform, running inside a kind of hacked-together document viewer, with a simplistic programming language designed to control how documents were displayed. It took about 1000x as much memory and CPU, but, with addition of about 50 different frameworks and 30 different new custom APIs, you could finally get close to the same functionality as the first solution.
Ah, technological progress...
If only mobile phones hadn’t had been so slow when running jvm and flash when they first came out, we might be writing java and flash web apps in NodeJF by today.
"fuck your platform" or less crass "your platform is just one of my delivery vectors" could be the 2015 on mantra for appdev.
Game engines mostly get this right too. You get a rectangle to render everything from scratch and enough abstractions where interacting with the OS directly is a rare occurrence.
The SVP responded as if the guy asking that question had just stepped out of an alien spacecraft from Alpha Centuri. At the time in that room it seemed incomprehensible to most present how anybody could possibly bask in the glory of the Google infrastructure and then want anything other than that.
This may sound a bit snarky, but here is a serverfree app for your enjoyment as well:
<html><p>serverfree</p></html>
What? Is this some kind of confusing reference to lambda and competing providers? As far as I know most of computing is serverless.
Serverless products usually are charging by # of invocations or CPU times, whereas "server-full" products charge you a multiply of "# of servers".
Or just the whole kitchen sink. Why not?
Other than the looming threat of https requirements.