[Discussion] Dapr api for SDK model

[kevinten10]

dapr is an exciting project!

According to my understanding, dapr aims to provide a unified abstraction layer for heterogeneous middleware and heterogeneous API, so that the code only needs to be written once, and it can run anywhere.

But the problem is that I need to deploy the dapr sidecar process. Although the sidecar model is the future, the current situation is still mostly in the SDK model.

Do you consider supporting dapr api in only SDK model?

Migrating the original system to the dapr sidecar architecture will be more difficult. If we provide SDK model based on the unified API of dapr, this will greatly reduce the cost of use (after all, I don’t need an additional dapr sidecar process).

What I mean is to put the steps of invoking the heterogeneous SDK in dapr sdk instead of in dapr sidecar process. In this way, I don't rely on the dapr sidecar, although this is a rich SDK model.

Full support of sidecar requires the full support of the infrastructure, but in the foreseeable future, the SDK model will continue to exist, so it is necessary to consider the rich SDK model.

For comparison, the dapr sidecar model can refer to: #2817

I once did a project vrml aimed at providing an abstract API and shield the underlying specific SDK. This is the same as the concept of dapr.
If the dapr community considers the SDK model, I very much hope to be able to participate in the construction together.

[yaron2]

@kevinten10 that model was first looked at when we started the Dapr project and was quickly decided as not feasible.

It would mean the entire Dapr code base, plus it's existing components and any future components, would need to be duplicated and written in every language that needs to have Dapr support. This does not scale.

In addition, an SDK only model has the following issues:

1. Dependency collisions between Dapr and user code
2. Inability to set resource constraints on the Dapr layer
3. User app crashes if Dapr panics
4. Independent lifecycle management

I'm closing this issue, but we can continue discussing here nontheless.

[kevinten10]

Thank you for your reply!

As you said, I believe the community must have considered this model.

Although there are many problems with the SDK model, I think this is still a model that needs to be considered for a long time.

What I expect is that dapr can provide an abstraction layer.

If I need this SDK model, then I can implement it based on the abstraction layer.

Whether it is the sidecar mode or the SDK mode, the APIs provided to the outside are unified.

[kevinten10]

The community does not need to implement these functions.

As long as the API design of the abstraction layer is easy to extend.

Then people who have this need can do it themselves (for example, me)

[yaron2]

@kevinten10 take a look at this issue, does this more relate to what you have in mind?

#2817

[kevinten10]

@yaron2 Yes, the abstraction layer is what I want to say.

But when designing the API, please consider the SDK model, not just the sidecar model.

thank you for your reply!