Is Meteor is the right solution for me?

I am working on SPA web app that will allow drawing on screen canvas. The frontend is already done in JS.

There will be 1k to 10k registered users, concurrent from 0.3k to 3k.

No big database searches, just some internal on-server computation (loops, arrays etc.) with no extensive use of DB. As well no need to use realtime communication for now (even simple AJAX calls could be enough). Each user a simple call every 10 s, maybe a more demanding one each 10 min. Additionally I need a payment module, sending e-mails, that’s it.

I am worried about scalability and performance, as I read a little bit about this issue. I’ve read that Mongo DB sharding is difficult on Meteor.

I like the idea to have interchangable code between frontend and backend though and simplicity of Meteor.

I am considering also Laravel.

Sharding per se is no more difficult on Meteor than any other NodeJS framework. What’s difficult is using a sharded database with Meteor’s livedata (automatic syncing of client/server). However, at the expense of forgoing out-of-band operations, it’s possible to circumvent Meteor’s traditional implementation of livedata by using Redis oplog.

Is there any particular reason for using a sharded database?

1 Like


Wouldn’t I need sharding with 3k of concurrent users worldwide?

This is where you may run into performance issues - again, not a Meteor issue, but a more general NodeJS one. If you have only one server instance, then NodeJS has to service all requests on a single thread. If you have any heavy compute-bound operations, you’ll block the thread for other users. If these are straightforward JavaScript operations (no database I/O, for example), can you also run those on the client?

Yes, technically they could be run on the client. But the thing is, they have to be on server, because they are “prioprietary”:slight_smile:

I would go for create-react-app (with apollo-client) as your frontend and then a node.js server running apollo-server (graphql). Use mongoDB.

Emails you can just use nodemailer. Accounts you can checkout AccountsJS. Payments I would use stripe.

The hitting the api ever 10s is a lot of polling. Usually anything more than 30s is a lot but you could maybe pull it off.

Could you confirm, do I understand what you wrote to me correctly?

“If you do not need the features that the Meteor was build for and on, namely DDT and reactivity, that both take a lot of server power, then just give up meteor and switch to the vanilla node.js to gain performance”.

Sharding the database doesn’t directly impact the performance of the node.js server Meteor runs on. In general, you shard a database to handle very specific situations, typically one of:

  1. Increased read/write throughput
  2. Latency reduction from geographic locality
  3. compliance/security through segregating data.

If you don’t need one of these, you probably don’t want to go down the sharding road - there are a few “gotchas” that have nothing to do with Meteor.

with 3000 users online you’d need multiple servers (you’d probably want multiple servers for anything > 100 users, for reliability).

  1. Latency reduction from geographic locality
  2. compliance/security through segregating data.

(you’d probably want multiple servers for anything > 100 users, for reliability).

These are true for me.

Assuming you’ve already measured the latency from client’s in one geographic region to a server in another, and found it unacceptable (we have client’s in Europe using an app server/db on the west coast of the US with acceptable latency, and thus don’t require sharding) then it seems you do need sharding - but just to clarify, for both of these points you’d also need app servers running in the relevant geographic regions otherwise you’ll make things slower, not faster.

If you’re only making calls every 10 seconds, are you sure you need latency compensation? Instead of making the call every 10 seconds, make it every 9 and the result to the end user would appear the same.

Yes this is it. I think the biggest help from meteor are

  1. Nice accounts system out of the box
  2. Subscriptions are pretty easy.

If you don’t need subscriptions and can handle finding another auth system, then I would consider using something else.

The other consideration is if you’re comfortable with meteor. If you’re familiar with meteor inside and out, maybe it’s better to use it and move fast rather than have to learn new technologies. It sounds like you haven’t used meteor so maybe there’s no gain in that respect.

At the end of the day, the latest version of meteor is pretty close to a vanilla node.js application.

Got it.
No, no any experience in any of the Node.js frameworks.

How about this framework:

I’ve heard it’s the most complete framework for node.js there is.
Has inbuilt Auth, GraphQL, caching etc. It has it all out of the box. I’d need just to add a mailing library.

I’ve never tried it. There’s also next.js.

I just use vanilla node.js it’s pretty simple and I’m not locked into any one way of doing things.

Since you already have the frondend and don’t need any concurrency, it seems like you don’t need meteor at all. I think you should probably go with AWS lambda or the like coupled with a serverless DB and go completely with a serverless solution. That would save you the architecture and scalability headache with an infinitly scalable pay as you go model.
This should be the easiest and most efficient but not necessarily the cheapest.