Advanced routing and nested route vs service

In my app I have the following user hierarchy organisation (org) > reseller > customer. From a business perspective all three user types in the hierarchy are a customer with a :customer_id. From an app perspective they are seperate concerns, with the ability to impersonate users down the hierarchy.

So their base URL would all be the equivalent of:


But An organisation could route into a reseller as:


And both organisation and resellers could route into customers as:

localhost/org/:customer_id/reseller/:customer_id/customer/:customer_id or localhost/reseller/:customer_id/customer/:customer_id

Problems with this structure

The main issue is that every customer has it’s own site and service route. And I want to avoid repeating routes under the top level :customer_id. Essentially ending up with the following. {
  this.route('org', { path: 'org/:customer_id' }, function() {
    this.route('reseller', { path: 'reseller/:customer_id' }, function() {
      this.route('customer', { path: 'customer/:customer_id' }, function() {

But I’m unsure how to split the routes so that they inherit the correct URL structure but aren’t nested. And in a way where each customer can access/impersonate at the correct level.

###As an aside

If I can’t figure out how to execute this I’m planning on using a user-service to set a currentUser variable for impersonation, and then stripping the URL to localhost/org/:org_id/ for every customer. But this won’t reflect the level of impersonation in the URL.

  1. Is :customer_id referring to same entity type (e.g. customer) or is it different at different levels?
  2. I normally follow / mimic REST API Resource hierarchy (resource / sub-resource / …) for ember routes. With this context, How is your resource hierarchy laid out?

Good questions:

  1. Every org in the db has a :customer_id, but they may be either direct (a customer), a reseller or a parent organisation (org). Both orgs and resellers can impersonate the customers they own. So currently they are all the same, and a service runs a currentUser function to tell Ember which <org_code> param is current, depending on the level of access the org has. This allows them to impersonate the user.

  2. We’re building the api in Python in tandem with the Ember SPA. We started with /api/v1/org/<org_code>/ as the base, so every customer has:




With this sprint there’s some time to refactor, so I’m looking at ways where we can structure the URL pattern to reflect user impersonation a bit better.

You may want to use ember-route-alias add-on for your case.

This would help you to use different urls for a given route, and you can achieve your URL hierarchy without nesting the route definitions.

1 Like

This looks like it’ll do the job. Thanks for the recommendation @Elisha.Ebenezer