Bring Sanity to Frontend Infrastructure with Ember
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Selikoff, Sam
Monolithic server-side applications are on the way out - but what does this mean for our frontend code? A world of independent backend services creates unique challenges for internal frontend development: How can teams share code? Streamline deployments? Test and integrate their code with existing backend systems? This talk will discuss how Ember's conventions and tooling can bring consistency, discipline and sanity to a company's frontend infrastructure.
 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 is 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 experienced some growth. And they started 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 with 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 our 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. 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 had 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, okay, 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. 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 of 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 that they 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 it 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 from within their applications, the Ember framework itself, but Ember CLI brings this as well, right, 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's CLI, instantly they had some convention 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, right, these, these, the similarities jumped out at them easier because they were working on the 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 build the app and maybe synced it up to one of their servers and then they put it up, they put this every time they need 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, you know, they started doing it over and over and over again, 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 will 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 started a new interface, they installed 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, sorry, has nothing to do with our front-end static assets, but it's just going to be for the purpose of deploys. It's where we're going to 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, you know, 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. 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 away 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 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 queue units, set up test them, and we all had some helpers to go with. So 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 the Ember has brought. It only has 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 data, 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 back-end. We want a back-end in the browser to stand in for our server, which is not there. So we have more control over that back-end, 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 back-end 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're 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've packed it up to an add-on. And when we end up with something like a back-end 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 going to 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 their 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 kind of 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 library's 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 their other projects. They're going to know when they're going to need to contact a developer with more knowledge, but overall, they're going to be able to take not a lot of time at all to get it upgraded and that's going to 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 and just 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 going to be effective. Let's say they're using Ember data for this data layer, right? So they're going to go in and they're going to 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 going to have a stronger guarantee that new standards and best practices that emerge from the web community, those are going to 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. So 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 going to figure out some way, it's going to 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 going to be up to date and in one years, two years, five years, those things are going to 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, right? 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, right? I want to 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 going to have these services, we should try to imagine we're going to 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, in three years, in one year. And 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 backend services in this consistent and understandable way, right? And I think Ember and Ember Sealeye 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 with an Acme itself. The Acme process, the development process that happened with Acme as they brought Ember in, started 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. 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 in this talk, I guess, is 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. Thank you.
 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 is 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 experienced some growth.  And they started 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 with 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 our 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.  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 had 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, okay, 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.  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 of 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 that they  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 it 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 from within their applications, the Ember framework itself, but Ember CLI  brings this as well, right, 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's CLI, instantly they had some convention 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, right, these, these, the similarities  jumped out at them easier because they were working on the 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 build the app and maybe synced  it up to one of their servers and then they put it up, they put this every time they need  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, you know, they  started doing it over and over and over again, 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 will 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 started a new interface,  they installed 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, sorry, has nothing to do with our front-end static assets, but it's just going  to be for the purpose of deploys.  It's where we're going to 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, you know, 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.  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 away 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 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 queue  units, set up test them, and we all had some helpers to go with.  So 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 the Ember has brought.  It only has 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 data, 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 back-end.  We want a back-end in the browser to stand in for our server, which is not there.  So we have more control over that back-end, 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 back-end  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're 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've packed it up to an add-on.  And when we end up with something like a back-end 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 going to 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 their 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 kind of 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 library's  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  their other projects.  They're going to know when they're going to need to contact a developer with more knowledge,  but overall, they're going to be able to take not a lot of time at all to get it upgraded  and that's going to 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  and just 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 going to be effective.  Let's say they're using Ember data for this data layer, right?  So they're going to go in and they're going to 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 going to have a stronger guarantee that new standards and best practices that  emerge from the web community, those are going to 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.  So 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 going to figure out some way, it's going to 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 going to be up to date and in one years, two years, five years, those things are going  to 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, right?  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, right?  I want to 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  going to have these services, we should try to imagine we're going to 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, in three years, in one year.  And 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  backend services in this consistent and understandable way, right?  And I think Ember and Ember Sealeye 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 with an Acme itself.  The Acme process, the development process that happened with Acme as they brought Ember  in, started 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.  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 in this talk, I guess, is 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.  Thank you.
Bring_Sanity_to_Frontend_Infrastructure_with_Ember_0_83.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_84_203.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_204_311.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_312_395.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_396_515.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_516_911.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_912_1055.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_1056_1175.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_1176_2039.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_2040_2435.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_2436_3563.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_3564_3743.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_3744_5231.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_5232_6083.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_6084_7127.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_7128_7571.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_7572_7919.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_7920_14147.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_14148_15359.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_15360_17843.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_17844_20387.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_20388_22307.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_22308_23327.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_23328_25667.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_25668_26591.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_26592_27767.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_27768_28583.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_28584_29003.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_29004_29255.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_29256_33359.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_33360_33443.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_33444_33551.png Bring_Sanity_to_Frontend_Infrastructure_with_Ember_33552_33815.png