Thought and improvement of the js-sdk

[raymondsze]

Describe the proposal

I've take a look into the code details in this js-sdk.
Currently dapr message type can be divided into 4 category.

Service invocation, Pubsub, Binding and Actor

Assume the communication protocol is Http, the endpoint mechanism is like this

Service Invocation

• GET/PUT/POST/DELETE <app>/<methodname>

Pubsub

• POST <app>/<route>

Binding

• POST <app>/<bindingname>

Actor
Actor Method

• PUT <app>/actors/<actorType>/<actorId>/method/<methodname>
  Deactivate
• DELETE <app>/actors/<actorType>/<actorId>
  Timer
• PUT <app>/actors/<actorType>/<actorId>/timer/<timername>
  Reminder
• PUT <app>/actors/<actorType>/<actorId>/remind/<remindername>

All of these are Http call being called by the Dapr sidecar application. With http nature, we should able to

1. Obtain the original payload (for example, in pubsub case, we can have custom cloud-event, but we cannot get the cloud-event instance in current js-sdk)
2. Specify the response status code (currently, seems like throwing error in the invocation block cannot be catch by the dapr client side.)
3. Able to extends the server instance, for example, specify some express middleware like helmet or something else.
4. Specify header for service invocation and actor method invocation, seems currently js-sdk is unable to do it.

For gRPC case, we can just switch header to metadata, status code to grpc error code.

And, I have question about the sdk design nature.
The dapr nature would query pubsub config via /dapr/subscribe endpoint and then route the corresponding payload to the target route. This can be done purely without this js-sdk. Its same if we do the service invocation. However, its hard to implement actor part without the sdk. If I use this js-sdk, it is forced me to use the server instance provided by this js-sdk.

Let's say I've a nestjs server instance, and want it to be a dapr application which will be started with the dapr sidecar. I'm unable to simply extend the nestjs server to support actor feature. With nestjs, I can enjoy the benefit of some features like validation pipe, grpc transport, exception filer, etc. How about providing utilities to help developer to do the dapr integration instead of providing the server instance?

[XavierGeerinck]

Thank you for opening this issue! Happy to help clarify a couple of things on the design of the current SDK and open to discuss around it.

The SDK was built with the goal in mind of: "Being easily accessible, removing the need for basic boilerplate setup to allow developers to get started building microservices almost instantly". We could phrase this differently, but basically, we want you as a developer to instantly be able to get started.

Dapr as a runtime provides this in 2 different modes that we distilled out of its workings:

1. Client interaction (you interact with the sidecar)
2. Server interaction (the sidecar interacts with you) - this includes Actors

These modes are compatible over 2 different protocols (which the JS SDK both supports btw):

1. HTTP
2. gRPC

Currently we do not support the usage of a custom server implementation (though you theoretically would be able to do so) since it requires our users to think of things such as data serialization (on gRPC side mainly), metadata support, body size support, ... everything the Dapr sidecar encourages or enforces you to have as support. This is as well driven by that we want to provide an out-of-the-box experience rather than a configure-it-all experience.

Now as time progresses, we are aware of some roadmap items that are quite crucial and that I think might impact some of your requests. One main item that we are currently high-level wise thinking of is to be able to extract the Actors runtime from the main @dapr/dapr package and provide it as a separate package (e.g. under @dapr/actors. But this task is quite some work and not highly on our agenda as we are currently trying to stay up to date with the upstream Dapr features that are coming soon (e.g. Bulk Pub/Sub as well as the Workflow API that is in spec writing)

To close my thoughts of, we are indeed aware of what you are asking, but I think its a different shift in thinking and would require a quite sizable rework. Nothing however, is currently preventing us from closing this question though as we are learning from our community and wanting to improve upon it. It's currently just not on the table due to the time allocation that the contributors have to focus on this (me personally it's mainly a "hobby", other maintainers have other projects as well, ...).

We discussed this in the JS SDK Sync call and the other maintainers will help shine some light on this as well! We are as well looking into opening that call so we can have a broader discussion around it if you want