Store user preferences + stars in firebase instead of localstorage

[theRealPadster]

Just an idea. Not sure if feasible. We could have a table with users and their preferences (e.g. tabs, stars enabled, etc). This would be linked with their Spotify username/id or something. That way you can have the same marketplace experience on multiple computers.

[CharlieS1103]

https://supabase.com/docs/guides/auth/auth-spotify @FlafyDev

[CharlieS1103]

We need to determine the database structure, is it better to store the individual users and which themes/extensions they've liked in an object for the user, or is it better to store the themes and extensions with all of the users who liked them? We may have to do both.

[theRealPadster]

So I just realized a pretty huge issue with this. We can READ data fine, but if we want to WRITE data (e.g. when a user stars a theme), it will need to have our Supabase/Firebase credentials stored in the publicly-accessible code, which would allow anyone to do whatever they want to it. To get around this, we would need a private server that has the actual Supabase connection, and then POST data to it from within Spotify when we want to send anything.

[theRealPadster]

More notes on that issue:

• We could make a free Heroku account, which has 550h (~23 days) free dyno time. With a credit card verified, that jumps to 1000h. We would need 744h for 31 days.
• Then we could publicly host the server code on GitHub, and use Heroku's config vars to keep the Supabase credentials secured.
• We would also need some sort of DOS protection, since all the write requests would be going through our single (free, not professional-tier) server.
• And we'd want to rate limit by IP or something, so people can't just generate random user ids and boost their stats.
• So, it gets pretty complicated, pretty fast.

[FlafyDev]

So I just realized a pretty huge issue with this. We can READ data fine, but if we want to WRITE data (e.g. when a user stars a theme), it will need to have our Supabase/Firebase credentials stored in the publicly-accessible code, which would allow anyone to do whatever they want to it. To get around this, we would need a private server that has the actual Supabase connection, and then POST data to it from within Spotify when we want to send anything.

There are ways to authenticate users so they won't do whatever they want https://supabase.com/docs/guides/auth

I don't understand what you mean

[theRealPadster]

Usually there is some sort of API key, connection string, or secret, or something, to actually initiate the database connection. So it knows where the database is and is able to write to it. If those are in the code, anyone would be able to use them to write their own code and do what they want, no? Or are you saying since it's hosted, we just need some identifier for our database, and it handles stuff with user logins automatically?

[FlafyDev]

Usually there is some sort of API key, connection string, or secret, or something, to actually initiate the database connection. So it knows where the database is and is able to write to it. If those are in the code, anyone would be able to use them to write their own code and do what they want, no? Or are you saying since it's hosted, we just need some identifier for our database, and it handles stuff with user logins automatically?

Yeah, only the creators have access to the database's content. So people won't have access to other people's API keys