Meteor.js vs Firebase

Planet Earth
1

I have been developing with Meteor.js since v0.48 and I was wondering how other Meteorites see the new release of Firebase, specifically the Spark free to start plan as well as all the available features stack up against the Meteor.js ecosystem?

3 Likes
2

Meteor doesn’t just communicate with your database like Firebase does.

Meteor is your frontend, your backend, your API, your build tool, it can be deployed, and it has an incredible community around it. Firebase, as far as I know, just communicates with their servers. That’s it. They leave the hassle of setting up a project, build process, and deployment process up to you.

Plus, Firebase is reactive by default. That means scaling problems later down the road. Meteor uses MongoDB, which can ultimately be reactive or non-reactive.

2 Likes
3

Yeah, I think Firebase and Meteor are like an overlapping venn diagram. Here’s how I understand it so far:

  • Firebase and Meteor
    • data loading
    • security
    • accounts system
    • reactivity
    • hosting platform
  • Firebase only
    • built-in crash reporting, analytics, etc
    • backend as a service
    • data explorer
    • just read and write data
  • Meteor only
    • open source
    • reads from your existing database, so you own your data
    • build system for JavaScript
    • mobile builds
    • ability to write backend code

So if you want to build a realtime native mobile app from scratch, and you don’t need much backend code, I think firebase is more suited for that. If you are writing a JavaScript app that has custom backend logic, integrates with other systems, and you want to use lots of stuff from the JS ecosystem, I think Meteor will help you more.

One thing I haven’t thought about yet is how they could work together - I guess in that case you would use Firebase for all of the data, and Meteor/Galaxy for the build system, mobile wrapper, deployment, etc.

3 Likes
4

I’ve migrated an app from Firebase to Meteor where there are some parts still using Firebase (it was too much of a hassle to migrate that code) and it was an excellent opportunity to learn how much better Meteor is in more ways than you mentioned :slight_smile:

2 Likes
5

Sounds like a great blog post - “how I migrated from firebase to meteor, why, and what was better/worse”

2 Likes
6

Yeah, if only I had 25 hours in a day :smiley:

But, yes, something worth thinking about…

I guess I’ll first need some lessons from you on multitasking :wink:

(or from @arunoda on cloning myself… :stuck_out_tongue: )

1 Like
7

Any other thoughts on this?

Scotch posted a more in-depth analysis of the new features/platform:

  • I’m a little confused about how to work with firebase… does anyone have a good comparison of storing/querying with firebase for somebody who is coming from mongodb?

  • Is the main advantage of meteor at this point its build system? Aside from the learning curve, would webpack + firebase give you basically what you need? Especially as the “full-stack” package advantage (mongo/dpp/blaze) is on its way out?

  • Meteor’s main selling point was not forcing you to glue everything together everytime you added an npm package… with that breakup of mongo/dpp/blaze, now we’re faced with (a) gluing everything together on a meteor stack (b) gluing everything together on a js community stack or © gluing everything together with firebase + js community stack… are we at a point where none has any SIGNIFICANT advantage over the others?

8

Manav Sehgal posted on Quora a great comparison between Meteor and Firebase.

Surprisingly, I wasn’t able to find a comparison between MongoDB and Firebase Realtime Database querying, or a “guide for migrating from MongoDB to Firebase”, even though Firebase was built on top of MongoDB.

The Firebase querying API looks quite different from MongoDB’s:

firebase.database has no support for geospatial queries, regular expressions, aggregations, map-reduce, text search (you need to use Elastic Search for that), capped collections, or even arrays.

2 Likes