Multiple Ember Apps, One Product

Problems as an Ember app gets large. Workarounds until Engines.

Transcript

1. Multiple Ember Apps, One Product Workarounds until Engines – by John Kurkowski
2. Overview • Problems as an Ember app gets large • Current workarounds • What Engines solve • CrowdStrike’s approach: successes & failures
3. Amazon Home Page
4. Amazon Checkout
5. As a software product gets large… • Maintenance, reason-about-ability • Short compile/test time • Parallelization & stewardship • Isolate tech debt • Prototype quickly
6. Techniques • Split up the product into smaller pieces • Split up into dedicated teams • Share code
7. How does Ember hold up? Ember addons are great for sharing individual Ember classes (e.g. components, mixins, services).
8. How does Ember hold up? What about sharing something bigger? With its own routes?
9. How does Ember hold up? Ember has no built-in support for sharing something larger than a component. (e.g. checkout flow, forum, user account mgmt.)
10. Workarounds • Share as much you can in a common library (e.g. Ember addons)
11. Workarounds • Multiple Ember CLI apps – Each with the full boilerplate of `ember new`. Yup. – Must figure out how to organize in e.g. Git, NPM. – How to approach seamlessness? •  Reverse proxy to each app, e.g. –  “/home/*” routes to “cdn.com/home/index.html” –  “/checkout/*” routes to “cdn.com/checkout/index.html” •  Outer app with persistent header/nav, iframe to each child app –  What about iframe style? –  What about parent browser vs. child iframe URLs?
12. Workarounds Who wants to write their own platform? They want official support.
13. Engines RFC • Big update in recent months by Dan Gebhart, of Tilde • A way to tell a parent Ember app to load a child Ember app (Engine) within a URL namespace – Only diffs with a real app •  It doesn’t “boot” itself •  It doesn’t control the router • Parent runs the child – Injects dependencies – Maps/deconflicts object names – Determines the static asset versions, e.g. Ember
14. Engines RFC • Can lazy load engine assets • No ETA – Author is thinking about incremental delivery, as it’s a large change
15. Engines Usage • Generate your addon – $ ember engine <engine-name> • Write an App-like file, but call it engine.js instead • Write a Router-like file, but call it routes.js
16. Engines Usage //  routes.js   Router.map(function()  {      this.route('address',  function()  {          this.route('billing');          this.route('shipping');      });      this.route('payment-­‐info');      this.route('place-­‐order');      this.route('confirmation');   });
17. Engines Usage – Consuming App • Install your addon – $ ember install <engine-name> • Mount it in your Router
18. Engines Usage – Consuming App //  router.js   Router.map(function()  {      this.route('home',  function()  {          this.route('big-­‐sale');          //  ...      });        //  Checkout  engine  to  handle  /checkout/*      //  e.g.  /checkout/{billing-­‐address,shipping-­‐address,...}      this.mount('checkout');        //  Discourse  engine  to  handle  /forum/*      this.mount('discourse',  {path:  '/forum'});   });  
19. CrowdStrike’s Multiple Apps • We are reverse proxying URLs on a single domain to multiple apps – Some Ember CLI, some Ember, some not Ember at all • Our desired UX is like apps on a smartphone; dotadiw • This makes URL rules simple, e.g. – /foo/* goes to summary dashboard app – /bar/* goes to alerting app – /baz/* goes to hunting app
20. CrowdStrike’s Multiple Apps Pros • Develop 1 app at a time is typical; build/test time way faster • Flexible with libraries and varying versions • Isolated tech debt • New prototypes are easy to deploy alongside
21. CrowdStrike’s Multiple Apps Cons • Keeping boilerplate in sync – Ember CLI – Package versions – Universal CrowdStrike imports, initializers • No oversight to regularly extract duplicate code – Rule of 3 • User must re-download assets; FOUC unavoidable • New libraries and varying versions is flexible. But is it good?
22. CrowdStrike’s Multiple Apps Suggestions • Isolate tech debt very temporarily; don’t lie to yourself it’s really gone away • Share common libraries in a separate build, to avoid re-download – Import in index.html, rather than let Ember CLI concat • Need a bigger team to continually… – Sync library versions – Extract duplicated code •  Perhaps be more relaxed about Rule of 3
23. Looking Forward to Engines? • Yes!
24. But… • A little worried I won’t be able to run multiple Ember versions • However, this could be good discipline: – All prod engines run on Ember 2.1 – Prototype a new engine separately on e.g. Ember 2.2 – To merge to prod, must to do the work of upgrading all prod engines to 2.2
25. Holding Your Breath For Engines? • Don’t. It’s only an idea. No implementation ETA. • Stop planning ahead for how you’re going to take advantage of new features • Relax
26. References • Engines RFC • Ask Tom and Yehuda: What's the deal with engines? • Stack Overflow: Multiple “apps” with ember-cli • Microservices allow for localized tech debt
27. Thank you! • Questions? • Keep up with me @bluu