Kotlin Native SDK

[yasserf]

We have a pretty big issue with our SDKs, which is that it takes ages to write and maintain them, and we don't have a vocal enough community to support that.

I have looked into different tools for allow us to have the write once use multiple times paradigm, and it seems the best approach will be for us to use Kotlin Native

I already done a basic POC for this

So the idea is we write an SDK in kotlin, and we then write thin wrappers around it for the JVM and Swift. For those interested you can even wrap in C++. Won't be as fast, but it does some pretty interesting stuff in terms of garbage collection and such that makes it feel like a solid solution.

Currently the main blocker is the protobuf protocol. The good news is the serialization library now seems to be more solid, which will allow us to have a single parser/builder.

The end goal if this all goes smoothly would include no longer having a JS client and having multiple native clients backed by Kotlin. This way we can always support multiple SDKs.

https://github.com/JetBrains/kotlin-native

Generally we will be avoiding using JSON entirely in the core, which means the wrapping library can use whatever it wants to parse/serialize (GSON, etc).

My availability for this project is pretty limited, but I might add a bit every now and then to get a proof of concept working with events, rpcs and presences since they are very simple. Once those work and are published its a matter of migrating across the code from the JS client into Kotlin code.

The benefit of having the JS extension is also that we can use ALL the E2E tests which is pretty useful.

[redlock]

Hi, Have you considered using plain c ? It has binding to most languages and of course great performance. You don't need a complex class system since there isn't a lost of state to handle like a UI so no need for OO paradigm here. It has solid Protobuf library and support for all major protocols. It is also ready for production unlike Kotlin native. You can probably get to a good start by converting the Typescript client code with code converters such as: ts2c

[yasserf]

@redlock thanks for the input!

The JS client is definitely too verbose in order for us just to convert into C. C bindings to JVM also requires multiple different builds for platforms and such which isn't pretty from what I have seen. But I did spend a couple days trying to build a basic library that ties into python / java and so forth and it worked.

My dream was always to have a C library and then just have wrappers created for it. However the reality of the situation is I won't be able to maintain it properly, it won't allow fixes as easy from the community and it generally won't be as fun. So I'll have to get back to you on that.

[valentinvichnal]

It is a good idea but I would keep the JS client. There are more JS developers than Kotlin, and they might can't fix an issue in a Kotlin base library.

Swift and Java would be nice but we can already use the JS client in React Native and use deepstream for iOS/Android.

[yasserf]

Saying we can use deepstream via React native on iOS and android is a bit of an overstatement to the world of mobile app developers. Sort of like if I wrote the client in C and then said it works in browsers as long as you use web assembly. I personally use React Native, but I know that's because I don't have the skills (or desire) to write a totally native one with xCode and all that hassle.

From a pure time, feature and bug perspective, I think honing in on one SDK works best if we do decide to expand SDK counts, but I would be super happy for the community to continue supporting the official browser version as well!

[redlock]

I tried build a realtime app with react native. The performance was really bad due to the constant serialization needed between the native controls and the javascript vm. It wasn't an option if you want to have a responsive realtime app.

[valentinvichnal]

It is true React Native is not good for everything, with a native SDK we can build multiplayer games for iOS connected to deepstream.

[yasserf]

@redlock I'm going to give the C library a shot. If not now then when (now being relative to when I finish some clients work in the next few days). I would need some help with bindings if you are up for it.

[redlock]

Sure happy to help

[yasserf]

Okay I spent a bit of time on the C library and SWIG, and to be honest I feel it's way over my head. Would have loved to have focused on it before but it definitely doesn't feel like the size of a project I want to take on now. I really don't want to get into the nitty gritty of having to create hash maps, makefiles, linker issues, and so forth. I couldn't even get the python SWIG example running 😂

I think I keep making a roundabout to this issue and I need to really nail home that I'm trying to actually get out of the SDK/server space and more into end user functionality.

As such I'm probably going to close this issue and just focus on just keeping the JS client and server up to date.

Thank you @redlock and @valentinvichnal for your input again 😊😁