Alternatives to Firebase logo

Alternatives to Firebase

MongoDB, Parse, Heroku, Auth0, and Realm are the most popular alternatives and competitors to Firebase.
7.4K
5.4K
+ 1
1.7K

What is Firebase and what are its top alternatives?

Firebase is a cloud service designed to power real-time, collaborative applications. Simply add the Firebase library to your application to gain access to a shared data structure; any changes you make to that data are automatically synchronized with the Firebase cloud and with other clients within milliseconds.
Firebase is a tool in the Realtime Backend / API category of a tech stack.

Firebase alternatives & related posts

MongoDB logo

MongoDB

17K
13.5K
3.8K
17K
13.5K
+ 1
3.8K
The database for giant ideas
MongoDB logo
MongoDB
VS
Firebase logo
Firebase

related MongoDB posts

Jeyabalaji Subramanian
Jeyabalaji Subramanian
CTO at FundsCorner · | 24 upvotes · 353.6K views
atFundsCornerFundsCorner
MongoDB
MongoDB
PostgreSQL
PostgreSQL
MongoDB Stitch
MongoDB Stitch
Node.js
Node.js
Amazon SQS
Amazon SQS
Python
Python
SQLAlchemy
SQLAlchemy
AWS Lambda
AWS Lambda
Zappa
Zappa

Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

Based on the above criteria, we selected the following tools to perform the end to end data replication:

We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

See more
Robert Zuber
Robert Zuber
CTO at CircleCI · | 22 upvotes · 222.5K views
atCircleCICircleCI
MongoDB
MongoDB
PostgreSQL
PostgreSQL
Redis
Redis
GitHub
GitHub
Amazon S3
Amazon S3

We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.

As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).

When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.

See more
Heroku logo

Heroku

8.1K
5.7K
3.1K
8.1K
5.7K
+ 1
3.1K
Build, deliver, monitor and scale web apps and APIs with a trail blazing developer experience.
Heroku logo
Heroku
VS
Firebase logo
Firebase

related Heroku posts

Tim Nolet
Tim Nolet
Founder, Engineer & Dishwasher at Checkly · | 19 upvotes · 273.6K views
atChecklyHQChecklyHQ
Heroku
Heroku
Docker
Docker
GitHub
GitHub
Node.js
Node.js
hapi
hapi
Vue.js
Vue.js
AWS Lambda
AWS Lambda
Amazon S3
Amazon S3
PostgreSQL
PostgreSQL
Knex.js
Knex.js
vuex
vuex

Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

Enough biz talk, onto tech. The challenges were:

  • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
  • Update API and back end services to handle and enforce plan limits.
  • Update the UI to kindly state plan limits are in effect on some part of the UI.
  • Update the pricing page to reflect all changes.
  • Keep the actual processing backend, storage and API's as untouched as possible.

In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

  1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
  2. The Vue.js frontend reads these from the vuex store on login.
  3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
  4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

Hope this helps anyone building out their SaaS and is in a similar situation.

See more
Russel Werner
Russel Werner
Lead Engineer at StackShare · | 19 upvotes · 241.5K views
atStackShareStackShare
React
React
Glamorous
Glamorous
Apollo
Apollo
Node.js
Node.js
Rails
Rails
Heroku
Heroku
GitHub
GitHub
Amazon S3
Amazon S3
Amazon CloudFront
Amazon CloudFront
Webpack
Webpack
CircleCI
CircleCI
Redis
Redis
#StackDecisionsLaunch
#SSR
#Microservices
#FrontEndRepoSplit

StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

#StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

See more

related Auth0 posts

React Native
React Native
Auth0
Auth0
Amazon Cognito
Amazon Cognito
Django
Django

I'm starting a new React Native project and trying to decide on an auth provider. Currently looking at Auth0 and Amazon Cognito. It will need to play nice with a Django Rest Framework backend.

See more
Realm logo

Realm

121
73
9
121
73
+ 1
9
Realm makes it easy to build reactive apps, realtime collaborative features, and offline-first experiences.
Realm logo
Realm
VS
Firebase logo
Firebase
Contentful logo

Contentful

404
121
43
404
121
+ 1
43
Manage content once, publish it anywhere
Contentful logo
Contentful
VS
Firebase logo
Firebase
Google Cloud Storage logo

