Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add CloudEvents middleware

Aperta
  • Qualcosa non va?
#96 7 commenti 0 reazioni 1 assegnatario Vedi su GitHub

@jskeet ci sta già lavorando.

Dal 13/2/2021.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
C#
Stelle
334
Fork
88
Merge medio
6m
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cloudevents/sdk-csharp

Tutte le issue di cloudevents/sdk-csharp

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.