Three streams shipped this week:
100 document parsers with one command
100 finance validators with one command
100 monitoring pages — and this...
For further actions, you may consider blocking this person and/or reporting abuse
❤️😀
I'm building VAT Engine, an EU VAT API. Your VAT_SNAPSHOT is a separate data source to maintain alongside the currency feeds. Would querying a VAT API be useful for this monitor, or do you need a bundled snapshot to keep it self-contained? I'm interested in what would make an external source worth using.
Keeping it self-contained with a bundled snapshot works great for preventing runtime latency and avoiding external point-of-failure issues. However, an external VAT API would be an absolute game-changer if it handled real-time country-specific rate changes and dynamic B2B tax exemptions out of the box.
Would fetching updates on a schedule and keeping your local snapshot work, or do you need a change feed? Also, by B2B exemptions, do you mean VAT-ID checks or deciding the tax treatment from buyer/seller and transaction details? I'd like to pin that down before suggesting VAT Engine is a fit.
Leveraging Cloudflare Workers to handle scheduled snapshot hydration instead of maintaining a heavy change feed completely eliminates runtime state overhead. Isolating B2B VAT-ID verification boundaries directly at the edge is exactly how we keep cross-border compliance low-latency and secure. Prototyping dev tools around this serverless pattern right now.
Thanks, that helps. If you'd like to try VAT Engine for the scheduled rate refresh, the API docs are here: vat-engine.app/docs/api/rates. It's in free alpha. I'd be interested in what you'd need to change to use the response in your local snapshot.
Using Workers for scheduled rate refreshes is the perfect use case. Low latency, decoupled from the main app, and zero server management overhead. Testing it out for a local snapshot sync sounds like a solid weekend project.
The VAT path has a useful distinction to make explicit: as shown here, it's watching changes to a bundled snapshot, rather than discovering changes at the source. What refreshes VAT_SNAPSHOT, and how would a subscriber know that refresh stopped?
I'd add two fixtures: bump
updatedwithout changing any rates (no VAT_CHANGE), then change one country's rate without bumpingupdated(detect the value change or reject the inconsistent snapshot). Keeping source-checked time separate from deployment/edit time would let a successful daily cron report stale source data rather than imply a fresh check. I haven't run the Worker; this is based on the snapshot and date-gated comparison described in the post.This is incredibly solid architectural feedback. Handling stale source data is one of those classic edge cases that completely breaks currency monitors if left unchecked. Separating the source-checked timestamp from the internal deployment time is a textbook best practice. Definitely worth adding those test fixtures to ensure the Cloudflare Worker fails gracefully instead of reporting stale data as fresh.