Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Multi-team/Multi-UI Development @ Interactive I...

Multi-team/Multi-UI Development @ Interactive Intelligence

We'll show how Interactive Intelligence architects its front end to allow for multiple concurrent teams and applications to coexist within a single Ember-based application platform. Learn how we got Angular, Knockout, and Ember to coexist and how we moving forward into the future with Ember Engines.

Avatar for Todd Jordan

Todd Jordan

June 22, 2016
Tweet

More Decks by Todd Jordan

Other Decks in Technology

Transcript

  1. Who Am I? • Senior Developer @ Interactive Intelligence •

    Member of the Ember Learning Team • twitter: @tddjordan • github: toddjordan • Ember Slack: todd.jordan https://github.com/toddjordan http://emberjs.com/team/ Sign up for Ember Slack here: https://ember-community-slackin.herokuapp.com/
  2. Who Are We? • Cloud-based Global Contact Center Software •

    …plus Realtime Collaboration (chat, webrtc, telephony) • Headquartered in Indianapolis • Development Lab in RTP • https://www.inin.com/careers https://www.inin.com/careers https://www.inin.com/whoopass for a funny video on what we are doing in the cloud…
  3. Dreams within Dreams To make this cohesive UI using multiple

    frameworks, you might feel like this in looking at things…
  4. • Unwanted dependencies (Tangles) • Inconsistent coding standards • Build

    breakages/bugs • Maintenance Common codebase challenges with large teams
  5. Autonomous Teams Want • Own release cadence • Own coding

    standards • Protection from each other
  6. An Oral History I’m the Kathy Bates in this story,

    getting a history lesson from our developers who lived it from the beginning.
  7. Engage 2013 Engage is our next generation customer servicing app

    - cloud-based offering At the time Knockout was simply the best solution for the job * Ember didn’t have a concept of service, and was difficult to extend * Angular was a pain to extend its directives
  8. Code Repo Sub-App Core application code / common services As

    they were all using a single repo/code base, any break would result and total blockage for the team.
  9. Code Repo(s) Sub-App Core application code / common services Drove

    the team eventually to modularize into several repos using requirejs
  10. Angular Admin 2014 Adapted an existing angular admin app, grew

    quickly as a common admin UI. Started with developers with angular skill Designed to be iFramed and used by other apps
  11. Initially, we were thinking lets treat apps separately and access

    them with a launcher Think Google Apps Each application was separate, launched from a common menu.
  12. Single App Look/Feel 2015 We found that customers wanted a

    single app experience, with common services built-in
  13. IFRAME, Cross Document Messaging, and You Window.postMessage Window.on(‘message.x’, …) Ember

    Knockout https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage https://html.spec.whatwg.org/multipage/comms.html#web-messaging
  14. Why Ember as the App Platform? The OrgSpan App was

    a logical “Decorator” to our customer servicing product line… But choosing ember as the shell paid immediate advantages :-) • Robust Routing • Rich Addon ecosystem • A helpful and passionate community • Semver - Steady, predictable releases (no rewrites?) The main reason to have Ember as the App platform was the fact that the OrgSpan UI made sense as a wrapper, since it brought “decorative" functionality to our traditional “money makers” with chat, directory, etc (chatting while customer servicing, etc)
  15. Embedded App Component * A component renders the IFrame *

    Passes in functions to handle Window.on events from the IFrame
  16. Embedded App Service • Routing • Sending Events Back •

    App State around the sub-app (is it active, etc) * Iframe app sends a message up with the new route * service sends a message back to the app that the route has changed * Iframed app does a history.replaceState as to not update the history of the IFRAME (ensuring more consistent back buttons support)
  17. Incremental Rewrites 1. UX or significant change from Product Team

    2. Create a feature flag (in our feature flag service) 3. Implement it in Ember (preferably/eventually engines) 4. Flip the switch when ready Now that Our apps embed themselves in an IFRAME, the plan is to convert over to ember as we make changes to the platform.
  18. Engines • A namespaced, routable addon • Allows for accessing

    shared services • Like an addon, can run in a dummy app • No Cross Document Messaging needed • Can be Lazy loaded (future) • Currently Piloting with our Engage Queues App Engines going forward Though we may need to help contribute https://github.com/dgeb/ember-engines https://github.com/emberjs/rfcs/pull/10
  19. Challenges • Not quite ready for Prime-time • Lots of

    time currently spent on getting engine dependencies right. Most common complaint is that there’s not a good way to manage add-on dependencies between parent and child. • No Lazy Loading (yet) See https://github.com/ember-cli/ember-cli/issues/3718 for more of the dependency discussion in engines
  20. Apps Fuller featured embedding platform. Similar IFRAMing strategy, but normalized

    to give would be apps a stable, friendly API. Allows 3rd part apps to be part of the App platform. In the case above one of our developers built a video game as an app on our platform.
  21. We want to consolidate… • but it makes no business

    sense to stop and rewrite • We want to continuously deliver on a cadence and as we do that… • Keep developing our Ember shell into a robust application platform • Incremental conversion • Continue developing Common Components as Addons!! • Utilize our Common App Platform? • Stay with Engines and contribute to its maturity When I first joined, I saw us as a collaboration platform, now I see us as an application platform (with awesome collaboration capability)
  22. Parting Thoughts • Autonomy and Standards • Continuous Delivery and

    Ambitious Change • Choosing the best Tech and Maintenance Concerns • Customization and Reuse • Pragmatism and Idealism Truth is, we constantly balance between We are not special snowflakes in this