Ask HN: Strategies for Providing Live Data to B2B SaaS Clients?
3 comments
Did you look at Server Sent Events (SSE)? It's a web technology, I would assume that there are client implementations in all major languages.
https://en.wikipedia.org/wiki/Server-sent_events
https://en.wikipedia.org/wiki/Server-sent_events
Have you considered message queues? You could push updates to a queue (with reasonable max size limits to avoid overflow). This queue could be exposed through websockets or by using AWS SQS.
Your customers would populate the older data using your existing API, but then switch to the queue for new updates.
Your customers would populate the older data using your existing API, but then switch to the queue for new updates.
Webhooks are definitely the most standard way of doing this in my experience.
Have you looked at svix.com ? (I have no affiliation)
Have you looked at svix.com ? (I have no affiliation)
1. Our clients struggle to access "live" data as we don't offer web-hooks. 2. We don't provide data with applied business logic, such as status reports.
Of course we could (should?) build those things but (A) building/maintaining a web-hook service seems daunting and (B) it feels suboptimal.
The goal is to provide real-time read-only data where my clients don't each have to implement data-sync.
In my head, it feels like we should give each client a small, read-only Postgres instance where we keep updated reports and fairly denormalized data. Then they can just hook into it and setup their own watchers, etc. If they need more muscle, then they replicate it to their own instance. But is there something "better" I could provide?
SupaBase seems close, but again - that's both us and our clients having intimate knowledge of propriatary tooling - whereas SQL (Postgres) is nearly universally known.
So if you were trying to provide realtime data and reports to a bunch of SAAS client IT groups, how would you provide it?