NASA Asteroid API

I do a decent amount of data vis in my day job, but mostly in python (I use Bokeh for the interactive stuff, matplotlib for the quick and dirty “what does the dataframe look like” sort of questions), but not much clientside charting. So, mostly because I wasn’t able to style a bokeh plot as I wanted You might have noticed that Tufte.css doesn’t use totally white backgrounds or totally black text, it uses #fffff8 and #111111. So, I wanted to make the background of my bubble plot look like that, but couldn’t, so here we are., I decided to use Chart.js, which I’m decidedly meh on.

I think I noticed it when I was writing my last post; NASA also has a pretty cool near earth object api, and I got it in my head to make a live bubble chart delightfully visualizing our imminent demise. This was fun-ish because I (a) learned a bit about Chart.js Mostly I’ve learned that I don’t love it. So far it just seems a bit more limited than python tools, but t.b.h. that might just be my lack of familiarity, and the fact that I’m more used to matplotlib style data inputs. Then again, it’s always good to have a clientside option for visualizations, especially interactive ones. Also, the animations seem a bit superfluous. and (b) I muddled through some more async python.

I’m going to write more about the process and the code later, but I’ve got to clean it up first, and I wanted to post something because it’s been forever. So, I cleaned up the python, learning a smidge about better documentation in the process. The repo lives here. Have fun with it, I guess. To be honest, I do not have the energy to go through a how to (I’m doing that for work at the moment, and the process fills me with dread). I’ll summarize some more of my thoughts and feelings though.

1. The async python stuff is a drag, but it does make a difference. I’m not using it in a particularly nuanced way here, but the pattern works. You basically want the coroutines to bubble all the way up to the fastApi endpoints. When they do, you can actually see that it’s running everything simultaneously. It would be worth bookmarking that against Flask’s threading behavior, though.
2. I’m honestly struggling with the proper separation of the visualization and data layers. It was a pain to reformat data to fit the ChartJS requirements (as is probably abundantly clear from this post), then again it wasn’t hard, just annoying. And you get all the delightful customizability that comes along with clientside development. The contrast is a more python-only option Those of us keeping track at home will recall that this whole charade began because I couldn’t style the background color of a bokeh plot., which counts for a whole lot, especially if you don’t care to bother with a hot mess of javascript. Long story short, I really don’t envy the balance that data visualization libraries have to walk in keeping things customizable while easy to use. But I do love the idea of building a bunch of data endpoints, because it feels that lots of different clients in the future will be able to make use of them. I’m not sure how to balance that against the cost of making something that will fill the immediate dashboard/publication requirements.