Skip to main content

The alter egos of firebase

 So I was tinkering around the internet as usual, when I came to know about open source alternatives to some of the common tools that we use day in day out.

That's when I came to know about firebase alternatives. A service that I used more often to come with a small POC of anything that I want to try out.

A couple of the alternatives were Appwrite and Supabase.

 

I started with appwrite initially, their self-host policy was really awesome and how easy to set it up and get started. 

 

I created a small application on top of appwrite, that I am currently using for my company internal documentation storage. Since it's on top of docker image and resource-heavy I could not deploy it to my AWS free tier server. So sorry about not showing you guys a demo.

 

After working on top of it, these are my main findings;

 

Positive 

  • Easy to use, no doubt on that
  • Pretty straightforward documentation on about implementing the features
  • support for a vast number of SDK, both front end and back end (just like firebase 🔥)
  • community support is average
  • less learning curve if you are into firebase before (I believe they even tried hard to make the API calls just like firebase API calls)

Negative 

  • Even though the documentation is straightforward, when it comes to production deployment there are challenges, like how to deploy the server and how to name the domain etc. (cookies 🍪)
  • storing files was a nightmare sometimes when it comes to giving permission on who can view it and all (it was mostly me, but I could not solve it pretty straightforward when it reaches production)
  • Docker image deployment, the cloud is on the way, so that's a relief 

 

Overall

 One of the projects that I will keep an eye out for. I see potential, huge potential.

 


Now the other project I was more inclined to was that of supabase. Cause of their cloud support I was up and running in no time. I used supabase on my sample budgeting app only to tinker with Chakra UI and supabase. That was a hell of a combination in the end actually. I was using authentication as well as their database (which is Postgres, yay!!!) for all the things inside the app. Now I need to say this, but the team at supabase had done a wonderful job at keeping the documentation and the entire dashboard pretty straightforward to use.

 

I had a lot of fun working with supabase. I was impressed by their support on multiple SDK's. Here is my work if you want to check it out (it's a work in progress, so bear with me).


Positive

  • Just perfect documentation and an easy interface gets you up and running in no time
  • Good community base compared to appwrite I think, I never get stuck at any problem that I faced
  • The learning curve is low, if you are familiar with firebase, Postgres, auth etc, you are good to go
  • Policies are impressive on database layer and easy to implement 

Negative 

  • Documentation on certain topics such as RPC etc can be improved, those are really helpful tools for big projects, so a lookout for those areas will be a boon for the entire project in the future.

 

Overall

I think supabase is one of those projects which is ahead of the curve at the moment. They should keep up the pace and in no time they will be the real deal.

 

At the end of the day, I had fun working on top of these tools. There were moments when I want to throw away my keyboard, but just a bit more research, these tools are really easy to use. There are a tiny bit of missing pieces, but hey! let's face it which project/library is 100% right?!?!

 

Right???

Comments

Popular posts from this blog

A smoooooth operation....

 Backward compatibility...   A word that I used to hear when I started my career. You design your APIs with backward compatibility in mind, don't break anything when you are upgrading, think about this, think about that etc. Well, those teachings from my previous mentors didn't go in vain, as I made a fundamental change in how we report problems @  Gelato .    You see recently @  Gelato , the CS (Customer Support) team moved from A ticketing management system to B ticketing management system, which is a monumental task for all the people involved in the CS team. Even though the fundamental concept remains the same the places, the attributes the concepts, and the naming of different attributes all change if you have this transition. And thus it was a big change for the whole company.    After the decision was taken, the first step was to create a well-written transition document, which the good folks at the CS team tackled. Special thanks to  ...

AI. Will it replace us or...?

AI!! The buzzword is too hot in the market nowadays. Do you have a technical product or an idea? If it doesn't have AI in it, then chances are it's not going to be sold like hot cakes. That is how things have changed lately. It is no wonder why me and my colleagues at Gelato want to see what AI can do in a niche department like customer support and service. And that is exactly what we did. For a company like Gelato, which is in the market for production-on-demand, there are a lot of customer questions you need to answer. It can be related to products, queries about shipping and pricing, and so on and so forth. Thus, our customer support team is always happy to help with these recurring questions. Let's take one example. A customer asked us, "Do you ship to Norway?" Now that is an easy question to answer if you have the knowledge written somewhere where you could refer to it and say, "Yes! As a matter of fact, we do." Following the same thread, the next q...