Architect: Recipe for a Multitenant application

Serving several clients with in the same application represents an architectual challenge. Let’s set up a recipe to follow for deploying a classic CRUD application pattern.

Step 1: What does the master application look like to the outside world?

For this we need to consider why a multitenant application in the first place. We want to be able to service many clients from a single codebase, database and application server. Best Practices and the ability to scale rapidly on an as needed bases we will use database schemas for secure access to client data with load balancing on the fly provided by the cloud services. All this securely behind a firewall in the cloud.

Step 2: How do I get to a client application?

We need a mechanism to find out which schema to use in the database and which look and feel and controller logic to apply for the user experience. How do we know which client (tenant) this user belongs to in our multitenant scheme? We can establish a mapping for schema name to the unique client portion of the url. By request we will establish the session based on this client (tenant) info parsed from the request url.

Step 3: Application routes: what functionality (routes) are exposed to the outside world?

Now we know how to get to our client application, how is the needed functionality exposed to the outside world? Routes define how we access a certain need (how to get to a person) and how that maps to whats inside that does the heavy lifting - the controller.

Step 4: Workflow for seeing and Object’s details

Ok now we know what routes are for, can we see one in action? For seeing a Person’s details we want to fire the show controller via a route with Person with id=6. The url for this route is http://myclientapplication/person/6