Create a Sidecar console project

[iancooper]

Is your feature request related to a problem? Please describe.
The goal here is to allow us to run Brighter as a sidecar

Describe the solution you'd like
Implement the Dapr Pub-Sub specification i.e. we can hot swap for Dapr
https://github.com/dapr/docs/blob/master/reference/api/pubsub_api.md

Describe alternatives you've considered
Using RESTMS as the API over using Dapr. It is possible that might be a viable alternative, but I think it is open question if you need the AMQP 0-9-1 primitives in the API as RESTMS has, or if it's just easier to be able to hot swap with Dapr. Of course, it does mean Dapr can hot swap with us, but so be it.

[iancooper]

Interesting question is, do we want the callback to be in ServiceActivator (requires ASP.NET in Service Activator) or stand alone. Adding ASP.NET to service activator does open some things we have resisted, such as a monitoring endpoint on the service

[Shawn-Fan]

What a very exciting project.
There are many client APIs(Net, Java, ...) for Dapr runtimes and pub/sub api is called by the client API.
I am wandering if the project (Brighter as a sidecar) supports all the APIs(net, java,...) or just for one specific client API(for example .net api) or else? how the Brighter as a sidecar works(In the application code/ In the client API/ In the Dapr sidecar)? Thanks in advance!

[iancooper]

@Shawn-Fan it is a proposal for now. Dapr is just a simple HTTP API over transports, we already abstract transports, so we could build something similar. As I think more about this though, I think Dapr's API is very lilmited and it might be smarter to use something like RESTMS to build a sidecar.

[Shawn-Fan]

@iancooper After some researches on it, the workflow could be as following:

1. microservcies A--> sidecar(Brighter) --->Dapr (API interface->server) sidecar A====> Dapr sidecar B-->sidecar(Brighter)-->Microservices B
   OR
2. microservcies A(Brighter + Dapr net API) -->Dapr sidecar A====> Dapr sidecar B-->Microservices B(Brighter+ Dapr net API)
   The problem is that Brighter works on pub/sub of Dapr runtimes not traditional bus, something in Brighter should be changed. your idea?

[iancooper]

@Shawn-Fan

I think that Brighter and Dapr solve the same problem. They are abstractions over message-oriented- middleware, provide a message pump to pull messages of a queue etc.

The difference is that Dapr runs not as an library, or framework for the consumer, but as a separate process that you call using HTTP. In return for that latency, you get to use one library across your microservices, regardless of the stack they were written in.

The issue with Dapr is, I think, how abstract it interface over middleware is. It really is lowest common denominator, and although you can use configuration to try and deal with the platform, I think it's possible to expose a better API using something RestMS.

Dapr is interesting, but I don't know how much our abstracting Dapr is useful, as opposed to providing our own sidecar.

Let me turn the question around, why would you want to use Brighter to abstract Dapr? What benefits would you see?

[Shawn-Fan]

@iancooper In my knowledge, the Dapr messaging is the abstract layer above the communication among the kubernetes(pod) in the cluster. This is the reason why Brighter should be used to on the layer, or else, we do not have to use Dapr.

[iancooper]

@Shawn-Fan Dapr is an abstraction over multiple possible transports, RMQ, NATS, HTTP etc. In that sense it is no different to Brighter. I don't think we would consider it a transport.

[Shawn-Fan]

@iancooper Yes, Dapr supports multiple transports. what I thought from the source code of http/grpc interface:
https://github.com/dapr/dapr/blob/master/pkg/http/api.go
https://github.com/dapr/dapr/blob/master/pkg/grpc/api.go

what is the better way for applying Brighter in Dapr ?