Is Meteorjs good for making social network website?

1

Hi,

I read an article that says mongodb isn’t optimal for making social networking websites. However, I am currently using meteor to make a social networking website. Since meteor uses mongodb would this be a drawback for choosing it?

2

  1. Keep in mind that minimongo acts as a client-side replica set, and livedata and minimongo together implement a cache invalidation architecture. Fundamentally different database topology, and therefore different system architecture.

  2. The team in that article didn’t have matb33:collection-hooks to implement cascading master-detail updates.

  3. The author of the article admits they had a communication problem with their client regarding expectations of what they want to do with their data.

Probably the best comment in that article is the one by AverageJoe regarding the team (and clients) still being in a relational mindset, and the assumption that social data necessarily needs to be consistent.

As for using Meteor to build social networking sites, there’s a half-dozen of us in the healthcare group that are working on social health-record applications; but we know that our industry has been using document oriented databases for 40+ years, and that our clients can handle waiting 5 or 10 or 30 minutes for things like name changes to propagate through the system. We know our healthcare data is fundamentally unstructured and document-oriented. Which gets back to the point about knowing your industry, your clients, how they want to use that data, and what their goals are.

Anyhow, if you decide to continue moving forward with your social network app:

  • don’t use any joins in your publications.
  • whenever you add a userName field, be sure to include a userId field; and vice-versa.
  • use matb33:collection-hooks to implement master-detail relations and cascading updates of duplicated data
  • soclalize:friendships implements a basic social network pattern
1 Like
3

You might want to check out this response ( which was how I first heard of that article )… http://ayende.com/blog/164483/re-why-you-should-never-use-mongodb it gives you a perspective of how to design what they were trying to do from a nosql perspective.

1 Like
4

@awatson1978 Would you please explain, or point to posts/articles, the rationale for not using for not using joins in publications? Is there something fundamentally wrong/broken with implementing joins vs denormalizing data? I am guessing the second bullet point follows from the first, i.e. it is better to denormalize by inserting userid and username than to find one or the other in a separate collection?
I am still new to meteor and am learning about developing best practices when creating my apps.

Thanks,

Kamal

5

Node is benchmarked to max out around ~40,000 operations per CPU. Meteor introduces various overhead with regard to tcp/ip, session management, ddp pub/subs, etc which brings that ceiling down to something like ~5,000 concurrent sessions per CPU. Every join that’s added to a publication requires an extra database lookup, which means disk IO, which blocks for ~50ms to ~200ms or so.

If you’re lucky, the performance will only halve the throughput; so the first join will drop you down to ~2,500 concurrent sessions; the second join (in the same publication) will drop you down to ~1,000 concurrent sessions; three joins you’ll be down to ~500 concurrent sessions, etc. Of course, as you’re just starting out, those performance hits won’t be visible, if you’re only working with a couple of users. They only become apparent when you start scaling up.

The pub/subs basically come about as optimized and as fast as they’re ever going to be the day you write your helloworld. After that, it’s death by a thousand cuts. The trick is to just get out of their way. Keep them as light-weight as possible. The simpler the logic in your publications, the more your application will scale.

And, yes, storing the username along with the userid allows you to not need to do a lookup whenever you just want to show the list of folks who liked an article, or posted something, etc; while, conversely, the userid allows you to do exactly that, and lookup the user when you need to go to another person’s wall, or look at their photo album, or whatever. Looking at your news feed, another person’s wall, and another person’s albums… three different data access patterns… and data access is what Mongo is optimized for.

4 Likes
6

Hello ! My name is Greg and i’m the CEO of Peuplade.fr which is a french social network for neighboors. We we work with my Lead dev on our mobile app and my question is : Does Meteor is a good framework to build a very good mobile app ? Is anybody build a quite big social network with Meteor before ? @markqian did you do you your site ? @awatson1978 what is the Meteor Clinical ? Thank you ! Greg