Multiple “apps” with ember-cli

Question

I\'m trying to migrate to ember-cli from some old homegrown build tools. Our app is quite large and is actually split into several ember.js single page apps (e.g. index, adm

Answer 1

If you must accomplish multiple apps with Ember CLI, per your 2015/1/28 edit, you'll want to wait for more pod support, or engines.

Consider however the naive DIY solution here: make your n separate Ember apps into n separate Ember CLI apps. Serve them yourself in a single superproject.

Disadvantages

As with your investigation into addons, you will have repeated boilerplate, package.json, environment.js, etc. You will incur the overhead of maintaining each app's Ember, Ember CLI, etc. versions separately. You will have to create a way yourself to serve them all in a superproject. Even if multiple apps are on the same library version, clients will likely have to download duplicate vendor.js code.

These are strong disadvantages you'll have to weigh.

Advantages

1. You keep your current code organization.

2. You must be disciplined about the code you extract for sharing.

   "Duplication is far cheaper than the wrong abstraction." In the world of dynamic JavaScript, where anything goes in the type system, and everybody has a different module implementation, abstracting/extracting too early gets you into trouble. When shared code is carefully extracted into a separate library—perhaps using the Rule of 3—it results in a higher quality microlib. The lib's maintenance can be focused on optimizing just the shared functionality, and its backwards-compatibility. You might not get that if the shared code remains in your app, employed via import spaghetti.

   As with frzng's answer, "include shared code via Bower, NPM," and Ember addons.

3. The tech debt of one app doesn't corrupt another app.

   This is good particularly in the Ember ecosystem. Even though its motto is "stability without stagnation," new Ember patterns come out every day. Want to try one of those bleeding edge Ember techniques, but don't want to spend time upgrading your entire Ember monolith? Upgrade just one smaller app instead!

   I've worked with a massive Ember app whose tech debt in small areas prohibited upgrading the entire app. With this scheme, don't need to say no anymore.

   (Halting the spread of tech debt is part of why microservices are so popular lately. Many small Ember apps could be called a microservices approach.)

The Superproject

Organizing

You can explore Git submodules (*shudder*) subtrees or NPM artifacts. You'll jump through hoops to keep them all in sync.

In my situation, it doesn't make sense to run 1 app without the others. I've had success with a monorepo.

Serving

My URL scheme worked for the Unix philosophy-like separation of my Ember apps. Each could be served by a single server, but each grouped under a logically separate context path. For example, all requests to /app1/* get routed to app #1's compiled index.html. All requests to /app2/* get routed to app #2's compiled index.html. And so on. Ember takes over routing from there.

You might be able to do the same with /index/*, /admin/*, and /reports/*.

To mount these apps to their various public URLs, add some metadata in each's package.json to tell the server how. On startup, the server loops through the metadatas, and dynamically generates web framework routes.

for packageJson in packageJsons:
    path = packageJson.contextPath                               # e.g. '/app1/*'
    indexHtml = packageJson.abspath.dirname + '/dist/index.html' # Ember CLI's conventional location

    # Dynamically mount the route.
    # Normally you'd hardcode your routes, something like  
    #     yourWebFramework.GET('/hello', echo('Hello world'))
    yourWebFramework.GET(path + '/*', serveStaticFile(indexHtml))