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
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.
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.
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:
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.
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.
