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

Local-First and Ejectable

thymer.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Local-First and Ejectable

#31

Post by wim »

oDot wrote: post #15
wim wrote: post #13

Earlier quoted context omitted.

Sure but not all backend operations can always be mapped to flat files on Dropbox, like when you have certain real-time collaboration features, syncing on graph/tree-like data structures, or perhaps permissions in case of a company tool. That's why longevity of the "data" aspect is usually easy to solve when a copy of the data is already local, but then you still risk losing a part of what it is that makes the app wh…

It serves more use cases than you might think, especially with CRDTs. Nestful is a tree structure and uses Yjs for sync. Permissions can be done in the file system level. Yes, I agree this is not an end-all be all solution, but the tradeoff is often worth it.

Yep love CRDTs but I think we are in agreement that it's a matter of trade-offs whether or not to use a backend (beyond a shared fs service). The idea with ejectable is that if you've decided the trade-off of a backend is worth it to enable certain features/UX, then it's a good way to ensure longevity of the entire app for users.

Re: Local-First and Ejectable

#32

Post by TeMPOraL »

danjl wrote: post #17
pscanf wrote: post #12

Earlier quoted context omitted.

I definitely agree that we should be improving browsers in that way, though I'm not sure that it's easy and I'm pessimistic it'll ever happen. Mostly because - cynically - I think that the vast majority of users will never care about owning data and software, so I don't see the incentive for browsers vendors to implement features to make it possible. In their current state, I personally don't find PWAs + local databa…

There are many customers that care about owning their own data. Despite what you might think, there are lots of companies that do not trust sending their data to the cloud. In addition, there are lots of companies and individuals that have all their data local, for a variety of reasons (often security) and primarily use desktop applications to work with that data. The "vast majority" may never care, but the complimen…

> In addition, there are lots of companies and individuals that have all their data local, for a variety of reasons (often security) and primarily use desktop applications to work with that data. The "vast majority" may never care, but the compliment is still a very sizable market.

Is it still?

