Here is a usage case I expect to implement that does not subscribe to that rational that a developer would NOT query the database for entries while doing Webhooks maintenance, and hence why I’d like a python endpoint.
In the last 3 facilities I have worked for (all very large facilities with 500-1000 employees), I have implemented a global data point entity (Custom Non Project Entity ) to track user utilization of studio tools relative to a project and user. The rational behind this has been that I can track tool adoption relative to project and user and use this to help the projects succeed and management see the value of our pipeline work. This usage data needs to be persistent and historically available indefinitely (apparently Webhooks purges some of this info). Think of it as a bean counter or a turnstile in a subway. Then with the data in SG we use dashboard pages with graphs to review tool usage as it relates to the departments, projects or users. The hook to add entries into this database often lives in the base class of our tools. Currently we have a hook in our action menu item base class, however adding one directly in our Webhook class is a bit more risky for performance reasons. I plan to create a CRON service that extracts daily usage summaries of Webhooks and re-injects them back into a custom table in SG to assist in ROI/ROA (rate of adoption).
I know this data is in the Webhooks table, however everything about the Webhook data table is non-Shotgun like. A phrase that comes to mind during code reviews is NonPythonic. Managing the Webhook entries in a SG grid is not accessible, natively linking Webhook’s to our global data point table is not possible, the UI is a bit clumsy when you have Webhook names that are long or a long list of Webhooks and now the data is not accessible via the python API. Webhooks largely feels like a separate app strapped on top of SG.
The current implementation of Webhooks is a great spike of work that already appears very promising. I don’t want to overshadow that with my next few bits of commentary. I do mean GREAT! I truly think Webhooks is an astounding addition to SG. However, I believe they need some more refinement to make them more Shotgun-like, hence my persistence here and unwillingness to let some of these things go as “oh-well that’s the way it was meant to be”. Maybe the way it was meant to be needed more user feedback. My biggest fear is that Webhooks will be branded for ever more beta and continued development, improvement and refinement on it become abandoned like other spiked efforts we have seen within SG. Or when improvements are needed to be made they are made to serve internal SG development interests rather than the requests of the developer community. And as a result, throughout this journey user development team come to terms and are forced to accept the warts.
I am also concerned that my feedback into a black box of feature request does not drum up the right conversation regarding the needs for these improvements to warrant change. Hence utilizing this community board and this private section on Webhooks as a sounding board.