Hacker News Reader

Comment by jitl | Hacker News Reader

It sounds like the stream must be an append-only table. This is awkward - I would expect streaming updated results for a query. If I want clients to refetch changed record in real time, do I still need to build that on top of this stream primitive? Like, I stream an audit log style table, and then refetch any IDs mentioned in the stream separately?

View on HN

I work at Hasura. You don't need an append-only table always. You may have to add a monotonic ID to your table which increments on DMLs (and use it as the cursor for streaming) and this can be done using a post-DML trigger in Postgres. Also, streaming works over tables with relationships as well so you can get related data in the same stream as well.

Also, there is another interface for real-time subscriptions called live queries which might be more appropriate depending on the use-case: https://hasura.io/docs/latest/subscriptions/postgres/index/#... .

This is my favorite kind of schema -- do not UPDATE Person.Name, instead INSERT into PersonNameChange.

With the right indexes and lateral joins/cross applies you can make the aggregate you need when you query instead of when you write.

I think you’re missing the key part which is that this is delivered over a single GraphQL subscription.

So as new data is added to the table, hasura automatically pushes it to the client via the Websocket subscription.

No refetch needed.

Reply on news.ycombinator.com