Make java-sdk as a independent project

[kevinten10]

Do we consider java-sdk as a independent project,

Just like dapr-java-sdk did.

[kevinten10]

Java is an important user, so a project with good readability and maintainability is necessary.

Now it is directly generated through proto, I cannot read and change the code well.....

The dapr-java-sdk is very easy to understand and maintain.

[seeflood]

Thanks for your feedback!
We have always want to build an easy-to-use java-sdk,and @ZLBer is working on it,see #148
Recently he is too busy to do it,are you interested in working with him together to build this sdk? :>

Regarding independent project,we plan to upload the jar package to maven central repo,and I think that's enough for developers to use?

[kevinten10]

I am happy to help.

I have studied all the codes of dapr's java-sdk.
I am currently doing an SDK implementation based on dapr's java-sdk. For details, please refer to [Discussion] Dapr api for SDK model

If layotto needs java-sdk, I am very willing to participate.

[kevinten10]

Thanks for your reply, let me know the ideas of the community!

I think...
It is feasible to provide a jar package for using.
But the benefit of independent project is that it is easier to develop and collaborate,
and attract more people to join in.

[seeflood]

I am happy to help.

I have studied all the codes of dapr's java-sdk.
I am currently doing an SDK implementation based on dapr's java-sdk. For details, please refer to [Discussion] Dapr api for SDK model

If layotto needs java-sdk, I am very willing to participate.

Cool!

1. I read through your post on "api for sdk",are u still working on it? It's a solution for legacy systems to progressively migrate from in-process sdk to sidecar architecture,but the drawbacks that yaron mentioned are indeed unsolvable.
   So I think maybe you don't need to build it for all languages, only a java version "api for sdk" is enough? The benefit is to serve Spring based legacy microservices only.
   And there is no need to implement any components in this "api for sdk", it's just an abstract layer like slf4j. Developers integrate their existing sdk with this layer themselves. Maybe we can call it "slf4j for runtime" or "runtime4j".

2. Regarding Layotto java-sdk, we desperately need it and welcome you to join us ! It's time to think how we work together,since the pull request Add more features for java sdk #148 is stuck for a while.
   @ZLBer Can I delete your unimplemented interface and merge the other code?So that we can work based on your contribution now

[seeflood]

Thanks for your reply, let me know the ideas of the community!

I think...
It is feasible to provide a jar package for using.
But the benefit of independent project is that it is easier to develop and collaborate,
and attract more people to join in.

Regarding the repo:
Actually the idea to start an independent repo for java-sdk has been discussed several times since we start Layotto project.
Currently we didn't do it because Layotto was just launched and a single repo is good for marketing(with higher 'star' and 'contributors' statistics).Finally we will migrate it to a single repo.
Welcome to work together with us to develop the java-sdk,and If you have pain when writing code in a single repo,just tell me and I will migrate it....

[kevinten10]

I read through your post on "api for sdk",are u still working on it? It's a solution for legacy systems to progressively migrate from in-process sdk to sidecar architecture,but the drawbacks that yaron mentioned are indeed unsolvable.
So I think maybe you don't need to build it for all languages, only a java version "api for sdk" is enough? The benefit is to serve Spring based legacy microservices only.
And there is no need to implement any components in this "api for sdk", it's just an abstract layer like slf4j. Developers integrate their existing sdk with this layer themselves. Maybe we can call it "slf4j for runtime" or "runtime4j".

I have the same idea as you.

I am currently building the java version of the api for sdk. It is indeed an abstraction layer. It follows the api defined by dapr and layotto. The underlying implementation is implemented by the sdk of different cloud platforms to help me write code once and run it in any of cloud platform.

At present I have implemented the rpc module, which is the same as dapr-rpc-api API structure. (the good news is that it can run well on ctrip-cloud-platform and aws-cloud-platform).
Now I am referencing layotto-config-api to develop the config module.

