Multi-tenant app

Design
1

Hello, I’m in the early stages of planning a multi-tenant rails app, where each client would have a unique subdomain for managing the app. I’m thinking emberJS would be a good fit for the front-end. This might be a crazy question but, in planning out the architecture, would it be possible that a single emberJS app would serve up the front-end of the various tenants?

Come across any good guides or case studies to use EmberJS in this way?

Thanks, Rob

2

I don’t have direct experience with this, but I think that would be fine. Though I’m sure you’d need to adjust some configuration data for each (such as API keys). Perhaps that could be dynamically injected into your index file instead of an ember-cli thing. (I’m thinking you would build the ember app once and serve the same build for each subdomain using virtual folders or such…) I’m sure there are multiple ways to achieve this, but should be doable IMO. Ember / ember-cli isn’t tied to a specific domain that I’m aware of, just the folder from which it’s served.

3

Maybe a better question, what wouldn’t you want to architect into your EmberJS app? Is it possible this entire app can be designed without a backend like Rails?

4

This is exactly how our application works. Our backend is python, so I cannot speak to the rails side of things.

I’m not really sure what questions you have so I don’t know how I can be helpful. But a quick overview would be that all requests for both assets (JS,CSS,Images,etc) and AJAX requests are routed through the customer’s subdomain. As opposed to having a dedicated subdomain for AJAX requests. This makes life much easier with CORS and other security aspects, such as session cookies which can be tied to the specific subdomain. (This is particularly important if you expect some users to have access to multiple tenants).

Our DNS has wildcard routing into the production server (eg *.myapp.com). When a user launches their app (eg foo.myapp.com), the server looks up the specifics of their enterprise account (foo) and embeds those into the HTML that is served up. When the Ember app comes to life it looks on the window for this data and uses it to populate a Config service. Other parts of the app end up using the config service to get access to data specific to that tenant (page title, banner, custom branding, public API keys, etc).

If there are any other questions you have, I’d be happy to try to answer them.

1 Like
5

Thank you so much. It took a little while for all this to cook, but I understand it now. I’m wondering though, is it better for Ember to look at the window to determine the subdomain, or should you send that along with the data payload over the API?

6

You’re welcome! The data payload that’s embedded into the index.html has the subdomain. That just get’s stored in the config service and we use it that way. I don’t see any reason you couldn’t check the URL. Whatever is easiest.

2 Likes
7

I have the same requirement - multi-tenant EmberJS app being served from our customer’s subdomains and using Azure to host EmberJS and a JSON API using nodejs/express. We want to have each customer’s app rendered with a custom style sheet and a small package of customizable text (navbar title, login message, etc).

Could you give some more details on how this data payload is embedded into the index.html file?

8

Hi there!

Our app is using a multi-tenant architecture, which I can tell a little about. We use a single front-end with Ember to all our clients (although we do not have a tenant specific styling option).

Basically, what we’ve done is created a domain service that handles the subdomain, like this:

import Ember from 'ember';

const { Service, computed } = Ember;

export default Service.extend({
  domain: computed(function() {
    return location.hostname.split('.').shift();
  })
});

And configured the Ember Data ApplicationAdapter to use the current subdomain as the namespace of API requests.

So, when fetching members for the foo tenant, a request is made to http://api.example.org/foo/members.

Also, you have to remember to configure the DNS for your site with a wildcard entry and make sure your server software is properly configured to listen for subdomains.

2 Likes
9

I guess I’d embrace some of the benefits of a per subdomain deployment that pops in my mind:

  • Ember doesn’t need to know that it runs in a multi-tenant env, I guess that makes the Ember app simpler.
  • Customizing the front-end can be done at build time
  • And what I like most: You can do staged deployment for carefully rolling out new releases and in case you screwed up, do rollbacks for single tenants.
  • (What about scaling?)

Edit: I only refer to front-end, not back-end. I like the idea of the above reply for the api, but that doesn’t add to security.