[dsies]

Hey there - we have documented the tech stack here: https://docs.streamdal.com/en/resources-support/open-source/

Tldr: go, grpc, Protobuf, wasm, deno, reactflow, ts

And yep, you’re right - we are using protobuf to have a common schema between all SDKs, the server and UI.

Re: sdk implementation - it’s basically implementing grpc methods, knowing how to exec wasm and doing a couple of extra things at instantiation. In real terms - it took us about a week to implement the python SDK - that’s with learning how to do wasm, Protobuf and grpc in python + 1 week afterwards to iron out edge cases.

Re: Java - that was going to be the next sdk we do but we have no idea if it needs to be a specific Java version? Should we target lowest possible Java version? We need to have a solid wasm runtime support - so maybe that limits us to newer versions of Java. Is that a problem?

I did Java a looong time ago - so need some outside input at this point haha

[tfsh]

Thanks for the info, sounds like you have a pretty solid tech stack :)

Re Java - If you're looking to maximise compatability, then yeah you should aim to target an older JDK. Virtually all Java projects use at least JDK 8 so that can be a baseline, however many enterprise projects would use closer to JDK 18 at a guess (Google's internally aiming to migrate to 21 in 2024). Generally if there are libraries or features from newer JDKs that you do want to use, I'd say just go for it, since JDK 11, the releases have been yearly (there was a three year gap between JDK 8 and 9) and more incremental.

What I would recommend is using Kotlin rather than Java, Kotlin's completely interoperable with Java, but provides a much nicer development experience. That way Kotlin clients get niceties such as named parameters [1] (which with data classes [2] can pretty well replicate StreamdalClient) [1] and Protobuf DSLs [3] and Java clients still get a first class, completely interoperable API.

No idea what WASM support is like for Java, I suspect it's lagging behind other implementations, however the most popular framework is Teavm.

1: https://kotlinlang.org/docs/functions.html#named-arguments 2: https://kotlinlang.org/docs/data-classes.html 3: https://developers.googleblog.com/2021/11/announcing-kotlin-...

[avgcorrection]

> Re Java - If you're looking to maximise compatability, then yeah you should aim to target an older JDK. Virtually all Java projects use at least JDK 8 so that can be a baseline,

Oracle says that JDK 11 is on “Extended Support” which comes after “Premier Support”.[1] Why not just support JDK 17 and higher?

[1]: https://endoflife.date/oracle-jdk

[dsies]

This is solid - thank you very much. We will do some more research but basically sounds like - go as low as possible, as long as the underlying libs support it.

And re: kotlin - I last worked/played with it in 2016 and recall that it was MUCH nicer to work in compared to Java.

I just did a quick cursory look and it seems like Kotlin only has slightly slower builds compared to Java and rest of perf is basically the same due to generating similar bytecode. Neat!