Open source drop: React client, Go proxy, and Mobile app

⚙️ Web integration 🧩 API
1

Hey all, just dropping links to a few things I authored recently which are free and relatively simple to use.

The first is a React client that you can get on npm: GitHub - dctalbot/react-spinitron: A Spinitron API client

The second thing is a companion relay server written in Go that satisfies the terms of service as far as API key mgmt and request caching: GitHub - wcbn/spinitron-proxy

Finally, you can combine the powers of the two things above to release a mobile app: GitHub - dctalbot/spinitron-mobile-app: Customizable Spinitron mobile app

It’s still early days for each of these, but I felt they were stable enough and good enough to be worth sharing here. Feel free to ask questions here or by opening issues on the repositories.

Enjoy!

3 Likes
2

Hi David,

Omg this looks

A M A Z I N G !!

Thank you!

I searched for WCBN in Google Play (the Android App Store) and installed the app. It’s great. From a UI point of view it is almost exactly what I would specify for a white label app based on a station’s live database in Spinitron.

From an architecture point of view, I’m only partly in a position to judge. The API proxy looks fine. (Does it have garbage collection? I couldn’t see how that works.) But I no longer know the state of the art for async state management in React-based apps and Tanstack is new to me.

Concur. This looks like a strong foundation, afaict. Thanks for sharing. I’ll ask more questions when I have time to poke around, learn about the deps, and try some stuff.

Your READMEs are very fine too. Makes all the difference.

3

Nice, thanks for checking out the app!

Yeah, the proxy and its in-memory cache only rely on the native language features in Go which does have a garbage collector.

Re architecture, the main blemishes I’m aware of are:

  1. The actual radio part of the mobile app (streaming audio). This is by far the deepest integration with the platforms the app has to do in order to have things like lock screen music controls, bluetooth controls, and long-running background audio. I have some ideas for how to improve the current implementation, but the maintenance burden ramps up pretty quickly.
  2. The app does some N+1 queries. For example, when displaying the schedule, it does 1 request for the shows, and then N requests for the DJ names. On a given day, we have on the order of 15 shows, so 16 requests, which is survivable. The cache mitigates it to some degree on your end, but it would be convenient if the DJ names were on the initial response. Or maybe a dedicated /schedule endpoint.