Post on 11-Apr-2017
Multi-Team/Multi-UI Development
@Interactive Intelligence
Who Am I?• Senior Developer @
Interactive Intelligence
• Member of the Ember Learning Team
• twitter: @tddjordan
• github: toddjordan
• Ember Slack: todd.jordan
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
3 Web Frameworks
One Cohesive UI
Dreams within
Dreams
Large Scale Development:
Its hard.
The more people on a team, the harder to
manage.
• Unwanted dependencies (Tangles)
• Inconsistent coding standards• Build breakages/bugs• Maintenance
Autonomous Teams Want
• Own release cadence• Own coding standards• Protection from each other
An Oral History
Our Story BeginsCirca 2012
Ember 0.98@OrgSpan
Engage2013
Code Repo
Core application code / common services
Code RepoSub-App
Core application code / common services
Code RepoSub-App
Core application code / common services
Code Repo(s)Sub-App
Core application code / common services
Angular Admin2014
Acquisition2014
Initially, we were thinking lets treat apps separately and access them
with a launcher
Think Google Apps
Single App Look/Feel2015
IFRAME, Cross Document Messaging, and You
Window.postMessageWindow.on(‘message.x’, …)
EmberKnockout
KnockoutEmber
EmberAngular
EmberAngularEmber
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?)
Embedded App Component
Embedded App Service
• Routing• Sending Events Back• App State around the sub-app (is it active,
etc)
Incremental Rewrites
1. UX or significant change from Product Team2. Create a feature flag (in our feature flag service)3. Implement it in Ember (preferably/eventually engines)4. Flip the switch when ready
2016
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
Engine!
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)
Apps
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
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
Thanks!!!!