[DX] Switch to Firebase?

[ykdojo]

Description

Relevant discussion: #242, #300

Edit

Someone on Twitch suggested Railway - seems like a solid option.

[CerealPlayer]

I don't think it's necessary.

If you are facing issues with Auth (which is something I've always dealt with in Supa) we can go for the good old NextAuth and manage users on our own. This opens up the posibility to manage Auth with NextAuth and Prisma once we have that setup, which will create just one workflow. (see edit below)

Also, we have these helpers for NextJS which make our life easier.

Edit: See my last comment on #180 . Managing users on our own would mean to switch from supa auth from a simple users table in the public schema and migrate all current users in production.

[ykdojo]

Didn't see those helpers before, thank you! Is there a way, with those helpers, to use an admin-level access Supabase client in an API route? I guess we could just initialize that separately in the API itself?

Managing users on our own makes sense, too. I feel like the question then would be - why would we use Supabase in the first place then?

[CerealPlayer]

For your first question, I think it is possible, all about going through it. I guess if you still want to give it a change we can try it out.

For your second question. Mainly because of Postgres, the platform being good enough and also Realtime which I guess at some point we could make some good use of. Although it's clear to me that there's plenty of alternatives.

Also, Firebase relies on NoSQL so the changes needed would be somewhat bigger?

[ykdojo]

Also, Firebase relies on NoSQL so the changes needed would be somewhat bigger?
Potentially, yes.

I honestly don't have a strong preference either way.

My impression was that the Firebase solution might be more straightforward, but if you want to go with the other solution, I think that could work, too.

The other concern I still have is the backup. I couldn't figure out a way to do that on #240 after doing some research.

[CerealPlayer]

Whatever works, Iif we switch to Firebase I'm sure we can make it work, just a matter of preference.

Personally most projects I've done I used Supabase just as a Postgres db host and Prisma to manage everything db related. However whatever solution that can host a Postgres container will work too like ACI, ECS or Run.

Regarding backup, I just commented on #240

[ykdojo]

Interesting. Using Supabase just as a DB host might work well.

Any reason why you prefer Postgres over other DB?

[CerealPlayer]

It has a lot of features that make it really powerful, though that might make it more complicated. And also, Prisma 🤣

[ykdojo]

that might make it more complicated

Right, that's my main concern.

The original reason why we went with Supabase was to keep everything as simple as possible.

With custom auth, Prisma and everything, it might be too complicated, though.

So based on all these, Firebase might actually be a good, simpler solution even though I know a lot of people are not huge fans of it.

What do you think?

[CerealPlayer]

I tried Firebase just a couple of times on some side projects so I can't say I have enough experience with it. I had the feeling it was a bit similar to supa.

Let's see what everybody else has to say :)

[ykdojo]

@CerealPlayer sounds good!

[takanome-dev]

Hi everyone, here are some differences between firebase and supabase:

• With Supabase, we can easily import a CSV or copy and paste a spreadsheet to kickstart the project. Firebase doesn’t offer inbuilt services that enable us to directly upload bulk data.
• Firebase charges for reads, writes and deletes, which can lead to some unpredictability, especially in the early stages of a project when your application is in heavy development. Supabase charges based on the amount of data stored, with breathing room for unlimited API requests and an unlimited number of Auth users.
• Supabase is a relational database whereas Firebase is a NoSQL database.
• Firebase provides official extensions that can help us integrate directly with other relevant services like Stripe, Google play, Algolia, Twilio, Mailchimp, etc.
• Data migration on a NoSQL database without schema or an ORM such as Firebase could prove difficult compared to using a relational database, which is available with Supabase. It’s even harder when we’re already in production.

For more information:

• https://supabase.com/alternatives/supabase-vs-firebase
• https://blog.logrocket.com/firebase-vs-supabase-choosing-right-tool-project/

[ykdojo]

@takanome-dev right, thank you for the overview. Any thoughts on this discussion or this issue?

[mamonraab]

the main question here .. are we looking for a fully managed backend solution? or just DB?

putting in mind firebase is full backend solution ( so what in firebase you are more interasted in ) that can help make better solution

assuming you look for DB
another note is jumping from SQL DB to NoSQL DB is deepened on what best fit your project

are you need complex queries with a lot of joins and need ACIDs (I am not aware of the full project details so can't make a judgment without knowing the full services if plan to provide )

example of what I do as a checklist

• is it need high ready ops, high write .. or a balance between both
• is it going to be for realtime commuinaction systems
• what about security, scalability, sharding, backup and restore, and migration?
• my data nature are we dealing with very relational data that need complex joins and multi-level queries, or is it less strict and has less dependence
• do we need specialized calculations ( map-reduce, graph queries, geo queries .. etc)

also, we can do multi-DB stack
example auth can use firebase (due to it being easy to integrate with all types of auth solutions)
while keeping the things that need heavy join and multi-relation in some SQL DB

also , you can do joins on firebase but must be carful on how you store your data and them keys. as heavy joins in firebase is costly in term of money