In fact, I am trying to promote this project on ctrip. I am expecting that this project can help deploy business code on ctrip-cloud-platform and other-cloud-platforms(aws/...).

We have a technology interest group working hard for this.
If we can participate in layotto, it will be attractive to me and other members.

Looking forward to participating in the construction of layotto.

[kevinten10]

Regarding Layotto java-sdk, we desperately need it and welcome you to join us ! It's time to think how we work together,since the pull request Add more features for java sdk #148 is stuck for a while.
@ZLBer Can I delete your unimplemented interface and merge the other code?So that we can work based on your contribution now

So how can I participate in the construction of java-sdk.

For example, like the following:

Direct refer to dapr-java-sdk and layotto-go-sdk,
Then submit the changes to the layotto-java-sdk directory.

[ZLBer]

2. @ZLBer Can I delete your unimplemented interface and merge the other code?So that we can work based on your contribution now

Yes, of course you can.I'm glad the community has become active.

[seeflood]

At present I have implemented the rpc module, which is the same as dapr-rpc-api API structure. (the good news is that it can run well on ctrip-cloud-platform and aws-cloud-platform).

Sounds cool! I'm curious how you implement these APIs in java sdk? Since they are grpc API and defined by proto files,how you define grpc API in java?

Now I am referencing layotto-config-api to develop the config module.

Wait a minute, Layotto config API is experimental and might be refactored in the future. It's a long story. We are working with Dapr to design config API, and the definition is still in discussion,see dapr/dapr#2988.
After the design proposal be approved by community,we will refactor layotto config API.
(Although in Alipay we have already used config api in the production environment,our internal API definition is different from community version.We are waiting for Dapr community to approve the proposal and then we can refactor both internal and open source Layotto)

We have a technology interest group working hard for this.
If we can participate in layotto, it will be attractive to me and other members.

Looking forward to participating in the construction of layotto.

Wow,we look forward to building the project with you guys!

[seeflood]

So how can I participate in the construction of java-sdk.

For example, like the following:

Direct refer to dapr-java-sdk and layotto-go-sdk,
Then submit the changes to the layotto-java-sdk directory.

Yep,you can refer to dapr-java-sdk and layotto-go-sdk.
Actually we can reuse dapr-java-sdk in some ways,I copied some code from dapr-go-sdk to Layotto-go-sdk and added some declaration that these code attribute to Dapr project ,see https://github.com/mosn/layotto/blob/main/sdk/go-sdk/client/state.go
Maybe we can import dapr-java-sdk and using some grpc interceptors to change the grpc method name.That will be better than just copying code but I'm not sure if we can do it well.

Personally I hope users can use one sdk to invoke Dapr,Layotto and your api for sdk in the future. That is truly vendor-free and 'write once,run anywhere'. But currently it's hard to do it.

[kevinten10]

Hi, let me talk about my thoughts and hope to share:

Although several projects (dapr/layotto/capa) all claim to use a unified API definition, they actually play their own, such as dapr-proto and layotto-proto are independent implementations ( Although it is written the same).

If for the goal of "a user can write once and run everywhere" using an SDK, then we may need to add an abstraction layer on top of it, just like the abstraction layer we do on middleware. Block the differences between dapr/layotto/capa items.

For example, referring to the The Reactive Manifesto, we can jointly launch the "xxxx Manifesto" with dapr, and then define a unified API in this declaration through protobuf. These APIs It has nothing to do with specific projects such as dapr/layotto/capa.
Through this protobuf, a unified API in different languages ​​is generated. For example, reactive-streams-jvm is the implementation of the interface defined by the reactive declaration on java .

After that, the user only needs to program for this library when coding, and then adapt it to the client implemented by dapr, layotto or capa through different adapters.
For example, when I was writing serverless code, I was coding by spring-cloud-funtion, so that I can have a unified coding implementation on different cloud platforms, and then introduce different spring-cloud-function-adapter, adapt to aws, gcp or other serverless platform.

