Hi, I’m currently updating my fork of GenieACS and have added several features, including HTTP(S) webhooks.
The webhooks work by marking a device or task object for a specified period via an API call. During this time window, any updates to the device or task trigger the webhook, which sends a copy of the updated object to the specified address.
This feature is extremely useful for programming reactive and responsive frontends. Webhook endpoints efficiently propagate data throughout your application, ensuring that data changes are reflected instantly across multiple windows, which is vastly more performant than polling.
I would like to ask the project maintainers if I could submit a pull request with this feature for review (as per stated in the contributing guidelines)
How much complexity does this add to the code base?
This same behavior can be accomplished with an unmodified GenieACS using a vparam to store the time period, a preset, provision script and ext script. Yes this sounds like a lot of machinations, but is consistent with how the rest of GenieACS operates.
Please don’t take this as me criticizing your work, I’m trying to understand how invasive your changes are and what benefits this would offer over the in-built ways of accomplishing the same task.
1 Like
It does not add much complexity honestly. For the device collection, the most complex part is a simple http request made at the end of the of saveDevice if the webhook matches the criteria.
It’s possible to achieve this with standard Genie, but the process feels unnecessarily complicated. For me, webhooks are a more natural fit when dealing with APIs, especially given the asynchronous nature of the ACS protocol. They also seem to be a better option than using the ‘timeout’ feature in the API, which doesn’t work well with languages or frameworks that can’t handle long HTTP calls without blocking a server workers (like Ruby on Rails in my case)
