Skip to content

[Webhook] Usability as actual "component"? #54546

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

Closed
mikespub opened this issue Apr 10, 2024 · 6 comments
Closed

[Webhook] Usability as actual "component"? #54546

mikespub opened this issue Apr 10, 2024 · 6 comments
Labels
DX DX = Developer eXperience (anything that improves the experience of using Symfony) Webhook

Comments

@mikespub
Copy link

Description

I've been a big fan of Symfony components (as opposed to the full framework) ever since I integrated the Workflow component by itself with an unrelated framework.

However, in trying to do a similar thing with the Webhook "component", I'm afraid I was sorely disappointed so far. Besides the obvious dependency on RemoteEvent and Messenger shown in composer.json, there doesn't seem to be an easy way to actually configure & use this by itself without all kinds of framework dependency injections on messenger/bus/transport/... level.

Am I missing something obvious, or is there really no way to use this by itself without the full framework around it?

To be clear, I'm not necessarily interested in using Mailer or Notifier as consumers here - although that would be a nice bonus for later since it's already been done in the framework too. For now I'd just like to see it work by itself and add some custom request parsers and consumers...

Thanks for any pointers or improvements in re-usability for the future :-)

Example

No response

@xabbuh xabbuh added DX DX = Developer eXperience (anything that improves the experience of using Symfony) Webhook labels Apr 10, 2024
@carsonbot
Copy link

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@stof
Copy link
Member

stof commented Oct 11, 2024

Standalone usage will need RemoteEvent anyway as this component is used to represent the payload of the webhook (request parsers are about building RemoteEvent objects).

For usage out of Symfony of the client part of the component (i.e. receiving webhooks), you would have to implement the equivalent of the WebhookController for your framework, deciding how you want to process parsed events (which should be asynchronous because most servers expects a fast response from clients to accept the webhook, which is why the core implementation uses Messenger).

For usage out of Symfony of the server part, there is 2 options:

  • if your project uses Messenger, you can use that part in the same way than in a Symfony project (dispatching a SendWebhookMessage in the bus), once you register the SendWebhookHandler as a messenger handler in your messenger setup
  • otherwise, you can use the TransportInterface directly in whatever way fits your project

@carsonbot carsonbot removed the Stalled label Oct 11, 2024
@carsonbot
Copy link

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@carsonbot
Copy link

Hello? This issue is about to be closed if nobody replies.

@mikespub
Copy link
Author

Hello? This issue is about to be closed if nobody replies.

Not quite resolved, but I assume there are no further plans to improve stand-alone re-use

@carsonbot carsonbot removed the Stalled label Apr 26, 2025
@chalasr
Copy link
Member

chalasr commented Apr 26, 2025

Closing as this is indeed not actionable right now. Feel free to ask for reopening if you want to discuss an idea that makes it easier to use standalone, or submit a PR directly. Thanks

@chalasr chalasr closed this as not planned Won't fix, can't repro, duplicate, stale Apr 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DX DX = Developer eXperience (anything that improves the experience of using Symfony) Webhook
Projects
None yet
Development

No branches or pull requests

5 participants