WatchMe – Watch for Changes on a Page(github.com) |
WatchMe – Watch for Changes on a Page(github.com) |
The way we handle it now is that our integration will start throwing serialisation errors. This will then have our platform send a probe to get a RAW response from the system and then we let the admin see side by side, the old data and the new data. This allows the developers to schedule a new deployment to make these fixes. The good thing is that when the new deployment is made, the orchestration around it will handle fixing the data that it couldn't resolve while the serialisation was failing.
We do get other benefits out of this, including the ability to better handle integrations where you have absolutely no idea what to expect from the API e.g. old Oracle, IBM products that don't have discovery endpoints like Dynamics, Salesforce etc does.
Our recommendation after managing so many integrations is "let things fail". Embrace a data integration pattern that allows things to fail.
But as someone responsible for producing API docs, it really pains me to say this! I know my team goes to great lengths to ensure that our API docs are up to date; we even maintain a changelog of every single doc modification, in large part because we have people integrating directly with our Swagger/OpenAPI based docs.
After a bit of Googling, it looks like CluedIn has an integration with us (Zuora). In case it can help you in any way, our changelog is available at [0].
Full disclosure: I work at Zuora, but am speaking for myself only.
[0]: https://community.zuora.com/t5/Developers/API-Changelog/gpm-...
All GUI tools are limited and soon you get out of the comfort zone if you use them for more then 2 things.
That is the main reason I created AU framework[^1] for chocolatey which main choco repo uses to daily watch and update 250+ packages[^2]. Previously they used Ketarin tool which is GUI and was very limited and hard to on-board too. Its basically this, but you program simple PowerShell functions that can check for changes using whatever available in .NET.
The same goes for any declarative tool - you simply need a good programming language all the time.
[^1] https://github.com/majkinetor/au [^2] https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7...
Would be nice to run this from a home server/raspberry pi.
What I'd like to see is a site that generates diffs from webpage changes, and makes them available as an RSS feed you can subscribe to.
Ideally this would be a free service, and I wouldn't mind if the RSS entries were prepended with adverts (or required you to click through to a page hosted by the service in order to see the diff, surrounded by adverts).
The only thing that is not present on a normal Linux system is the xmppsend [1] command for which I use a simple go binary that can easily be deployed.
I see the similarity in making a critical comment regarding a presented project but I think it is different. One of the biggest things Dropbox tackled was to make it a plug and play experience (e.g. you do not have to own a server). With WatchMe I have more the impression that you have to learn a new tool (incl. configuration) and have a more or less limited system afterwards (limited to watching urls or psutils).
I don't really see there any advantage over using shell scripts unless you want to limit what the job creator is allowed to do (which might be a valid use-case). Maybe I am missing something, but from my perspective, it looks like learning to use the existing system tools is of higher value than to learn how WatchMe works (even if their documentation looks nice).
And thus became the buy-ee instead of the buy-er...the price of altruism!