ID of the user should imply this should be a string right? which is what I think the type should be, not User. Since it doesn't make sense to return all of the user metadata for every single emote query, which also requires fetching all of their emote sets. Deep fetching all of the data like this is going to make our HTTP requests incredibly expensive as we scale, and we should try to target minimizing the joins and requests we need to do to fulfill our API contract in most situations, unless all of the user metadata information is always going to be needed whenever an emote is queried.
While AVIF may be supported by all modern browsers, is this something we can also say for certain for any local GUI app that might be integrating with ligmotes? It might be good to still have some sort of compatibility
Should we just use INTEGER and just use the RGB value instead of as a string? saves data at the very least
I'm not very familiar with toolchain tbh. is there a concern with toolchain local?
I personally of the opinion that having an env file that sets the values for each environment is better to go, much more portable and swappable over having to pass a long list of args (which can…
I don't like the idea that we automatically run the up migration every time the application starts up. Is this the best way to do it? I would prefer it was a separate command or something.
