Open programsam opened 6 years ago
Looking up an individual jam is probably not doable without a set of separate queries which are best defined in separate functions. But for the ones that correlate to search and browse, this definitely makes sense.
So maybe it’s an endpoint for looking up a jam/jams … which just has the columns in the jams table. Then separately the lookups of various entities associated with jams. Locations, bands, musicians, staff, tracks, etc?
Means the same number of queries to the database but more client to server queries. Not necessarily the best. Maybe a ?extended=true
kind of deal so that it’s optional? When do you need all that info and when do you not…
Also, sometimes it feels a bit redundant to have views that we lookup w data in them and then API calls that do the same data lookups?
Improved this a lot with https://github.com/programsam/binkjs/commit/a6775839627d3a715ddd3a4ec89a905cf34518ec and also https://github.com/programsam/binkjs/commit/1c52a18629d63072ad35da23c6d0ce1c547a3939 and also https://github.com/programsam/binkjs/commit/4c89fc71d2e2ec1104b4593b6249e73b424bb882...
There’s an entire library called
processing
that I wrote for things like “does this jam have videos” that has some redundant or unnecessary components.The fact that pulling up a jam entails using
async
iterative functions is a bit of a bad smell. Refactor out what’s not ideal.