35 comments

[ 20.0 ms ] story [ 379 ms ] thread
Hi, I'm Andrew and I had this stupid frustration: in order to have a live streaming web plot in my page I am required to either read 10+ pages of JS integration docs, or pay $20+/mo, and usually both.

In the world of HTML5, EventSource and all the modern infrastructure that shouldn't be so complicated!

So I crafted this microservice in a couple of days to solve this unfairness.

It generates an SVG image that does everything automatically, you just need to do some GET requests to feed your live data. It is in early stage testing, so be free to post what you think of the idea and the code, I will be happy to discuss!

p.s. my microservice is currently hosted at scaleway ARM microserver and I am very excited about pushing it to the limits!

> I am very excited about pushing it to the limits!

Looks like you found them.

I ran out of 1024 open file descriptors limit... May be a bug or 1024 connections... :-/ investigating
The classic scaling problem! Justin.tv faced the same one. [0]

> "a sign behind Emmett’s desk read “HAVE YOU CHECKED THE FILE DESCRIPTOR LIMITS?”

Side note... does anyone know why the default FD limit is so low at 1024 on most machines? It seems like there's very little cost to changing it to a high value (e.g. 65535).

[0] http://justinkan.com/three-stories

That is a classic. I would think the default is just an old vestige of mesozoic machine limitations. And its not like everybody is scaling up, most of the time it is indicative of a leak, and you would be happy to get the heads up.
This is very cool, thank you for making it!

I just have one concern: Does the AGPLv3 license mean I need to open-source whatever other service I make that might be making use of this?

AGPLv3 means that if you use the _code_ provided at git repo, you should share whatever modifications you make; Using the service itself is no way affected.

But not having any "Terms of Service" is really a lack here, will be fixing that soon

I do web dev for a living and I'm slightly embarrassed that this is the first time I've heard of the EventSource API. Why would I use it over Websockets, though? It appears that it does the same thing - keeps an HTTP connection open - but without the ability for the client to send anything back.
In this particular case this is exactly what I need - to send server generated events with no way to talk back :) I just use the right tool for the right thing here
My favorite thing about EventSource/ServerSentEvents is that reconnection is handled for you by the browser. EventSource also works over straight HTTP without need to renegotiate the protocol, which is nice for hosts that don't support WebSockets.
I can think of many scenarios where the client needn't send anything back, notifications being an immediate example; I haven't dabbled with either, but I imagine reasoning about EventSource is probably a little bit easier than WebSockets.
I used it for notifications once and it was really nice, as well as trivial to implement on the server side. I think that it can be thrown in to basically any server is a big selling point.
It handles a lot of the details if what you want is to get a stream of asynchronous events. You can certainly implement an equivalent on top of websockets, but the same is true of any protocol, including HTTP itself.
Really love the idea of embedding the EventSource and image update JavaScript in the SVG doc itself! Keeps the host page clean and tidy! Took me a while to get my head round where the python script was "generating" the svg.

A really clean solution, love it!

I'm getting "Internal Server Error" each time I try to connect. Marketing something as "just works" is asking for trouble on a beta release :).
(comment deleted)
You need something more like value-based instead of cost-based pricing for this kind of service.
Agreed, just had no time to invent anything else yet! Thank you for suggestion!
So is this a service or is this open source? Can I set up my own Plotti instance?
This is actually both. And yes, you can run your own instance. Just be sure to share your derivative work too :) I am not ready with step-by-step manuals on running this, but the source is very simple so you can easily get the idea
Umm the page literally jumps up and down when viewed from my phone.
What OS/version do you have? Will be interesting to investigate!
Fun gizmo Andrew! So much cleaner than the one I wrote that pretends it is an animated GIF. Next up you'll want some sort of reflection UI so that user's can mouse over the graph and have it pop up the values from the colors at that point (that feature is in most (if not all) of the plot packages out there. It does look a lot easier to just plop in and go for simple live displays, excellent work.
Thank you! More interaction should definitely be on the roadmap! Not everyone likes too heavy plots though.

btw, I updated the front page with short snipptes of how it can be used for server monitoring.

I'm not usually a fan of plotting tools. I prefer instead to make custom plots in D3. Usually plotting tools are too simplistic to be useful for significantly valuable use cases. This however is an example of a "simple" plotting tool bringing lots of value. Kudos. This is great.
Ouch. I didn't knew that I can just put a <script> into SVG and it would just work. Nice, thanks!
This is one of those rare things that seems so obvious and simple yet awesome that I immediately slap myself in the face for not thinking of it already. Great idea :)
I'm not sure marketing something as just works is good, especially when none of the plots worked for me at all.
I will be very pleased to hear what browser/OS do you use
Should maybe the endpoint for feeding data into the stream use POST instead of GET?
I am adding HTTPS and (some minimal) POST support soon!