Advice on creating a multi-tenant SAAS App with MEAN Stack (Mongodb, express, angular, node)

I am trying to wrap my head around developing an SAAS application with MEAN stack rather than PHP and MySQL. I need advice on a good way to create a multi-tenant application with mongodb. I know from previous reading that I don't want to do one database per customer because of the large size of a single mongo database, so I will most likely stick with a single database.

I am thinking that creating the database similar to a mysql database in structure with a "customer_id" value in each collection would be the best idea, but that brings me to my primary question...

If I create a REST API for this application, how would users access their information. Would I log them in and then based on their client id, access the api that way, like:

api.myapplication.com/CLIENTID/projects

Any advice on this is appreciated.

======

I want to expand on my use case scenario, because while the first answer was very good, I'd like some additional advice. I'll be creating a system where a user signs up for our app and keeps a bunch of internal records. I don't want to give away too many details so lets say this users company signs up and then he can add "team members". His team members all have individual logins that relate back to his main company. This company has several resources. Lets say estimates and invoices (like freshbooks).

I'm thinking about starting this project off with each company assiged a unique ID. That ID becomes a mongo collection. Inside that single collection are ALL of that companies Estimates, invoices, Team Members and a document with all their stripe api information (for my use in billing them).

======

I have read both pros and cons of building out the database with a single collection per user and I think based on what i've read, that it is preferable to a single database per user scenario, which would be my second choice.

Any more comments / feedback based on this expansion of my original question is appreciated.

-------------Problems Reply------------

This is a fairly high level question with a lot of areas that could be expanded here, which makes it a bit difficult to answer. Also designing something like this without a lot of information on how it will be used or consumed also makes any answer quite vague. So sorry up front for all the hand-waving I'll be doing :)

In general there's a lot of people who would argue against using the NoSQL databases in the same way you would with SQL databases. But it's completely understandable that you might want to play around in these NoSQL databases to see what it's all about, and better understand what's good and bad with them. Mongo is a popular one, and there's a lot of good that comes with it, but know that referencing data across multiple collections is a bit different. In general though, a common use is to have a collection per resource (which tends to fit in with REST).

Moving along to the REST question, here again there's a lot to say on the topic. Certainly if you're unfamiliar with the concept, there's tons to read on it. Most REST APIs are built around a resource, so instead of what you had suggested, it would be more like:

api.myapplication.com/projects
api.myapplication.com/movies
api.myapplication.com/cars
..etc

But in general, yes, the user first authenticates themselves and then attempts to access the individual information from those REST APIs for each resource. But as you begin to build these apps out, more and more APIs mean more and more request/response cycles, which can lead to lag on the client side. So recently people have moved away from SOA to more client-specific APIs which bundle multiple resources into a single request (or rather they build these APIs on top of a SOA layer). These APIs are fine-tuned to a specific client app, and thus reduce the overhead of the multiple requests.

Hope that helps you get started...

Category:javascript Views:4 Time:2014-05-26

Related post

Copyright (C) dskims.com, All Rights Reserved.

processed in 0.080 (s). 11 q(s)