Add CloudEvents middleware

Abierto
  • ¿Algo no está bien?
#96 7 comentarios 0 reacciones 1 asignado Ver en GitHub

@jskeet ya está trabajando en esto.

Desde el 13/2/2021.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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 https://github.com/cloudevents/sdk-csharp/pull/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.

Lenguaje dominante
C#
Estrellas
334
Forks
88
Merge medio
22 min
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cloudevents/sdk-csharp

Todos los issues de cloudevents/sdk-csharp

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.