4 ms·

Seems like you're describing event sourcing. I'm building an offline-first app and doing pretty much what you're describing. > I always end up duplicating almo

Seems like you're describing event sourcing. I'm building an offline-first app and doing pretty much what you're describing. > I always end up duplicating almost all of the backend logic into the clients as well Yep, this is a pain I feel acutely. I'm using dotnet (C#/F#) because it allows me to ship & run DLLs on the browser with Blazor, leading to significantly less duplicate code. F# can transpile to Javascript with Fable (F# + Babel), so that's also an option. I haven't fully vetted Blazor yet, but it seems good. Clojure can also run on the server and on the browser with ClojureScript. The only other option I see is going fullstack Javascript, and I hate Javascript.

zorr 5y ago
> Seems like you're describing event sourcing. Yes it looks like event sourcing. But most of the classic event sourcing implementations I've seen are mostly backend only. The project I'm currently hacking on has an MQTT broker that is used by both clients and backend and the events can come from anywhere. For example when a client sends a `location_updated` event, the backend reverse-geocodes this into an address and possibly sends out `place_entered` events, or sends out notifications for Tasks that are now relevant on the new location, or "completes" a "go to location X" task resulting in a `task_completed` event. Enabling all this in an offline-first paradigm is hard and requires a lot of duplication, I am very close to just saying screw this and requiring network connectivity for most of the features.
JamesSwift 5y ago
.net is also my choice for this. Xamarin on mobile and hopefully blazor on web in the future. Kotlin is the other contender to keep an eye on in the future (Kotlin Native and Kotlin Multiplatform)