Multi-tenant Web Application

Developing web applications, campaign websites, or whatsoever aren't often too complex tasks. But, after a while, all of these "small" applications together become unmanageable for small teams.

For this reason, I started looking for a stack that would make it easy to start and maintain these kinds of projects together on this scale. In this article, I won't dive too deep into the technologies used, but rather give you an impression of the stack.

Use cases

The use cases we've worked on, with this stack are;

• Server-side rendered static websites
• Web applications
• Reporting and dashboard tools The variety of use cases forces us to form a stack that is flexible enough to fulfill different scenarios.

Server-side rendered static websites

Eventually, in most cases, the ideal situation for this use case would be; to start directly on the designs and frontend components. Without having to worry about the backend architecture, the content management system, packaging manager, en so fort. Working on UI components and designing exclusive user interfaces would be the most important focus points in this use case.

Web applications

Applications require more backend work. Usually, you would have to create an API or mock it in the frontend. But, either way, determining data models will take time. And, also the way storing data will be a challenge. UI development won't be our foremost concern in this use case.

Reporting and dashboard tools

In contrast to static web sites and web applications, reporting and dashboard tools require both extensive backend and frontend workload. A configuration for such use case in this stack could be;

• Timeseries for IoT data, relational or non-relational database to fit the need. - Also an opportunity to use fully-managed cloud database solutions
• Serverless solutions like AWS Lambda or Node.js Express APIs
• Frontend frameworks with state management in combination with D3.js (data visualization library), or Grafana (open-source analytics tool)
• Also for these tools like D3.js and Grafana, the private NPM registry could be used

Layers

The stack consists of the following layers (accessible via);

• Database (db.local.io)
• APIs / CMS (api.local.io / cms.local.io)
• UI Components Library (ui-lib.local.io)
• Packaging Manager (npm.local.io)
• Frontend Framework (www.local.io)
• Hosting

Shared UI Component Development

Based on the framework we use, often React or Vue, we create the project codebase manually or with the default command-line interfaces. Next, we will develop our new components or extend existing ones based on the "Atomic Design" pattern. We can easily publish the package through npm-scripts. Now we can import the "package" in the frontend or use it in other projects.

The directory structure would look like this;

├── .storybook
├── dist
├── src
|   ├── components
|   |   ├── atoms
|   |   ├── molecules
|   |   ├── organisms
|   |   ├── templates
|   |   └── pages
|   ├── styles
|   └── tests
├── stories
|   ├── atoms
|   ├── molecules
|   ├── organisms
|   ├── templates
|   └── pages
└── typings

You could also use one of the available open-source UI component libraries, implement, extend and, reuse it in other projects.

Frontend

Concerning the frontend framework, there are no restrictions. Gatsby is the framework I usually prefer for simple static websites. For more complex web applications, I prefer NuxtJs or Next.js.

Benefits

The benefits with this stack are, mainly the flexibility of the boilerplate and reusability of the UI components. But, also specific mixins that keep returning in projects like function compositions, curry-, utility functions like debounce-, throttle-, and localization functions.
Composing this way assists us to avoid shared-states, mutable-data, and side-effects, and keeps our functions pure.

I hope this provided some insights about multi-tenant applications.

To have some indication about the need for a more in-depth article, please give feedback one way or another.