We started out by making an EventSource endpoint and using JS EventSource object to get updates. Seemed to work great.
Pushed it live.
To everyone on the site. Not just to the people on /l/place. Oops. Mistake #1.
Mistake #2: I was aware that Arc kills threads that take longer than 30 seconds, but I was unaware that EventSource automatically tries to reconnect. Welcome to the DoS party.
With no way to tell the clients to stop. Mistake #3.
It was only live for about 10 minutes, but it took around two hours before the last few clients finally refreshed their browser and stopped DoSing the endpoint. The server absorbed the extra traffic like a champ, but the server logs were ridiculous for about an hour. Lots of "client took too long" error messages spit out by Arc every second.
Sooo yeah, submitting changes via JS is easy. Getting updates is the hard part.
Could poll. But then that's still hammering the server. Moreso than it already is.
It's probably a feature that it's painful to use. Only the determined will use it for art.
That said, if anyone has ideas for how to tweak arc for performance for this scenario – and remember to calculate how much memory is used by how many simultaneous sockets are open – I'd be willing to try again.
> I was aware that Arc kills threads that take longer than 30 seconds...
> Sooo yeah, submitting changes via JS is easy. Getting updates is the hard part.
That's why I suggested a post request...
Just deliver the page and create an api end point, on the server, that gives you the last x changes from the change log.
With that ajax request, you could return these net updates for the client and use client side js to apply them to the dom. You could even create a trivial js debounce algo to throttle requests if you wanted to go even further.