Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: support cloud event deserialization out of the box #1319

Open
2 tasks
a-wallen opened this issue Mar 21, 2024 · 2 comments
Open
2 tasks

feat: support cloud event deserialization out of the box #1319

a-wallen opened this issue Mar 21, 2024 · 2 comments
Labels
feature A new feature or request p3 Issues that we currently consider unimportant

Comments

@a-wallen
Copy link

Description

Support for context.request.pubsub() similar to context.request.json() immediately.

This may work well as a package, but to be honest, I am not sure what the best way is.

I have a few services that I've deployed to cloud run that respond to various Eventarc events.

Would be nice to have this functionality out of the box.

Requirements

  • Implement context.request.pubsub()
  • Implement context.request.firestoreDocument()
@a-wallen a-wallen added the feature A new feature or request label Mar 21, 2024
@jhuckabee
Copy link

jhuckabee commented Apr 1, 2024

I like the thinking behind this. Two questions for you @a-wallen...

  1. What do you envision as the return type of the two methods listed in your requirements? Is that an object from google_cloudevents_dart? For context.request.firestoreDocument() my mind immediately goes to DocumentEventData (defined here).
  2. Does this also imply that we'd have essentially a method per system? e.g. context.request.storage for a Cloud Storage events, context.request.alloydb for AlloyDB events, etc.

@a-wallen
Copy link
Author

a-wallen commented Apr 1, 2024

What do you envision as the return type of the two methods listed in your requirements? Is that an object from google_cloudevents_dart? For context.request.firestoreDocument() my mind immediately goes to DocumentEventData (defined here).

Yes, that would be the idea.

Does this also imply that we'd have essentially a method per system? e.g. context.request.storage for a Cloud Storage events, context.request.alloydb for AlloyDB events, etc.

Yes, we would support all cloud events.

This may be best suited as an extension library.

@tomarra tomarra moved this to Needs Triage in VGV Open Source 🦄 🧙🌟 Apr 2, 2024
@tomarra tomarra moved this from Needs Triage to Backlog in VGV Open Source 🦄 🧙🌟 Jul 1, 2024
@tomarra tomarra added the p3 Issues that we currently consider unimportant label Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A new feature or request p3 Issues that we currently consider unimportant
Projects
Status: Backlog
Development

No branches or pull requests

3 participants