 My talk is on front-end infrastructure with EmberJS. My name is Sam Selikoff. I live in Burlington, Vermont with my wife. I work at Ted Talks, a conference company. And if you catch me outside and want to talk about something non-tech related, I like economics, snowboarding, and music. So I'm going to start off with a story. This is a story about a company, Acne Inc. Their startup. So they're just launching their first web project. They got a handful of programmers. It's a web app. And the code base that supports this web app, it's a single code base. All the programmers are working on it. It's pretty simple. And that's pretty much all there is to it. Now, this code base starts off in this kind of story as a monolith. And I don't say that disparagingly. It's a single code base. And it has kind of a single logical purpose. There's a handful of programmers. They're all working on the same thing. So this is what makes sense. And this is kind of the initial phase. So Acne experiences some growth. And they start to have more demands on their products from their customers and also from internal users, from their company. They start growing. They hire people in accounting to help the customer service. And so a single code base doesn't cut it anymore. So what they do is decide to split this code base up into multiple different back end services. And they kind of make a data layer out of this. Now, at the same time, they split up their front end interfaces into multiple products. They still kind of have this main client facing web product that was the original product of the company. But they've also made additional client facing and also internal web products. And so they've kind of went with this model where they have lots of back end services acting as their data layer. They have a lot of front end interfaces, JavaScript applications, essentially. And then they communicate over this API. So let's take a look at Acne's infrastructure, kind of after this period of growth and after they've been hit with some complexity. Now, the back end, this is really where Acne's programmers shine. This is kind of where the area of expertise is. So their back end systems, as they kind of grew and they became more complex, they had a good process for how to split apart the original monolith and make it into separate services. These services were all independent. They could scale them independently. So if one service needed more resources or became more complex, they could work on it without affecting the other services. But importantly for this talk, the back ends were consistent. And what I mean by that, not the technical term consistent, but consistent in a way that Acne's programmers, both people who hadn't worked on particular apps and new programmers that were hired, fell at home in these code bases. They were all structured similarly. And it made them productive. They didn't have to waste time figuring out how each app was set up, how the architecture was set up, how data moved through the application. So now let's look at their front end infrastructure. So the programmers, they weren't as kind of well-versed in how to scale out their front end infrastructure. And so originally they didn't really have many decisions to make around this. They kind of had the single code base, rendered this web app, and that was pretty much it. But now the picture is much more complicated. They have a lot of interfaces. What happened was every time they needed a new interface, whether it was an internal web product for accounting or something for customer service to help with sales, the programmers had to make a lot of decisions. They had to decide, OK, which JavaScript and CSS libraries are we going to use? How are we going to actually set up our build pipeline for this new front end? What's our data layer going to be? Because now we're building rich client-side applications. We need a layer that is for requesting data from our APIs and worry about caching data within the browser. How are we going to deploy these apps? And how are we going to test them? And so these are, among other things, a variety of questions that the programmers had to answer every single time. And they kind of answered them differently. Different groups of people were responsible for them. They didn't have the same consistent process for spinning up new interfaces that they did for their back ends. And so this caused a lot of problems. But first of all, it wasted time. They were worried about these questions each time, and that just cost programmer time. It's hard to share code across the different interfaces, because these questions were answered slightly differently. Slows down new devs who are trying to get familiar with their infrastructure. Ultimately, it really just kind of hampered the growth. As complexity was growing inside the company, it was difficult to keep up with all these interfaces. So what is Acme to do in this situation? What can they do? Well, I think one thing they can do is start adopting Ember and Ember CLI for these interfaces, for their front end projects. And I think Ember and Ember CLI goes a long way to help Acme with this problem they've kind of found themselves in. Two main ways that this works. First, today, if they started using Ember and Ember CLI within their company, it could improve their infrastructure. So the tools and the principles exist today to start immediately answering some of these questions in a more consistent way. But I think the more important point is that it will help them in the future, because Acme doesn't know kind of where they're going to end up. They don't know what their infrastructure is going to look like in a year or two or five years, and Ember brings the same process to their front end developments as they already have in their back ends. So let's look at these two points. So let's look at first, how can start helping them out today? Well, there's some obvious things that probably most of us in this room know already. So Ember and Ember CLI reduce boilerplate. And this is true within their applications, the Ember framework itself, but Ember CLI brings this as well and gives these commands. And so any programmer working in any of these front ends is going to know how to build or serve or test these applications. It gives their applications a similar directory structure and a similar architecture, not just in terms of how it's laid out, but again, also how data moves through the application. So what it's really doing is providing consistent answers to these questions. One way you could sum this up is by saying that Ember brings conventions to Acme's front ends. Now we hear a lot about conventions when we talk about Ember. It's an important part of our philosophy, the community's philosophy, the framework's philosophy. But it's more than just about, conventions are more than just about reducing boilerplate. I think one way to think about conventions is this. They eliminate trivial differences between our applications that hold us back. And holding us back is the important point here. Again, it's not just about having the same answer, but it actually lets Acme move to a new level, higher levels of productivity and abstraction within their company than they otherwise would be able to do. So let's look at two concrete examples of how this actually happened for Acme. The first is with deploys. So by using Ember and Ember CLI, instantly they had some conventions set across all their apps. Ember Build clarified this notion of what a distribution was for them. Ember Build created this kind of disk and they realized, well, that's really what this Ember app boils down to. And you could say, well, maybe they understood this before like a static app is just a group of static assets. It has to be deployed somewhere. But time and time again working on these apps over and over, running Ember Build and maybe manually copying it up somewhere, they started to see these similarities jumped out at them easier because they were working on a shared convention. So the next thing they did for all their apps that they were just running Ember Build for, they wrote a script, right? And they wrote a script that built the app and maybe synced it up to one of their servers and then they put this, every time they needed to deploy a new interface, they put this script up on one of their CI servers. So they started doing this and this was better than what they had before but they started doing it over and over and over again in each new interface. Again, they were repeating themselves. It's kind of like they were moving up this ladder where the more that was held constant across the organization, the easier it was to identify these trivial differences, the things that were the same and the things that were different that didn't really matter. So they came to understand really what a deploy is all about. Them and the rest of the Ember community, right? This is kind of maybe the development that happened over the past year with some of what Luke's worked on. They came to understand that, well, really when we deploy, we need to just put an index up on our server that's serving up our app and we need to update our JavaScript and CSS assets. Once we configure our backend servers to work with this, we really just need an add-on and that'll take care of the front-end part. And so again, their deploy process evolved and it kind of moved to this next level. And so now each new interface had an add-on and they just, when they start a new interface, they install the add-on, their backends were configured and so it became even simpler. Ember deploy was all they needed to do to deploy their apps. Okay, so finally, there's one more thing that happened. Even though this was even simpler, they still had to set up the backend when they needed to say a new API layer and they had to set up authentication, right? And again, they're doing this over and over again, months and months, one of the programmers realizes, well, why don't we abstract this even more? So why don't we extract some of this off and backend config work, put it in its own deploy server? So we'll have a separate server that has nothing to do with our APIs, has nothing to do with serving or sorry, has nothing to do with our front-end static assets, but it's just gonna be for the purpose of deploys. It's where we're gonna send the static assets so that they can be served up, but it's also going to proxy these API requests to our backend API layer, right? And so some of this is inspired by what's actually happened with companies within the Ember community and some of it is just some ideas that people have floated around, but the point is here that bringing Ember and Ember CLI into the organization established these conventions. It's kind of established the bottom rung on this ladder. And very quickly and consistently, the developers were able to kind of innovate along what it meant to deploy their app and to make it more general, more abstract, and ultimately more powerful. And so you can see if, oh, back when they were kind of all writing their own JavaScript apps and each team was kind of answering these questions their own way, they could say, oh, we're all deploying our apps, like what do we need? Well, that's an easy question to ask, right? The hard thing is how do we get to the answer? And if someone would have said, oh, we need a deploy server, that's too far of a reach because you haven't even identified what's constant across your apps. And so the nice thing here is that by establishing that baseline, bringing those conventions, it gave Acne's engineers a way, a process for discovering the shared things when they were able to iterate and grow and climb up that ladder of abstraction. And so the next example of how this helped them today is in the area of testing. And it's a similar idea. Bringing an Ember and Ember CLI kind of established this baseline convention. So now, instead of having to start from scratch with each of our frontends, Ember set up QUnit, set up Testim, and we all had some helpers to go with. But as they looked across their Ember apps, that's kind of where the similarities ended. They were still writing a lot of their own code to wire up their test harness and they still had to figure out how to get fake data into their testing environment to assert against that. And that was still a decent amount of work that they had to do. They did this over and over again and the similarities started jumping out again. So they realized what they need was an XHR interceptor. So they needed a way to basically plug in a server, something that would respond to the API requests and get data to the Ember app so that the Ember app could be populated and it could start asserting against the data it had. So it's kind of the same process. They kept doing this. They realized the script that had the code that wired up the interceptor was the same and they just wrote an add-on. We see here again something else that Ember has brought. Not only has it established the conventions, which let them identify the things that were the same, it's given them tools like the add-on infrastructure and the Ember CLI build pipeline, which lets them easily experiment with these solutions. So they wrote an add-on and now all their interfaces have this add-on, more consistency across the board, easier for new programmers and existing programmers to work because there's more similarity across the apps. This final level abstraction is okay, instead of just an add-on, we now have this add-on and we still have to wire up the routes for each app and we still have to figure out how to get maybe fixed your data or fake data into this server, the server that's kind of intercepting our API requests. So if you think about it, what we're really doing is we want a backend. We want a backend in the browser to stand in for our server, which is not there. So we have more control over that backend so we can assert against it and test against it. That's really what we're doing. And then additionally maybe eventually we want to be able to populate that backend in a browser with data from our actual server so we're really running end-to-end tests all the way from our JavaScript apps to our data layer. And this brought some cool things like the ability to generate factories. So again, they're writing even less code, there's even more consistency. So the idea here is the same. They started out, Ember established these baseline conventions, they were writing manual test code, they identified, okay, this piece are the same, what we really need is an interceptor, it's a script that we've shared, now we package it up to an add-on and when we end up with something like a backend in the browser. Again, we see this process which leads to this discovered solution, this thing that they didn't know that they needed, but the process enabled them to find it. And so that's really how Ember and Ember CLI helped out ACME today. It's about giving them a process for identifying redundancies and being able to extract new solutions and identify the abstractions that are gonna work within their company. And just to point out, you can say they had the same apps at the beginning. Why can they just identify these redundancies? Well, it turns out identifying the redundancies is very difficult and often it's less damaging to just duplicate yourself than it is to get stuck with a bad abstraction. That's true with infrastructure, that's true in a lot of programming problems and so it's really important to have a process for discovering the right abstractions. Okay, so that's kinda how Ember and Ember CLI can help them out today. Let's look at how it can help them out in the future. Well, first, it helps them stay up to date. Sember, semantic versioning and the conventions that Ember CLI bring are really important for making sure ACME during this growth period, as they're branching out and they have half a dozen, a dozen, more, front-end apps, all the apps stay up to date and they stay consistent with each other. I think it's easy for a lot of people to dismiss semantic versioning, but with something like the conventions of the CLI upgrade process and the semantic versioning of the libraries, Ember, Ember data, the various libraries, in an organization like ACME that really enables one developer, gives them the confidence to go into a project that they've never even touched before and they can be confident in how to upgrade it because it follows the same conventions as there are other projects. They're gonna know when they're gonna need to contact a developer with more knowledge, but overall, they're gonna be able to take not a lot of time at all to get it upgraded and that's gonna keep things consistent, keep things fresh. This kind of combination also gives ACME flexibility into the future. The stability that they get from having the various interfaces much more consistent and uniform, it keeps their overall architecture much more flexible and it lets them swap pieces in and out. So you can imagine them making a decision to some of the back-end engineers making this thing to split out one of the server-side components into two and because all their front-ends are similar, the front-end engineers know there's only one layer where this is gonna be effective. Let's say they're using Ember data for this data layer, so they're gonna go in and they're gonna make the changes but everything else is the same. So that's kind of the power that this consistency brings and how it keeps their architecture flexible. Now I think the biggest thing that it helps ACME with when thinking about the future is that ACME is gonna have a stronger guarantee that new standards and best practices that emerge from the web community those are gonna make it back into these interfaces and let me explain why. So I think all the frameworks do this. I think all the frameworks are really important and not just the mega frameworks, smaller libraries too but these shared solutions that we all use are really important for helping us discover and identify what best practices and standards are, the new standards that we should be using. They help us discover things that make building quality software easier, better and faster. But I think Ember more than any other framework is absolutely relentless about identifying the best practices and standards that have emerged from the community and rolling them back into its own. And it's gonna figure out some way, it's gonna be determined to figure out some way to make these new best standards and practices available to anyone building an app with Ember. So whether that's promises, whether that's an entire new rendering layer, building your app with ES6 modules or something like rendering on the server, if you think about the longevity and the importance of longevity to ACME, a company like ACME that is growing, has lots of diverse groups internally, has many interfaces. To be able to say that all those interfaces are gonna be up to date and in one years, two years, five years those things are gonna incorporate modern best practices that's extremely powerful for an organization. So just in closing thoughts, when they started out, these architecture questions weren't that big of a deal. There was a single code base, they rendered a single web application and that was pretty much it. But when you move to kind of this environment that's more complex, there's not a one-to-one relationship between your backends and your frontends, it becomes more difficult. I wanna make a point that ACME was right to start with a monolith. The problem was not that they should have sat at the beginning and thought, hey, we're gonna have these services, we should try to imagine we're gonna be in a couple years and split our backends into these five services and make these eight interfaces, that's not what they should have done. But they don't know when they're starting out what their apps will look like in five years and three years in one year. In their server side components, they had a process. They had a process that they were able to follow once things started getting complex and that let them break out their back-end services in this consistent and understandable way, right? And I think Ember and Ember Seal, I can do that for their frontends as well. Ultimately, I think Ember is not just a framework. It's really a philosophy. It's a philosophy about how to create and improve software and it's essentially, if I had to boil this philosophy down, it's what we saw at work within ACME itself. The ACME process, the development process that happened with ACME as they brought Ember in, sort of refining their infrastructure, that's kind of a microcosm example of this. And the philosophy is essentially this. The first step is you want to give real developers the tools to tinker, right? You want to encourage them, real developers with their boots on the ground, building actual applications to tinker and to experiment with what they need. And that's going to let them identify the things that are the same, the redundancies. Then you want to be extremely deliberate, relentless about folding these things that you've discovered back into shared solutions. Now if you think about it, these tenants, they're absolutely embraced by the core team of Ember, right? But they're also embraced by the Ember community. And in fact, this is really how web standards and even the JavaScript language itself evolves, right? It's basically, I think a lot of people have come to believe that, the notion that you can get a small community of people and top down analyze the problem and say, these are the actual primitives and abstractions that we need. That's basically gone, I think. It's clear that the way to actually develop successful applications and identify the primitives that are actually going to be valuable to real developers building real software is to let them tinker, let them innovate. This is the path to consistently letting developers write higher quality software. So if there's one kind of call to action of this talk, I guess it's to embrace this philosophy yourself, is to within your own development, your own company innovate, identify things that are the same, but be relentless about sharing them within your organization and within the rest of the community. Thanks a lot.