I read different post around here and still I’m pretty confused about how optimize Meteor Apps for large scale applications with lots of concurrent users.
In my case, I’d like to build a SaaS that can reach potentially a large base of users.
The biggest pain of Meteor is CPU usage and this could be really cost expensive.
Can you help me understand (maybe with a bullet list) how can I start building an application that is optimised for my specific case?
Move as much processing on the client (e.g. sorting, filtering, mapping) = spread of computing cost. Use web workers.
Use elastic computing for servers (cost effective)
Use Lambda/serverless functions or microservice servers for longer tasks (image processing, analytics calculations).
Do large reads for things like data dumps for analytics or exhaustive searches on secondaries of your Mongo clusters or on separate DB.
As much caching as possible on the client with sessions persistence or browser persistence.
One set of servers for one function and integrate via iframes or something else. (e.g. don’t do chat and general app in the same Meteor App. They have specific data consumption patterns).
Make use of Node Events (as opposed to reactivity). (e.g. Let someone who is online know that you are also online with Events instead of writing states to DB, extrapolate the concept to wherever Events can replace publications.)
“Can you help me understand (maybe with a bullet list) how can I start building an application that is optimised for my specific case?” - Your case is not too specific.
If you have in SaaS something like an accounting system / CRM these are softwares with large sporadic reads (get a lot of data upfront). Save back updates which are mostly forms-like.
You may have 1 million users connected with less that 1000 DB transactions per second average.
In a forum/chat you would have the opposite … 1000 users with at least 1000 DB transactions per second. Stock dashboards and games … a completely different beast.
Number of concurent users is not very revealing in terms of server load. The actual code may tell a clearer picture.
The better question are for me:
is Meteor (NodeJS) a high output web server. Yes, it is.
is it maintained. Yes
is Javascript maintainable now and in the future? Yes, very much so.
will I find workforce? I’d go React for frontend and for server side … you pretty much need a javascript developer, not a lot more.
Except point 2 which is Meteor specific, everything else is just NodeJs. However, as some work now on brining change streams to Meteor, this answer will probably change or you can at any time use a mix of reactivity and methods.