ps: capa (cloud-application-api) is the api for sdk mentioned above.

---

Hi，我说一下我的想法，希望交流一下：

虽然现在的几个项目(dapr/layotto/capa)都宣称使用统一的API定义，但实际上还是自己玩自己的，比如dapr-proto和layotto-proto都是独立的实现(虽然写的一样吧)。

假如为了"用户使用一个SDK可以做到一次编写，到处运行"这样一个目标，那我们可能需要在这之上再加入一个抽象层，就像我们在中间件上面做的抽象层一样，以此来屏蔽dapr/layotto/capa这些项目之间的差异。

例如参考反应式宣言，我们可以联合dapr共同发起《xxxx宣言》，然后在这个宣言中通过protobuf定义好统一的API，这些API与dapr/layotto/capa等具体项目无关。
通过这个protobuf，生成不同语言的统一API，例如reactive-streams-jvm是反应式宣言定义的接口在java上的实现。

之后，用户在编码时只针对这个库进行编程就可以了，再通过不同的adapter适配到dapr、layotto或者capa等具体实现的client上。
举个例子，就像我在写serverless的代码时，我是面向spring-cloud-funtion进行编程的，这样在不同的云平台上我可以有统一的编码实现，再通过引入不同的spring-cloud-function-adapter，适配到aws、gcp或者其他serverless平台上。

ps: capa(cloud-application-api)是上述提到的api for sdk.

[kevinten10]

Sounds cool! I'm curious how you implement these APIs in java sdk? Since they are grpc API and defined by proto files,how you define grpc API in java?

HAHA, you can understand that I copied the code of dapr-java-sdk, and then modified the underlying implementation inside, (call dapr-sidecar in the sdk -> modified to call different middleware SDKs)

Wait a minute, Layotto config API is experimental and might be refactored in the future. It's a long story. We are working with Dapr to design config API, and the definition is still in discussion,see dapr/dapr#2988.
After the design proposal be approved by community,we will refactor layotto config API.
(Although in Alipay we have already used config api in the production environment,our internal API definition is different from community version.We are waiting for Dapr community to approve the proposal and then we can refactor both internal and open source Layotto)

If like the above, there is a unified API definition file, (it may be independently deployed in maven), then I can directly reference it and update my code when it is modified.
But now, I can only modify my code to keep up with the community.

[seeflood]

@kevinten10 I really like your idea. But currently I don't know how to generate language specifc API (not grpc API) from proto files. Give me some time to understand your reactive-streams-jvm example.

Is capa your personal project or Ctrip's project? If an influential company like Ctrip wants to do this,then the idea that we jointly launch the "xxxx Manifesto" with dapr is more feasible and easy to promote,since we can say that "Projects and Developers from Ctrip, Alipay and Microsoft have signed the manifesto"

[seeflood]

Personally I was thinking about another idea recently. I want to launch a project to integrate Spring Cloud(or SOFA boot) project with existing sidecar like envoy,mosn,dapr and layotto. If we have such a java API, it will be much more vendor neutral

By the way, I just merged the java sdk pr #153 .We can work on java sdk based on @ZLBer 's contribution now

[kevinten10]

I'm also thinking about how to make a unified API recently.

capa is currently incubating. It has a project in Ctrip, but it has not been completed yet, so we have to wait for it to be used before we can say that Ctrip is using it...

I have already started working on java-sdk, maybe I can develop and submit on a separate branch, so that other java-sdk developers can see the updates in time?

[seeflood]

capa is currently incubating. It has a project in Ctrip, but it has not been completed yet, so we have to wait for it to be used before we can say that Ctrip is using it...

Haha,I get it.So we need to build api specifications and products with community influence before we can attract users.

I have already started working on java-sdk, maybe I can develop and submit on a separate branch, so that other java-sdk developers can see the updates in time?

It's ok to submit pull request directly to the main branch if you think some features are completed.Of course, if you think the current development is still immature, you can work on a separate branch

[kevinten10]

