10

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!

Ole Spaarmann
  • 15,845
  • 27
  • 98
  • 160

3 Answers3

20

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 and flow-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.

David Weldon
  • 63,632
  • 11
  • 148
  • 146
  • thanks for answering this question David, this is a very good and thought out answer. At first I thought this question is loaded. – imslavko Sep 30 '14 at 00:21
  • Thanks for your answer. Some party of my question were badly phrased. For the rest: I still read in many articles that Meteor and security is a very big issue and that it is nowhere near production ready (I mean they haven't reached v 1.0) yet. A collection of youtube videos where the founders of Meteor praise their system doesn't really assure me. About SEO: Launching an entire web browser on your server, render the page, then pass that to the search engine is extremely inefficient and makes you prone to a DDOS attack. https://andrewmunsell.com/blog/the-odd-state-of-nodejs-and-its-frameworks – Ole Spaarmann Sep 30 '14 at 13:11
  • 1
    A few things: (1) I wouldn't have recommended meteor in 2012 when that article was written, but **a lot** has changed since then. (2) I added a link that gives a security overview from the Discover Meteor blog. (3) You concern about SEO may be real, as the current solution is a bit of a hack - something better is on [the roadmap](https://trello.com/b/hjBDflxp/meteor-roadmap) for post-1.0. – David Weldon Sep 30 '14 at 16:53
  • The more I read about it the more I get the impression that Meteor just isn't ready yet. I think it is very, very nice for prototyping and for realising ideas quickly. But I don't want to build a more complex on top of so many problems and hacks. That might (and hopefully will) change and I like the approach. But many things don't make any sense to me and seem to address people who want to code as little as possible. Which isn't the case with me. I want as much control as possible and am willing to do a bit more work for that. And it is not exactly building your own browser either :) – Ole Spaarmann Oct 01 '14 at 19:29
  • Haha, yeah my browser comment was a bit hyperbolic. I think of the tools we choose as being somewhere on a spectrum from very low-level (left) to very high-level (right). Meteor is certainly right of center, but not as far right as something like rails. Getting your hands dirty and having more control is a perfectly legitimate choice. :) – David Weldon Oct 01 '14 at 19:46
  • just want to give a hint to use `prerenderer.io` instead of `spiderable` for SEO nowadays – Dude Jul 26 '16 at 09:23
15

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!

Vladimir Makhaev
  • 1,104
  • 2
  • 10
  • 23
  • Re. the confirmation on performance and scalability: it's unclear if Christian Steward was using MongoDB oplog tailing back then. I've [asked for a follow-up](https://groups.google.com/d/msg/derbyjs/lfwziMXnaM4/jMcr-5k6hLUJ). Without oplog tailing, subscriptions can indeed be very slow. – Dan Dascalescu Mar 21 '15 at 01:48
  • After some googling, I still haven't figured out what LWW-strategy means – Loupax Jun 03 '15 at 09:56
  • 1
    LWW - means Last Writer Wins. If, for example, some users been offline and made changes to same data and then come online. The last, who come online will rewrite changes of other users, though actually his changes can be made early in time, compared to other users. In LWW there is no data versions or something that can solve this issue. – Vladimir Makhaev Jul 11 '15 at 07:48
3

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.

Anzel
  • 19,825
  • 5
  • 51
  • 52
  • Thanks. I thought about that as well. I have a lot of many-to-many relationships, sometimes even with a join model which contains data about the relationship. I had a look at Sails.js and it supports a lot of database systems, also MySQL (which might be a better choice for this system). It even supports joins across different databases (but I don't know how well this feature performs). Since it is based on Express and Socket.io all the realtime features can be used as well, and you have a nice MVC structure. My data is very document-like, that's why I thought about using MongoDB. – Ole Spaarmann Oct 01 '14 at 16:06
  • I guess you have to take into account what's the expected traffic you will get. If you want to roll your project out at soonest and take all advantage of reactive data, Meteor is indeed a very good choice. And you only need to worry about scaling if your app is very popular (which is good). – Anzel Oct 01 '14 at 16:49
  • 1
    Well, I always consider scalability. I don't want to be in the situation having to rebuild the whole thing when it receives a lot of hits because I made a poor choice out of laziness in the beginning. And if it has to scale, it usually has to scale fast (and not after a couple of weeks rewriting the whole thing). – Ole Spaarmann Oct 01 '14 at 19:26