Is it already worth to give Derby.js or Meteor a shot for an app for production with authentication?

I started reading about Derby.js and Meteor to do some research on an project I'm working on. It uses a lot of real time functionalities so they both seem handy. But I have some major concerns and am wondering if it makes sense to use them at this time.

  1. Are they yet production ready? Or are there still major security issues?
  2. Do they by now support sessions and authentication?
  3. Am I right with the assumption that by relying on frameworks that do a lot of the work you might have it easier for the simple stuff but much, much harder if it get's a bit more complicated?
  4. Am I right with the assumption, that I could achieve exactly the same effects (from a user-experience perspective) when I just use Express + Socket.io (or express.io) and that I just have to invest more time/work?

At the moment I'm more drawn to Express + Socket.io and think Derby and Meteor are a bit hyped. What do you think?

To get a better idea of what I'm planning:

  • User authentication is needed
  • Complex routing is needed
  • SEO is an issue
  • Full Text Search using Elasticsearch
  • DB probably MongoDB
  • Complex relations between objects
  • Realtime updates (Socket.io)
  • Security is an issue
  • Performance and scalability are issues.

Thanks!

I can answer your questions for meteor:

  1. YES. There are many of us running meteor in production for revenue-generating companies.

  2. YES. Meteor has had an accounts system since October of 2012.

  3. The more the system does for you, the harder it is to manipulate the underlying mechanics. I find that meteor strikes a reasonable balance.

  4. This assumption is correct. You could also implement your own web browser to visualize HTTP, however I find it easier just to use chrome.

Other Requirements

  • User authentication: Yes, see above.

  • Complex routing: Yes, see iron-router.

  • SEO: Yes(?), see spiderable and ssr and this post.

  • Elasticsearch: Yes, (independent from your framework choice). Meteor doesn't have an ES backend, but you certainly can talk to an ES datastore via a node.js module or directly over HTTP.

  • MongoDB: Yes, that's meteor's default (and only official) DB.

  • Complex relations: Yes, (independent from your framework choice).

  • Realtime updates: Yes, this is how meteor works.

  • Security is an issue: Yes, Emily Stark has you covered! Also see this post on the discover metetor blog.

  • Performance and scalability: Use oplog-tailing and monitor your app with kadira.

There are Meteor answers and there should be for Derby too:

  1. Yes, from 0.6 version Derby is stable enough and there are some sites using it in production, ex: Lever.

  2. Yes, there are some auth modules, ex: derby-login which uses passport

  3. Yes, but the more modular framework is (consist of replacement parts) and the more it follows conventions (npm, Express etc), the less you feel it.

  4. Yes and no. For example if you are serious about realtime, it's better to have some conflict resolution mechanism (OT or CRDT or smth else) and it's not trivial to implement one. By the way, Meteor does not have any, it uses LWW-strategy.

Other Requirements

  • User authentication: Yes, there are some modules.

  • Complex routing: Yes, isomorphic Express-like router.

  • SEO: Yes, built-in isomorphic (client and server) template engine. Html for first request renders on server, for subsequent url-changes it renders on client.

  • Elasticsearch: Yes, certainly. That's not framework issue.

  • MongoDB: Yes, there is adapter for it and this is the best choice for the moment.

  • Complex relations: Yes, not framework issue.

  • Realtime updates: Yes, with OT.

  • Security is an issue: Yes. From server perspective Derby is just Express. To secure all these realtime comunications, use some access-control module, ex: share-access

  • Performance and scalability: Yes, I do not have tests, but theoretically Derby should be more performant while scaling than Meteor. There is a kind of confirmation.

What about Meteor, I used it before Derby. It has good documentation, tutorials, support and marketing. It's good to bootstrap a small app in five minutes. It's good to understand concepts like: db on client, isomorphic code, realtime, etc. But it's quite monolithic and not flexible. It's way of implementing realtime is very simple, but it lacks of conflict resolution and have issues with performance. It can not be used for offline in any sensible way. Most of Derby-developers came from Meteor.

Try both and make a choice. Good luck!

I agreed with almost all answers from @David Weldon, just a few things you need to consider: Complex relations and scalability.

When you say complex relations between objects, I'm wondering if MongoDB is the RIGHT choice for you. Since all data is stored in documents, the less relations between the Collections the better.

On scalability, as said above, if you have a few rather "relational" collections (MANY-TO-MANY etc.), you could run into serious scalability problems in future (hard lesson learned).

If you really do, you should wait until Meteor officially supports other RDBMS.