Software as Service Project with Meteor


Hello Meteor Community,

I am a novice Meteor developer and quite interested in using Meteor for future projects. I currently run a startup company in Kurdistan Region, Iraq, called Meta Solutions:

My company is working on a software as service project. The software will contain lots of data and data will increase more and more as time passes since we are planning to maintain the app, as any other SaaS. I am a Ruby on Rails developer and worked closely with client-side javascript before. For this project, My team and I decided to use NodeJS since our initial research asserted that performance is much more optimized with NodeJS.
Then, I did a lot of research on what to use in NodeJS, the typical MEAN stack or something else. I incidentally stumbled upon Meteor which simply solved all the problems for us. The application we will build is mainly real-time and needs offline DB synchronization. So Meteor is an excellent choice for us.

But we are dubious. The problem is that we are afraid to use Meteor since:

  1. We are not sure if the code base of the application will be maintained and developed by MDG or unfortunately they will stop at some point. In other words, we are not sure if the project is already attracting many developers and hence succeeding.
  2. Some of the packages are outdated and are not updated regularly. We are afraid that this pattern extends for the rest of the packages. I currently realized that FlowRouter is no longer supported since Kadira has stopped its activities.
  3. Meteor changes its core and structure from time to time. Meteor 1.3 has a totally different structure than 1.6. I have spent ours looking for tutorials on 1.6, and unfortunately the only good resource I found was Meteor’s own Documentation, which is excellent but needs lots of studying if you want to build a solid app.
    The problem is the online tutorials (even those on udemy) are created using Meteor 1.3. This is disappointing and makes us more dubious. What if Meteor decided to change structure in 1.7? Then what? We can’t then migrate easily to the new version. I understand that newer versions are backward compatible, but these shifts are unpleasant and makes us think twice.
  4. If we use Meteor for our project, the idea is to use Galaxy for hosting the app. If Meteor project fails at any point, doesn’t that mean that Galaxy will fall too? What we will tell our clients then?

I would appreciate your inputs and I would be really glad to hear closely from any MDG people.

Best of lucks

1 Like
  1. MDG is growing fast and it is one of the most successful frameworks out there.
  2. This happens with any framework you will eventually have packages that are outdated and no longer maintained…
  3. This is not correct, Meteor 1.3 has the same API from 1.6 (with some additions), we upgraded apps from 1.2 to 1.3 to 1.4 to 1.5 to 1.6 without changing any parts of our code-base.
  4. - For Meteor 1.3 – up to date.
  5. As long as there will be paying customers, Galaxy will run, as it’s AWS in the back either way.

Meteor is a great choice and you will not find anything like it.

Here is a package that might make Meteor, even more interesting, show me any other framework out there that supports reactive data graphs:



Thank your so much for the input and the great Grapher tool. It definitely makes my life easier.