From what I saw personally, Azure is eating through this market. They give enough of the right guarantees that mutlinational corporations are fine with processing all their (and their customers') data in it, and from some quick research I've been involved in, it's the one (and AFAIK the only one) big cloud provider you can use in EU with sensitive data in a compliant way, up to and including medical data.

Beyond that, what's really left that most business users wouldn't just prefer to stuff into Azure and stop worrying about handling it?

Re: Local-First and Ejectable

#33

Post by SOLAR_FIELDS »

wim wrote: post #3
wmf wrote: post #2

Most people use the term self-hosting (or self-hostable) instead of ejectable.

One of the important points of an ejectable app is that you can easily move back and forth between cloud and self-hosted. You can always start with the cloud version and then transfer to self-hosted if you change your mind and continue right where you left off. Not just that, you can also move from self-hosted back to cloud. That makes it easier to get start with a service because you're free to change your mind with…

Most software apps that I've seen that are actually "ejectable" and use the "eject" verbiage are unidirectional. Not bidirectional. Meaning you eject once and any changes you make drift from the original implementation make it incompatible to go back. Example I know off the top of my head would be Draftbit. Visual Basic / .NET WYSIWYG would be another example. Both low code platforms, but that's usually where I see people talking about "eject"

Re: Local-First and Ejectable

#34

Post by kiitos »

gampleman wrote: post #26
kiitos wrote: post #23

> Being able to run the server executable locally. This should allow you to simply open the workspace data and continue where you left off. The "server executable" is where basically all of the value provided by these kinds of companies exists. If it were freely downloadable and self-hostable by customers, then the company would be giving away its main value prop, and would only be able to generate revenue by, I dunn…

It doesn’t have to be offered for free. If you sell a lifetime license for your software it’s actually sort of in your interest for customers to self host since then you’re off the hook for server costs. The main thrust here is if you buy a “lifetime” license, it should be your lifetime, not the lifetime of the company that sold it to you.

I think I'm not really communicating my point effectively.

If you sell a lifetime license for your software, then the customer provides a single one-time payment (essentially CapEx) which obliges you to indefinite long-term work and support and maintenance (costs). But you can't support indefinite future costs with a single payment from a customer. The math doesn't work.

Again, if the data is small enough that it can be downloaded and self-hosted in the first place, then almost certainly hosting costs are statistically zero, compared to the R&D costs of building and maintaining and evolving the .exe file that's actually providing the business value.

Re: Local-First and Ejectable

#35

Post by samsquire »

Thanks for the interesting article.

Is anyone not just me hesitant to run their own servers? I think about patching and it becomes a full on devops job to set up something safe and stay on top of upgrades etc.

One idea Ive had is that if the web facing part of the software is just a form saver. It persists the form to disk for retrieval by the local-first server that I run on my laptop after pulling all records.

Would like to talk to persons about this topic: local first and low-maintenance service design SAAS

I wrote about an imaginary cloud service that would be about hosting forms for batch processing later this is similar to the workspace.zip in this article but this is used for the app itself.

https://www.halfbakery.com/idea/Secure_20Form_20Endpoint_20S...

Re: Local-First and Ejectable

#36

Post by RodgerTheGreat »

drowe859 wrote: post #29
RodgerTheGreat wrote: post #27

Earlier quoted context omitted.

The application package you're looking for is a single HTML file with no external dependencies, especially if it avoids minification, obfuscation, or the use of technologies like WASM blobs which require complex external toolchains to disassemble or modify. This is very achievable right now! See tools like TiddlyWiki or Decker, for example. The primary barrier to an entirely server-free or server-agnostic webapp ecos…

I agree, I develop small utilities as single HTML for all the reasons you list (and fun), but having to work around browser protections for some various APIs can be a bummer. The average internet user could be exploited fairly easily if every HTML file had immediate access to all the lower level APIs being introduced[0], and we end up looping back around to some sort of signing or alternative install method (pwa). Cu…

In practice most of those APIs are also gated behind a user's informed consent to e.g. enable access to a webcam or some other sensitive kind of I/O. I'd argue that the HTTPS delivery side of the requirements is superfluous theater pushed by "HTTPS Everywhere" ideologues and doesn't actually enhance the real security and privacy benefits already afforded by requiring manual user interaction.

Re: Local-First and Ejectable

#37

Post by scubbo »

kiitos wrote: post #25
scubbo wrote: post #24

Earlier quoted context omitted.

I think you are underestimating how much people and businesses are willing to pay for convenience. For a business, especially, if the hosting provider costs are less (or even slightly more) than the pro-rated salary cost of the employee who'll need to keep the service up-and-running, that's a clear win.

How did the "server executable" get written in the first place, and how can it be maintained and enhanced over time, if the only revenue stream for the company is from (optional) hosting services? Especially when relevant data for a given customer is small enough that it can be "ejectable" and self-hosted in the first place?

The same way anything else gets created before it exists in order to create revenue - loans and/or early investors.

EDIT: whoops, I missed the second part of your question ("...how can it be maintained and enhanced over time..."). I've already implicitly answered that in my original reply, by claiming that the attractiveness of "optional hosted services" is higher than the average HN reader - who is predisposed to be a tinkerer, a self-hoster, someone who cares about DIY and learning - would assume. There are plenty of existing companies who make their base software available for free, but make a healthy income off of hosting and support. This article doesn't propose anything radically new in that regard - just extending it to "ejectability".

Re: Local-First and Ejectable

#38

Post by kiitos »

scubbo wrote: post #37
kiitos wrote: post #25

Earlier quoted context omitted.

How did the "server executable" get written in the first place, and how can it be maintained and enhanced over time, if the only revenue stream for the company is from (optional) hosting services? Especially when relevant data for a given customer is small enough that it can be "ejectable" and self-hosted in the first place?

The same way anything else gets created before it exists in order to create revenue - loans and/or early investors. EDIT: whoops, I missed the second part of your question ("...how can it be maintained and enhanced over time..."). I've already implicitly answered that in my original reply, by claiming that the attractiveness of "optional hosted services" is higher than the average HN reader - who is predisposed to be…

You give your server.exe away for free, and make all of your revenue in value-add hosting, and maybe professional services stuff to specific customers. You still have to maintain server.exe -- fix bugs, add features, etc. -- which requires engineering resources, time, money.

Someone else comes along, downloads your server.exe, and offers hosting and professional services themselves, as a competitor. To a customer there is no difference between you.com and competitor.com, they're hosting the same thing on different domains. And the competitor gets their revenue the same way you do, but they don't have to spend anything on server.exe, because you're doing all that work already.

Again, this math doesn't work out, at least not for you. The competitor will always come out ahead.

If the claim is that you have some unique ability to produce revenue that isn't available to third parties that download and use your server.exe, then whatever that is, it's not part of the server.exe, just by definition! You've got the server.exe you offer freely, and a different my-server.exe that only you can operate and which has value that only you can extract. So we're back to square one.

Re: Local-First and Ejectable

#39

Post by worthless-trash »

wim wrote: post #3
wmf wrote: post #2

Most people use the term self-hosting (or self-hostable) instead of ejectable.

One of the important points of an ejectable app is that you can easily move back and forth between cloud and self-hosted. You can always start with the cloud version and then transfer to self-hosted if you change your mind and continue right where you left off. Not just that, you can also move from self-hosted back to cloud. That makes it easier to get start with a service because you're free to change your mind with…

I think that ensuring data can load back into a hosted service is a losing proposition.

As software updates, the shape of data changes. This would make a significantly harder problem to solve.

Re: Local-First and Ejectable

#40

Post by apitman »

oDot wrote: post #14
apitman wrote: post #11

Earlier quoted context omitted.

This pretty much matches the way I think it should be done ideally. I'm still pretty new to local-first though. Are there data formats or types of apps that don't lend themselves well to file-based sync? For your app, how do notifications of changes get propagated? Does it depend on the backend (Google Drive, etc) supporting that, or does it just do polling or something?

For the desktop version just watching the directory for changes is enough to achieve that. Nestful is not aware the files are syncing, it just reads files as they are.

Ah ok so Nestful doesn't integrate with Dropbox/Drive directly, but if the user uses something like them for sync, the app picks up the changes?
Post reply on HN