I’m developing a consumer and merchant management app with two extremely different views. They both though need to share the same database. I’m building both the apps using ionic+cordova so can I use a single meteor backend for both. I’m a newbie so I was planning on creating two different roles but is this approach correct. I mean for vastly different views a bunch of (IsinRole.customer or IsinRole.merchant may lead to an ugly code?)
Could someone please help me, in how should I plan it?
PS: Any existing open source usage of multiple roles and views would be appreciated.
1 Like
Is there a problem with you just using a separate layout if the user is management?
I also thought the same but I don’t want the merchant account to ever login on the customer app. Can I stop this using the roles?
@gutsyninja Can you post an update ? I too need to keep two distinct app views (normal -vs- admin) where both share same database yet different CSS structure , desire to avoid bloat of sending admin code down to normal enduser etc … thanks
1 Like
Hi guys, I actually just designed two apps that do this.
Theoretically, you can write a single app and create a bunch of conditional checks like:
if (user.isLoggedInAsAdmin){
//something
}
but this will vastly increase the complexity of your code. I suggest having two different apps:
cd /path/to/customerApp && meteor create customerApp
cd /path/to/adminApp && meteor create adminApp
Basically, you can write two apps which connect to the same database. All you need to do is set the MONGO_URL and MONGO_OPLOG_URL to the same value. These can be set in your environment.
Both apps are standalone and contain two completely different clients.
2 Likes
I’ve done the same - connecting two apps to the same database has definitely been less complex in the long run and cleanly separates concerns for different users. i.e both apps won’t need to share ALL code and packages with each other.
To avoid repeating shared pubs/methods, you can also use DDP.connect to call methods across both apps, given you are communicating on a secure https connection. It’s worked well for us so far, but by guess is you would probably (?) need to take request/rate limiting into consideration at serious scale.
EDIT: the guide actually recommends rate limiting your methods as a general preventative measure
1 Like