Hi Gerard,
Seems to me latency to and from server is a separate issue regardless of
the back end solution.
I was anticipating that the issues using Kafka might be latency between
producer and consumer and whether it was intended to have as many
consumers as web clients out there as the app scales up.
What looked promising to me from the blog
http://www.confluent.io/blog/introducing-kafka-streams-stream-processing-made-simple
was the mention by Jay Kreps of "Event-at-a-time processing (not
microbatch) with millisecond latency" for Kafka streams.
Thanks for mention of Firebase. Had a quick look. Synchronization with
multiple client looks good, but there other requirements we have such as
preserving full change history which still make me think Kafka could be
the best fit.
On 22/03/16 01:55, Gerard Klijs wrote:
Hi Mark,
I don't think it would be a good solution with the latencies to and from
the server your running from in mind. This is less of a problem is your app
is only mainly used in one region.
I recently went to a Firebase event, and it seems a lot more fitting. It
also allows the user to see it's own changes real-time, and provides
several authentication options, and has servers world-wide.
On Mon, Mar 21, 2016 at 7:53 AM Mark van Leeuwen <m...@vl.id.au> wrote:
Hi,
I'm soon to begin design and dev of a collaborative web app where
changes made by one user should appear to other users in near real time.
I'm new to Kafka, but having read a bit about Kafka streams I'm
wondering if it would be a good solution. Change events produced by one
user would be published to multiple consumer clients over a websocket,
each having their own offset.
Would this be viable?
Are there any considerations I should be aware of?
Thanks,
Mark
