3 Meteor Apps sharing one database

help
1

I have one meteor app for the dashboard. Writes and Reads form DB.
I have one meteor app for showing data. No writes to DB. Subscribes to 3 collections only.
I have one meteor app for showing data. Subscribes to one Collection only.

I did that mainly because of loading time. I do not want to slow down things for users who never use a dashboard.

I’ve read some terrible things about multiple meteor instances and mongodb ram needs for every connection. In general I just wanted to know If this architecture is a bad thing, and If I should rethink the archtitecture.

Thank you guys!

1 Like
2

Do you have any evidence that the user experience is negatively impacted by having all three functionalities in a single app?

The Meteor ecosystem has evolved tremendously over the past three years. It is now possible to implement code splitting, which would appear to address the issue that concerns you.

There are a huge number of factors that affect performance; loading time being only one of them. Often times, the real performance bottleneck is not where you predicted it to be.

I recommend that you implement a preliminary version of your app, instrument it, and do performance testing with realistic loads. Then you can make decisions based on evidence regarding your specific circumstances.

Good luck!

3

Then you are in the best position to know: did you improve loading time? Or were you perhaps solving something that wasn’t a real problem to begin with? If startup time is of utmost importance maybe Meteor isn’t the best framework for your use case. That being said there are packages to improve load time like FastRender and code splitting can be used to split code into on-demand loaded chunks.

It’s meaningless to ask if this architecture is good or not based on your description of some data access patterns. What’s important when thinking about software architecture is the business domain. Are the applications separate based on business-services? Does the business have strong conceptual integrity to begin with? Does the software architecture reflect the service boundaries of the organization?

1 Like
4

BTW, if you’re interested in an example of how to figure out performance problems on initial load, here’s a great one:

https://forums.meteor.com/t/solved-poor-galaxy-meteor-performance-serving-small-bursts-of-users-load-test/

The whole thread is a really interesting read to see how the OP gradually diagnosed the problem and solution and supported it with data.

1 Like
5

OMG. That sounds not good to me. I do not want to start a commercial service, when 100, 200 or 500 users are a problem. :frowning:

6

btw Asana is used by tens of thousands of teams, and it has a very slow startup time. In fact Geoff Schmidt, a founding Meteor core developer was Asana employee #9 before he left and started Meteor based on principles of Asana’s Luna framework

Principle: sometimes a slow initial startup is tolerated if it enables a much more responsive app experience once loading is complete. Think about how this is true for apps on your smartphone.

1 Like