I've been posting high-quality audio of my #looptober tracks at https://music.mysteryhouse.studio/library/albums/2/ and funkwhale is impressive and ambitious but it also feels like wordpress, where you go into it thinking "Oh cool I'll just spin up a little blog" and then you realize that it has about 200 more features than you want and they're all enabled by default"
Like, I just want an account to share some audio tracks, maybe group them into albums, include a player UI if you're browsing the site directly. More like federated bandcamp than federated spotify
repository created 😑
I’ve picked up this thread again and while tinkering with schema have immediately run into the “user” vs “artist” conundrum and am already trying to over-engineer. 
It’s the result of having been burned multiple times over the years by doing the fastest/barest minimum to get a thing working and then having to do all kinds of gymnastics to work around unanticipated edge cases
…in the context of a personal project I know from experience that if I reach a “time to burn it down and start over” inflection point on a personal project I usually just abandon it.
Anyway, re: modeling, while it’s technically true that an album or track can be associated with more than one artist, and that a user could also be associated with more than one artist, I feel like most hypothetical users of an open source federated music publishing thing are going to be solo artists (or, they’re going to be one person who handles online stuff for a band)
The “one account, multiple profiles” thing was what I immediately disliked about funkwhale, so I’m not going there. As a futureproofing concession to myself I’ll make a separate ‘Artist’ model but keep User::Artist, Artist::Track, Artist::Album, etc strictly 1:1 for now
...so I was thinking about building this in nextjs/prisma, partly in an attempt to keep the stack simple, partly because it would be an opportunity to hone chops for $dayjob, but prisma doesn't support unions or polymorphism which is going to make things like tagging / generic media objects a big pain in the ass, so it's probably going to be a Django Rest Framework backend after all
mehhhh I guess I should take the time to rule out TypeORM
TypeORM doesn't solve the polymorphism problem, but it feels better than prisma, but (and maybe this is a me problem) it suffers from the "has lots of documentation that doesn't really explain how anything works if you aren't already familiar with it" problem
Anyway, it occurs to me that if I’m using UUID primary keys then I shouldn’t need to worry about data types in a hypothetical “I just want m2m tagging without umpty join tables” scenario, at least from one side of the join. I could still kluge a ‘type’ field into the join table to be able to query by tag + type if I needed to
One of the hardest shifts for me to make as someone who learned how to build web stuff when most people were still on 56K dial-up connections is the modern "just indiscriminantly make a bunch of HTTP requests to load the various parts of a page, whatever 🤷" philosophy
Since I decided to implement my own generic foreign keys for things like tagging, it means I lose the ability to do prisma queries that automagically return collections of related objects, which means that I either need to write a bunch of extra code to achieve that server side, or just give in and make multiple requests (and, in turn, multiple db queries) to load that data sequentially on the client side. It's not a _ton_ of extra requests but it feels so... inelegant
...I also have a stubbornly hard time with the whole "better to load a page incrementally than for a user to suffer the grave indignity of having a page take more than a hundredth of a second to respond" thing
like, try surfing the internet on a noisy 56k AOL internet connection and *then* talk to me about page loading times
All of that being said, #trpc is some next-level shit once you start to wrap your head around it https://trpc.io/
I have been very spoiled by Django's ORM
Oof, so if you make a (relational DB) query with prisma and say "Include records from this relationship" it does so by doing a separate query
I think that's the default behavior in Django too but Django has options that let you explicitly specify that a table should be joined, or doing a 'select from [related table] where related_id in [ids from the main query]' instead of doing n+1 queries everywhere all the time
I mean I know this stuff is hard, especially when you're supporting multiple backends, but the response to tickets asking about joins seems to pretty much be "queries are cheap lol"
Huh, not sure what I had going on the other day but Prisma *does* do the "Get the primary records then do additional queries for related records limited to ids from the primary records" thing
lol and lmao
so Prisma transforms datetime fields into native JS Date objects, which is entirely reasonable, but nextjs won't serialize them in server-side operations, For Reasons, so you get fun runtime type errors, and neither project is willing to concede that it might be useful to have the option to enable or disable date parsing.
The only viable workaround not involving poorly documented experimental/unstable additional libraries (as far as I can tell) is to take your prisma results and run them through JSON.parse(JSON.stringify)
great ecosystem
(Update: there are transformers for trpc and/or next.js that use the superjson package to automagically marshal JSON data to native JS objects and vice versa. It works and is not too huge of a pain to set up, but I’ll be damned if I can find the relevant documentation link to share)
