Ember in the deep end
- Proposal for: UtahJS Conf
Blurb: The Ember.js website says: “Ember.js is built for productivity. Designed with developer ergonomics in mind, its friendly APIs help you get your job done—fast.” Join us as we go through a mission-critical Ember application and see if this is the case.
My own definition may or may not be universally accepted, but I believe that it’s closer to what a large application actually represents.
Large as in?
- Size (Codebase)
- Developer Count (Contributors)
- Business Centricity
- Project started: 16 December 2013
- Beta rollout: 4 February 2014
- Production rollout: 30 March 2014
- v2 refactor started: 11 November 2014
- v2 Beta rollout: 19 February 2015
- v2 Production rollout: 13 March 2015
- .js LOC: 6,227
- .html LOC: 1,574
- .css LOC: 646
- Total LOC: 8,447
- Ember version: 1.7.0
- Uses require.js for dependencies
- Major portions rewritten or refactored earlier this year (see the timeline)
- Uses EmberData to communicate via REST to C#.NET backend. C# in turn aggregates data from Salesforce(CRM) and Zuora(Billing & Subscription) via SOAP calls. It also created subscriptions and customer records in both.
- Salesforce governor limits
- Salesforce query limits (both number of queries you can execute and table joins per query)
- Zuora API documentation
- Zuora subscription data model
- Salesforce frontend working with EmberJS (hint: it’s not easy)
- Routing is your friend
- Customized RESTAdapter. Helped us do dev on local machines with disconnected data, or use data in any environment we wanted.
- proxy.php helped avoid CORS issues
Target Audience: Experienced Developers