Support for other languages (Dart, Java, etc.)

[Richard Conway]

I think Service Weaver is a genius idea and addresses some of the major drawbacks of microservice development.  Do you have plans to add support for additional languages? Specifically, Dart, Java and/or Kotlin? If so, what does the timeline look like? I'd love to try Service Weaver, but would prefer to stick with languages I know, plus it would open up the project to many more developers.

Thanks and good luck!

Richard Conway

[Srdjan Petrovic]

Hi Richard,

We would love to support more languages and clouds/deployers. The ideal situation is one where we focus on adding more languages, while the community helps us build and maintain deployers.

Our first ticket item going forward is allowing two different Service Weaver apps to discover and talk to each other more easily. After that, we'll start looking at adding more languages. Java/Kotlin seem like more likely candidates than Dart. I'm not familiar with Kotlin, but does it have a way of interpreting the program (like a pre-compile step, which we need to generate the client/server stubs)? I'm assuming that with Java this is trickier.

Thanks,

-Srdjan

[Richard Conway]

Hi Srdjan,

Just saw your email - got sent to spam.  Thanks for getting back to me.  Java/Kotlin are very similar, both running on the JVM and both of which can interpret at run time or be pre-compiled.  Kotlin is a more modern take on Java, reducing boiler plate and including features to make coding easier, more secure, easier to maintain.  But the number of Java developers is still much bigger, so if you want to grow the ecosystem, you can go with Java first. Kotlin programs can mix in Java libraries.  

I haven't had time to dig into the Service Weaver source yet, but from context it seems like you might be leveraging Google's ProtoBuf framework for passing data between services.  Is this correct? I know it generates stubs for passing data for many different languages. 

I'll start looking into what it takes to build deployers to see if I find a match that I can work on.

Regards,

Richard 

--
You received this message because you are subscribed to a topic in the Google Groups "Service Weaver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/serviceweaver/IXcNidiiz8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to serviceweave...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/serviceweaver/2f6bf43d-035b-4791-b9e0-9284496f906an%40googlegroups.com.

[Srdjan Petrovic]

Thanks, Richard.

As an aside, we don't use Protos under the hood. We rely on language-native types that can be serialized. Java's Serializable may work well here.

Similarly, we don't ask the developer to declare their services as gRPC services. Instead, the developer writes a native class/type and registers it with Service Weaver. For Java, this would be a Java abstract class, with methods declared on it. Each method essentially corresponds to a RPC call. 

Service Weaver then needs to inspect the source code, find all of the Java abstract classes that are associated with it, and auto-generate RPC stubs that correspond to those abstract classes' methods.

I wasn't sure if this is something that Java/Kotlin support? Languages like Go and Python allow this level of source code inspection.

[Richard Conway]

Hi Srdjan,

Yes, Java and Kotlin have strong support for interpreting their own classes for methods.  It's called "reflection" in Java terminology.  It's baked into the capabilities of the language. So there shouldn't be any issues going that route, in fact it might be easier in Java/Kotlin than in Python and Go.

I was thinking that the developers would write native services and then  Service Weaver would analyze the classes and generate native gRPC stubs for them since gRPC has tools to generate native language stubs and that would be less work for you. Thanks for the clarification.

Really great idea. I've been avoiding micro-services because of all the downsides - which Service Weaver rectifies. 

Regards,

Richard Conway

[超级无敌阳光帅气的二狗]

Will you consider supporting rust?

[mwhittaker]

We don't have any short term plans to support rust, but in the future it is possible!

[San Nguyen]

Hi, is there any plan to support python?

[rgrandl]

Hi San,

There are some folks working on adding support for Python and Java. We will provide an update when it becomes readily available.

Thanks,

- Robert