Architecting an App with Admin and Multiple Instances


#1

I own a car dealership, and I built our entire front on a LAMP stack. After wandering the Node/PM2/React/Redux/Webpack/Express forrest for a year, I’ve come to Meteor for version 2.0.

Two questions, and I greatly appreciate the input from a 100,000 ft perspective. (I’m trying to avoid the sin of premature optimization, but if there are architecting decisions that I can make now to avoid extreme pain later, I’d like to know)

#Why do I make the Admin and Front End two apps?

The Meteor docs say to make two apps and connect it to the same database. That works. But I’m curious why I should do that. What’s the pitfall behind an /admin route? And I assume Galaxy then gets me for two apps, right?

#How do I spin up multiple instances?

My goal is to beta test this software with my own dealership and then license the software. At base, the sites will have different databases (obviously) and all other differences should fit into a settings config file. (Obviously I’ll need to make custom UI for customers, but we’ll cross that bridge later)

My research shows Docker containers are the answer. But I’m confused how you move from version control to a Docker container to deployment across multiple instances of an app. Any links are greatly appreciated!


#2

Currently, in stock meteor, everything gets loaded and downloaded to the user. Meaning non-admin users will also download unnecessary admin page data.

There are ways to workaround this (webpack to do code splitting). If you do not want the added complexity, you might want to split your apps there as you mentioned.