Hi all - I have been working on an open-source Kot...

# multiplatform

[Mike Dawson]

Hi all - I have been working on an open-source Kotlin Symbol Processor (door) that can automatically generate an HTTP server endpoint and offline-first repository based on a Room database (multiplatform client currently supports Android, JS, and JVM). Instead of having to manually write an offline-first data layer with 5 extra classes, and then write server http endpoints, if the client is Kotlin, and the server is Kotlin, it can generate a KTOR server route with endpoints and an offline-first repository for JVM, JS, and Android.

I've outlined it here:
https://medium.com/@mike_21858/auto-generating-an-http-server-and-offline-first-data-layer-based-on-a-room-database-using-kotlin-a24f376db7ef

It's not ready for use in other apps just yet, but the proof-of-concept is working and it is being stabilized. Feedback / comments / questions on the API are welcome.

[mikehearn]

This is really cool! Also, points awarded for nominative determinism! 😆

You may get some interest from the "LoFi" Discord. https://localfirstweb.dev/ <-- they're not as web focused as the domain name makes them sound and they're all about local replication of dbs and stuff.

Have you considered using the same tech with desktop apps? Using Kotlin/JVM and Compose or JavaFX, for example? Then you could have a unified architecture and codebase across all devices

[Mike Dawson]

Thanks! The link does look relevant. I might submit something to that soon. I also used to think that the answer was to have a local database, a remote database, and then sync the two. The problem with relying on sync only is that 1) you make the user wait for the sync when they login (never goes down well these days) 2) syncing everything a user could ever access is likely to be a waste of bandwidth and storage.

What if an admin user with access to everything logs in? I think what is needed is push (e.g. when the server has something that is likely relevant for a particular client, such as when the user has selected something that they want sync e.g. course, discussion topic, etc) and pull (random access anytime for the results of a given query as/when the user accesses a particular screen). When data is pulled, it should be stored in the local database and available next time even if the network connection is gone.

I'm already using this with desktop/JVM apps 🙂 and right now building a Jetpack Compose desktop app. Door already generates JDBC code, which can be used in a desktop app via SQLite/JDBC. I also used Paging Multiplatform ( https://github.com/cashapp/multiplatform-paging ) - so the paging PagingSource is also ready to go for Compose desktop.

[mikehearn]

Ah that's great! Check out https://conveyor.hydraulic.dev/ to make it easy to deploy your app. We can also feature you on our blog, I'm quite keen on promoting this type of low latency UX experience - it can be great even for cases where you have good network connectivity, but of course it's especially great for your use case of countries with poor networking.

[Mike Dawson]

Thanks! I was already planning to use conveyor to build our desktop app (which I think will be free for us as our app is open-source on a public github repo).

A feature on the blog would be awesome, most appreciated! I'll DM you when it's ready (right now as per the medium post we have a bit of work before it's ready to publish for use in other apps, but should be ready within weeks).

I think offline-first low-latency for desktop apps makes a lot of sense: no one ever complained about things loading too fast. If a desktop app doesn't work offline and/or provide low latency, then it doesn't have as many advantages over a web version. Even in high income settings, connectivity on planes, trains, and rural areas (e.g. the English village where my aunt lives) is still not great.

[mikehearn]

Yes it would be free in that case.