Add CloudEvents middleware

[rynowak]

Description

As part of the Dapr project - we wrote our own middleware to unwrap a structured cloud event. This seems like a generally useful feature - but because we wrote it ourselves separate from this project and tailored to Dapr's needs, it doesn't interact with the any of the goodness here.

https://github.com/dapr/dotnet-sdk/blob/master/samples/AspNetCore/RoutingSample/Startup.cs#L78
https://github.com/dapr/dotnet-sdk/blob/master/src/Dapr.AspNetCore/CloudEventsMiddleware.cs

Dapr uses the cloudevents format (only structured json) for pub/sub messages. The middleware gives users a pretty idiomatic experience for using ASP.NET Core's primitives to interact with the payload of the cloudevent (data or data_base64).

How this works in practice:

• Dapr sends an HTTP request to the app using the structured JSON format
• The middleware unwraps the envelope
  • The envelope is read as JSON
  • We replay the contents of data or data_base64 into the request body
• Some other piece of code (likely MVC) reads the request body and doesn't see the envelope, only its payload

What we're currently missing is that we don't persist the envelope of the cloudevent anywhere the use has access to. Example of what this might look like.... If we're going to expose the cloudevents envelope, then it seems useful to be able to do so in a strongly-typed way.

This ends up being a really useful pattern for an app that needs to receive a cloudevent, but the app code wants to use existing tech to read the payload. It feels like this is a generally useful pattern and we could converge this functionality with the cloudevents package rather than supporting it in Dapr as a one-off.

I'm starting to have some conversations with users that do want access to other properties on the cloudevent, so ultimately we want to leverage what's been built here already.

Why didn't we do this earlier?

We are unwilling at add Newtonsoft.Json as a dependency for just this feature given that the other 95% of our functionality uses S.T.J. If #94 is going to happen, then it makes sense for us to to contribute to and rely on this project, rather than building partial functionality that overlaps.

What would it look like?

I'd like to contribute the middleware if it can stay close to the current design, and hopefully support a super-set of the features we have today. Our users are using this pattern today (middleware unwraps the event payload, using MVC or some other mechanism for the app to read the payload).

We'd need to go though some kind of deprecation period and point users to this package, eventually removing our functionality in favor of this. If the middleware lands here, I'm not sure if we'd ultimately need to take a dependency on this package in our code, or just tell users to install it 🤷

If you don't think the middleware belongs here, I think it's likely we'll still want to start using functionality from this package once #94 happens.

[jskeet]

Thanks for raising this issue and providing details of the middleware. I'll have a closer look at it next week - which is good timing, as I'll be looking at the CloudEventFormatter aspect of things then.

[jskeet]

Apologies for the delay in updating this. #94 now has happened, so you'd be able to depend on CloudNative.CloudEvents and separately CloudNative.CloudEvents.SystemTextJson.

The CloudEvents SDK has changed API quite a lot over the last 6 months, and we'd like to release a 2.0 version "reasonably soon" - could you have a look at what's currently available (there are recent 2.0.0-beta.3 packages) and see if it helps you?

[rynowak]

Thanks @jskeet - will try this and and see if the beta lines up with our needs.