Engines vs PODs vs monolith - Need a suggestion for splitting up may app

Design
1

Hey!

First of all I’m searching for a good advice. Maybe a discussion will be started. I know that there is no “best” solution but I need to hear different opinions to make a decision. Now to my “problem”

I have a fairly large existing ember app and we want to implement a big feature into it. Specifically the feature is a product catalog with many pages, views, features etc. I’m not sure how to setup this project. I’m thinking of choosing one of the following options:

  1. Monolithic approach, just adding the source to the existing project Of course I could just drop in all the files into the existing project but then I would end up creating components with prefix names etc. For example instead of creating an items-list component I would have to name it catalog-items-list because this component already exists.

  2. Ember Engine Creating an engine would be an option. Maybe this would be a future proofed solution because an engine could be lazy loaded in the near future and there is a lot of work going on concerning engines. Also we could easily deploy the catalog as a “standalone” app.

  3. PODs I’m not familiar with pods and I’m not sure if they really fit my needs. In the Ember-CLI docs they are explaining it that there is one folder for every entity. Which would cause a lot of folders in my case. The example of the CLI is the following

    app/users/controller.js app/users/route.js app/users/template.hbs

I think approach 1 has the benefit that I only have to maintain one code base. Which makes it easier to upgrade dependencies etc. Also I only need to setup one build-workflow (eslint, sass etc). There would be no duplicated dependencies (only one ember.js, ember-data, bootstrap.css etc) but it won’t scale very well and I’ll end up browsing through many files and use long filenames.

The approach 2 is attracting me because it feels fresh and clean. But if I create an in-repo-engine it does not seem to be part of the build-workflow. I don’t get livereload and all the stuff I setup in the “main” project. Creating an external engine has the same drawbacks and if I set it up as an own ember app I additionally have to maintain all the dependencies. Also I’m not sure on how to build this with an external engine. Would this cause all the libs to be duplicated?

About approach 3: I’m not quite sure how to adopt PODs to my needs. Maybe they would fit great because they are part of the build-workflow of the “main” project and the source would be separated.

What do you think? Do you have any tips, any links any best practices? Thanks

2

why not use and consume it as addon? if i remember right addons also can live inside mainapp to cluster larger parts into a package… and you get a nice abstraction and maintainable code parts on top…

3

I believe pods are being deprecated in favor of a new folder structure. I remember hearing this on an episode of the Ember Land podcast, so if that is the case, probably don’t go that route. I was in a similar situation and I went with approach #1 since Ember Engines wasn’t even out at the time. If I were doing it now, now that Ember Engines is partially out, it might be worth a shot. Maybe try it on a toy project first to see how it works, and if it doesn’t fit your needs, go with approach #1.

4

What is the new folder structure ? I currently see a list of folders based on file types like controllers, templates, routes etc. in ember 2.7 (latest). Is this changing soon ? I like the concept of pods as this is what I use with Angular as well. Any other approach which is being thought of ?

5

You’d have to listen to the podcast to get an idea of the proposed new folder structure which isn’t out yet. Who knows when or if it will change. As of now, it is either classic (by type) or pods.

6

For more details on the proposed folder structure see https://github.com/emberjs/rfcs/pull/143