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.
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?
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?
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:
Increased read/write throughput
Latency reduction from geographic locality
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).
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
Nice accounts system out of the box
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.
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.
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.
