Single Meteor Project for Multiple Apps

[asafratzon]

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

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… )

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!

[alawi]

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.

[asafratzon]

So happy to hear that @alawi
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.

[alawi]

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.

[jkuester]

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.

[babrahams]

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.

[asafratzon]

Hi again guys!

2.5 months later I want to share my initial solution .

To keep things simple I will share 2 things - directories structure and the TODOs when adding a new app to the platform. I think these 2 give away the general idea of my implementation.

Directory Structure

imports:

• infra: public routes, data, security and general utilities.
• startup: startup code of server and client.
• ui: all shared UI components.
• apps: the root directory of all hosted apps. see an example below.

example_app_directory:

• index.js: contains the routing and definition of the app’s routes.
• config: app definitions and startup code (accounts, api and data initialization).
• data: data collections and schemas.
• ui: any custom app UI.

TODOs for New App
This is actually taken from my documentation.

1. Duplicate /imports/apps/demo_app and rename folder name to new_app.

2. Rename APP_NAME’s value in /imports/apps/new_app/config/names.js.

3. Rename account names so it won’t conflict with the demo_app’s account names (/imports/apps/new_app/config/accounts.js).

4. In startup/client, add:
   import "/imports/apps/new_app";
   in startup/server, add:
   import "/imports/apps/new_app/config/accounts";
import "/imports/apps/new_app/config/api";

5. Run the app :-).

Your thoughts?
It would be interesting to hear your feedback about my approach.
Currently to add/remove an app from a server instance all I need to do is to remove 3 lines of import statements. I didn’t want to complicate things so I’m not using any packaging mechanism at the moment. I would like to know what you think about that. Should I use one? if so, I would appreciate any guidance to a simple solution.
Any feedback is more than welcome

[drone1]

A bit late to the party here, but I wanted to ask if anyone has found an elegant way to manage meteor packages, where you’ve got multiple apps in a single directory.

I’m in a situation where I’ve got multiple smaller apps all being developed & deployed out the of the same folder, controlled by a high-level script and JSON files for settings and so forth. This has worked out nicely so far for sharing code in a single repo.

What I don’t have at the moment is a way to control which apps require which meteor packages. Since they’re all sharing a single .meteor directory, I could do this by having my high-level script do something like write -meteor-packages to .meteor/packages, yes, but I’d like to avoid this kind of thing if possible.

Anyone have any ideas?

I noticed “meteor run” has something called --extra-packages which allows you to add packages just for running your dev server, but for “deploy” this is not an option. Otherwise this would have been another option to consider.

Thanks a lot!

[alawi]

I’ve the same setup and I manage it via Jenkins build script. Basically, the script only clone the needed packages when a specific job is triggered. It will add the specific packages based on the job using Meteor Add xx and then deploy.

I know you didn’t want approach, but just sharing what I use.

Cheers

[tomsp]

Sounds like the perfect use case for a small cmd line tool or better yet a npm package so that you can do meteor npx new-app or something and it does steps 1.-4. for you.