Comment by filleokus | Hacker News Reader

Comment by filleokus | Hacker News Reader

Parent Full thread

Kotlin Multiplatform looks really cool and limiting code sharing to non-UI code makes much more sense to me. However, I wonder if/when/to what extent the abstractions become leaky.

For me it makes perfect sense to e.g create an internal API client using this. You use platform specific frameworks for making the actual HTTP requests[1], but can write all higher level business logic in Kotlin and expose that. Adding a new REST route or change data validation would be done only once and be in sync on all platforms.

But I'm guessing that you have to pretty knowledgeable about the underlying platforms to know how (and if it's even possible) to create a good abstraction above the platform code. For something like audio/video playback or BLE, I'm guessing that there might be enough differences between Android and iOS that an abstraction that fit both is really unwieldy. And even if you create something resonable today, one of the platforms might introduce new features which destroys your abstraction.

[1]: I noticed that they even have some kind of built-in HTTP client abstraction: https://kotlinlang.org/docs/mobile/use-ktor-for-networking.h...

> noticed that they even have some kind of built-in HTTP client abstraction

It goes one step further, you can have platform-neutral code to parse the API returns into Kotlin models.

https://blog.jetbrains.com/kotlin/2020/10/kotlinx-serializat...

A lot of business logic is shared in the domain layer on each platform client (and possibly on the server), and I think re-use of that is/will be Kotlin's main selling point.

Add SQLDelight for shared data access code on clients, and you can cover a lot of ground with one codebase.

What exactly is the value of this though? Isn't most non-UI code going to be buried in your server APIs no matter what? Most apps end up being 90% UI code.

> Isn't most non-UI code going to be buried in your server APIs no matter what?

As someone who has had to maintain apps across web, iOS and Android, the answer to that is most definitely no.

I don't get it. If you're sharing logic across web and mobile doesn't that demand moving as much work as possible to the server? I've built a plenty of web and mobile apps and that's how I've always done it. Maybe I'm not thinking of the kind of tasks you're talking about. Can you give an example of what kind of process would need to be run on device that's independent of UI?

Giving a good experience with poor connectivity means the clients need to be able to reason about updates to the domain model and potential conflicts. At this point they need to reason about almost as much as the server.

Search for "offline first" to see how people are exploring architectures like this.

Edit: source: I worked on a product bundling chat functionality as a plug in.

In fairness, I think this is not so relevant for apps which are consumption first, but if there's any kind of collaboration, or even just writing from the client, you want to show an optimistic (at least; some systems make the client state canonical) representation regardless of sync status.

Some use cases I think about off the top of my head:

- Data model operations on local copy of data: For some use cases you can't just send everything to the server all the time, instead you want a local representation which is periodically synced with the server

- Logging / monitoring: Expose a single logging / monitoring API which can be shared across platforms

- Input validation / rules engine: Consider implementing a syntax highlighter, you wouldn't want to do that on the backend. Even simple form validation might sometimes be preferable to do client side, calling the multiplatform validate(data_model) and getting per-field validation back would allow for a lot of logic re-use.

- Do work that could be done on the server: Because of a lot of factors, like privacy or cost you might want to do work that could be done on the server. I.e, calling some sensitive third party API (banking?) where you have to transform requests/responses. Or maybe computation on large sets of data (video compression?) which otherwise would need to be sent to the backend.

- Interact with devices only locally accessible: IoT/bluetooth things

You end up duplicating the logic achieve to offline-first, and reduce network roundtrips. Eg your sign up page final validation is probably the server's job, but if you want to give earlier/faster failure messages, you'll want it on the frontend too.

Server authoratative validation is security; frontend validation is UX

If you're moving most of logic to the server, why have an app at all? Just build a website. For me app means offline work.

Mobile apps often achieve better conversion rates than mobile websites - at least for e-commerce.

If it's only the reason why build app, it looks like providing WebView wrapper based app is just fine.

Authentication and identity management comes to mind immediately.

But, of course, there are plenty apps that prefer to do things locally, for so many reasons - if Spotify downloads songs, it does so locally. Or a note taking app such as Evernote needs to capture and compress whatever was drawn on the screen. Not to mention games!

If you think about more than CRUD apps, you’ll see that there are plenty things to be run on the device which are independent of UI.

that’s not true at all. especially for apps like netflix or youtube, but even average apps

source: have worked on apps you likely use every day

I've worked on plenty of small to mid-size apps and that's not how we ever do it. Like I said, we build views and API requests. That's just the same MVC framework for the past decade or so. And I've done the same for streaming services albeit not at the scale of Netflix. Given how apps like Netflix and YouTube are so nicely synced between mobile, web and STBs I'd still imagine all the logic and persistence is server-side. I can only speak from my experience though, I'd love to understand how you've done it and when you need to embed a lot of non-UI code in a client.

Both Netflix and Youtube (premium) can be used completely offline. I would guess that the iOS and Android apps have a pretty encompassing local data model to keep track of everything from watched status to settings changed in the preferences. Not to say that it isn't synced with the server, but the server isn't the only representation.

most MVC apps do still have a decent amount of business logic for things like caching (either http responses, or images, or a local db), authentication etc.. In theory the goal for a lot is to have a dumb client like you said but that's rarely the case.

If you can have your apps share their data models between both android and iOS you can have the apps share the HTTP request/response handling and their DB code etc and then it truly becomes just a dumb client.

YouTube/Netflix also have complex video encoding/playback code that can be written in c++ and shared between clients.

Most social media apps liek FB/Insta/Snapchat have complex camera and photo handling code as well as async messaging code. Which if you have things like retries or photo compression/encryption you'd probably want to share between clients. etc..

Let’s say you’re creating a presentation builder app and one of the requirements is that it work in airplane mode since people are likely to use the app to put together presentations while literally on an airplane. Having all the logic server-side simply doesn’t work for that use case.

Sounds more like you've never written an app.

But put logic aside being able to use the same programing language across platform eliminate a lot of the context switching.

They literally say in the article that 50% of their code is decoupled from the platform.

I am really curious to see people's take on Kotlin Native's compiler. From what I can see with Swift compiler development, there are tons of bugs when compiling down a high-level language. Of course, part of these Swift problems can be that the team choose to pursuit performance and low-overhead above everything else (which complicated the implementation quite a bit). But still, I wonder what Kotlin has done differently to make Kotlin Native reasonably cheap to maintain going forward.

I believe kotlin does not persuit performance and low overhead. But given that there are multiple variants of kotlin compilers (js, jvm, native) I think it will be a lot of work to maintain that, any behaviour need to be done in three places. Assuming that JetBrains can make some money from the Tools they sell, kotlin is probably in the right hands. May be good also have some vested interest for Kotlin to suceed.

fyi Jetbrains is combining the js, jvm, and native compiler pipelines. All three will use the IR infrastructure currently used by kotlin/native.

Wait, are you suggesting to use http 'internally' meaning within the same process on the device?

No. Internal as in to “your” backend API’s.

Reply on news.ycombinator.com