I consulted dapr about the progress of the standard API in the dapr/dapr#2817

I don’t seem to see much progress so far. Regarding the standard API, I wrote a sample cloud-runtimes-jvm I might publish it on maven first

I think the subsequent java-sdk can be developed based on directly referencing similar API definition packages?

By the way, I used the decomposition mode #194

[seeflood]

@kevinten10

1. Regarding the value of doing this and whether to do this: I thought about it carefully. If we define a set of java api spec similar to slf4j, the biggest problem is: the java microservice ecosystem has been monopolized by spring, and spring programming model (various annotations) is already a java api spec in the de facto sense, which means that we are actually starting from scratch to do the same thing. For example, spring cloud has an annotation, then spring-cloud-alibaba, spring-cloud-netflix have to implement it, so this annotation is already a java api spec in the de facto sense.
   This may not be a technical issue. Is it worth doing this, and how to promote it after doing it? Even if we design a set of interfaces, the users of spring cloud will not program to our interface in the end, but to the programming model of spring cloud. We are just an intermediate layer that is transparent to users and lose the meaning of defining the interface.
   This is my personal opinion. Let’s wait and see the opinions of the Dapr community.

2. Regarding how to design the interface: I read the definition of https://github.com/reactivegroup/cloud-runtimes-jvm. At present, it paste the Dapr interface and rely on the reactor-related package. This may not be universal enough. If we are gonna do this, we need to discuss whether to redesign the interface

3. Regarding whether Layotto's java-sdk imports cloud-runtimes-jvm: We can currently implement it independently (such as pasting the interface, keeping it the same as Dapr's sdk api), and then refactor to directly import cloud-runtimes after the java api spec reaches a consensus; after all, this matter is still being discussed and will be changed at any time. Doing it directly in Layotto-java-sdk will affect users (some users are already preparing to use Layotto java sdk)

Chinese:

1. 关于做这件事的价值、是否做这件事：我仔细想了下，如果定义一套类似于slf4j的java api spec，最大的问题是：java微服务生态已经被spring 垄断了，spring的编程界面（各种注解）已经是事实意义上的java api spec了，这意味着我们其实是在另起炉灶做同样的事情。比如spring cloud有一个注解，spring-cloud-alibaba、spring-cloud-netflix纷纷来实现它，那么这个注解已经是事实意义上的java api spec。
   所以这可能不是个技术问题。是否值得做这件事，做了这件事后咋推广？即使我们定了一套interface，spring cloud的用户最终不会面向我们的interface编程，而是面向spring cloud的编程模型编程，我们只是个对用户透明的中间层，失去了定interface的意义。
   这是我的个人观点，先等着看下Dapr社区的意见

2. 关于interface怎么定，我看了下https://github.com/reactivegroup/cloud-runtimes-jvm 的定义，目前是把Dapr的interface粘贴过来，依赖了reactor相关的包，这个可能不够通用，如果真要做这件事的话需要商量下是不是改下interface

3. 关于Layotto的java-sdk是否依赖cloud-runtimes-jvm : 我们目前先独立实现（比如把interface粘贴过来、和Dapr的sdk api保持一样），等java api spec达成共识了再重构成直接依赖cloud-runtimes-jvm 吧；毕竟这个事情还在讨论，随时会改，直接做在Layotto-java-sdk里会影响使用（已经有用户准备用Layotto java sdk了

[kevinten10]

Hi, Thanks for sharing your thoughts!

1. Yes, I also want to hear the voice of the community. But interface may still need to be defined, but the follow-up work may be to adapt it to spring annotations

2. At present, cloud-runtimes-jvm is just a sample attempt, mainly keep in sync with dapr

3. Yes, implementing a sample on layotto is currently not a stable solution. I will try this sample on capa. For layotto java-sdk, refer to dapr.

ps: We plan to open source capa to github, and we will publish it in capa. We will make some such attempts on capa.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue or help wanted. Thank you for your contributions.