Single Meteor Project for Multiple Apps


#1

Hi.
New to Meteor and to the forums.
Already had my few weeks with Meteor… and what can I say… so far - we’re in love :smiling_face_with_three_hearts:

I used the term a Single Meteor Project on purpose. Because I have googled first and also checked the most similar questions here in the forums but didn’t find the answer. Most questions I found are asking about sharing just the Meteor backend.
I think this question is pretty general and may benefit others as well.

Intro
Let’s assume I have a single Meteor project which has it’s various software layers laid, configured and well-tested (db, security, users, routing, etc.).
If I want to take advantage of the whole environment and basically create a new (lightweight) app by adding the following to the existing project:

  1. new user (few lines of code)
  2. the new app (basically it’s pages or visual components, could come down to 3-4 files)
  3. the relevant app data collections
  4. the app’s routing configuration (1 file)

Note that I mentioned the amount of code added to show how little it is.
Let me clarify that I’m talking about lightweight apps that have no more than a few users each and that will probably share at least 70% of the project’s code.

I have experience with Meteor+React and using Flow-Router for navigation, so technically I thought of loading the relevant app routing according to the user, which is a common case, but I want to expand this method to a whole different application space. Routing to pages that will access different data, etc. All of these lightweight apps can share the login page, let’s say.

Considering this direction 2 things that came to my mind were scalability & security. So I thought I’ll look for advice here with the experts.

The Questions (assuming it’s possible and not too complicated… :crossed_fingers:)

  1. How scalable is this approach?
  2. Is there an extra risk security-wise?

P.S. I’m assuming that it is possible to dynamically switch app-space according to the user even though I hadn’t done it yet, sorry if I’m missing something basic about Meteor.

Many thanks if you read this far and I’ll be happy if you share your thoughts.

Go Meteor! :rocket:


#2

I really like this question, I think it’s insightful and shows an economical mind in action.

But I’m biased, because we’ve exactly that architecture. I call it micro-apps architecture, as oppose to micro-services since we cover the full-stack per package, and it makes heavy use of Meteor’s isomorphic packaging system.

This architecture is not new, Eclipse (the popular Java IDE) has that architecture and it’s call plug-in based architecture, you can read more about it here. Of course the power of this architecture is in the re-use of the common foundational features, kind like re-usable rockets, when building a new app developers tend to start from a very low ground, but with this kind of architecture you’re up for a head start.

What can you pack in an “app” package?

1- App configuration files
2. Routes
3. Assets (CSS, images etc)
4. UI pages (React Components)
5. API methods
6. MongoDB Collections

So everything you need to create an app. What’s even more impressive, you can switch between apps at run-time and you can deploy several type of apps on a single deployment.

It’s feasible and easier done with Meteor then other framework (or pure NPM) because of how Meteor does isomorphic packaging. With regards to implementation, your starting point is VulcanJS. VulcanJS is step before this architecture since it focuses on capabilities (forms etc.) but not a full app but it does have hints on how to create such an architecture.

To sum up, yes it’s feasible and we’ve it in production with 10 apps and counting. :rocket:


#3

So happy to hear that @alawi :gift:
Thank you very much for explaining and for the references.
I will definitely look into them to better understand this architecture and see how I continue.
:pray::rocket:


#4

Best of luck, if you decide to pursue this architecture and you get stuck at any step down the road, let me know, I’d be glad to help.


#5

In Microservice Architectures there is the term of the Gateway Application which is used as kind of facade to the landscape of services. Martin Fowler is good to read on Microservices.

Regarding the recent posts: Our approach is similar to what @alawi described except, that we have the services as Meteor standalone apps and share the “interfaces definitions” in terms of const Objects via Packages.

The good thing is that Meteor will be flexible enough for you to find the way that will suit your needs.

P.s. you can also share diagrams and sketches as images/vector graphics here, which is a benefit for all. I see too often long texts in forums about architecture but very few images or sketches.


#6

We’ve been doing this for a few years with Meteor now. A mono-repo containing the all the separate apps and packages with all the shared code. The packages of shared code sit outside the app directories and are sym-linked into the /packages directory of each app.

Then, on the server, we start several instances of each different app. We go at the ratio of a couple of instances per core, but our apps are heavy data users with lots of per-user subscriptions, so you can probably get away with more app instances per core if they’re lighter apps.

I’ve been really happy with the development and deployment experience using this set-up and won’t be changing anytime soon.

Good to hear you’re loving Meteor. Six years of using Meteor and I still can’t think of using anything else without a shudder.