Google Cloud Storage

645
381
59
645
381
+ 1
59
Durable and highly available object storage service
Google Cloud Storage logo
Google Cloud Storage
VS
Firebase logo
Firebase

related Google Cloud Storage posts

Aliadoc Team
Aliadoc Team
at aliadoc.com · | 5 upvotes · 121K views
atAliadocAliadoc
React
React
Create React App
Create React App
CloudFlare
CloudFlare
Firebase
Firebase
Cloud Functions for Firebase
Cloud Functions for Firebase
Google App Engine
Google App Engine
Google Cloud Storage
Google Cloud Storage
Serverless
Serverless
Visual Studio Code
Visual Studio Code
Bitbucket
Bitbucket
#Aliadoc

In #Aliadoc, we're exploring the crowdfunding option to get traction before launch. We are building a SaaS platform for website design customization.

For the Admin UI and website editor we use React and we're currently transitioning from a Create React App setup to a custom one because our needs have become more specific. We use CloudFlare as much as possible, it's a great service.

For routing dynamic resources and proxy tasks to feed websites to the editor we leverage CloudFlare Workers for improved responsiveness. We use Firebase for our hosting needs and user authentication while also using several Cloud Functions for Firebase to interact with other services along with Google App Engine and Google Cloud Storage, but also the Real Time Database is on the radar for collaborative website editing.

We generally hate configuration but honestly because of the stage of our project we lack resources for doing heavy sysops work. So we are basically just relying on Serverless technologies as much as we can to do all server side processing.

Visual Studio Code definitively makes programming a much easier and enjoyable task, we just love it. We combine it with Bitbucket for our source code control needs.

See more
Amazon Web Services logo

Amazon Web Services

99
39
0
99
39
+ 1
0
The world’s most comprehensive and broadly adopted cloud platform, offering over 165 fully featured services
Amazon Web Services logo
Amazon Web Services
VS
Firebase logo
Firebase

related Amazon Web Services posts

Mohamed Labouardy
Mohamed Labouardy
Founder at Komiser · | 5 upvotes · 21.4K views
atKomiserKomiser
Google Compute Engine
Google Compute Engine
Amazon Web Services
Amazon Web Services
Go
Go
Docker
Docker
Material Design for Angular
Material Design for Angular
Microsoft Azure
Microsoft Azure
GitHub
GitHub

Google Compute Engine Amazon Web Services Go Docker Material Design for Angular Microsoft Azure GitHub I’m super excited to annonce the release of Komiser:2.1.0 with beta support of Google Cloud Platform. You can now use one single open source tool to detect both AWS and GCP overspending.

Komiser allows you to analyze and manage #cloud cost, usage, #security, and governance in one place. Hence, detecting potential vulnerabilities that could put your cloud environment at risk.

It allows you also to control your usage and create visibility across all used services to achieve maximum cost-effectiveness and get a deep understanding of how you spend on the #AWS, #GCP and #Azure.

See more
Mohamed Labouardy
Mohamed Labouardy
Founder at Komiser · | 5 upvotes · 15.4K views
atKomiserKomiser
Google Compute Engine
Google Compute Engine
Amazon Web Services
Amazon Web Services
OVH
OVH
Microsoft Azure
Microsoft Azure
Go
Go
GitHub
GitHub

Google Compute Engine Amazon Web Services OVH Microsoft Azure Go GitHub

Last week, we released a fresh new release of Komiser with support of multiple AWS accounts. Komiser support multiple AWS accounts through named profiles that are stored in the credentials files.

You can now analyze and identify potential cost savings on unlimited AWS environments (Production, Staging, Sandbox, etc) on one single dashboard.

Read the full story in the blog post.

See more
AWS Amplify logo

AWS Amplify

34
27
4
34
27
+ 1
4
JavaScript Open Source Library with React, React Native Extensions
AWS Amplify logo
AWS Amplify
VS
Firebase logo
Firebase
Firebase Hosting logo

Firebase Hosting

44
14
0
44
14
+ 1
0
Production-grade web content hosting
    Be the first to leave a pro
    Firebase Hosting logo
    Firebase Hosting
    VS
    Firebase logo
    Firebase