We celebrated some birthdays last month. I had a big one and Square turned 12. Now you might know Square as the little white card reader that plugs into cell phones that lets you take payments on the go. But we've actually developed a suite of hardware solutions to help merchants take payments and a suite of software to help merchants manage their business. And that software is called Dashboard.

And this is what Dashboard looks like. Merchants use Dashboard to keep track of their business. They can see their payment activity, they can send invoices, and they can run payroll. Dashboard is the home base for Square sellers.

And Dashboard is an Ember monolith. Today, I am here to talk to you about modernizing our massive Ember monolith dashboard. My name is Aubrey Knudsen and here I am at EmberConf in 2018 with Tomster and Zoe. I have been working with Ember for about five years. Two years in our dashboard application and three years in a separate application

that was a greenfield app and is a little more modern because it was newer. I have been participating in code upgrades and migrations and dashboard and have recently been driving engine adoption from a product team, not an infrastructure team role. And I'm here to convince you that you can build ambitious web applications with Ember that stand the test of time.

Today, I will convince you that with Ember you can build for the long term. Ember apps can be used for years, almost a decade in our case. This is important because time is a finite resource. When we at Square have done the analysis in the past, a rewrite is always more expensive than the proposed upgrades.

By spending less time on total rewrites, we're able to spend more time working on features for our customers and there's less chance of regression. And finally, when we stick with Ember, we're able to build knowledge and expertise in our engineers that is long lasting rather than changing frameworks every couple of years.

Our engineers become fluent in Ember, which makes them more productive over the long term. Today, I will convince you that with Ember you can build resilient apps. Ember apps can be used by tens of thousands of people every day and have hundreds of developers contributing because we've seen this in our app.

And today, I will convince you that with Ember you can build apps that evolve. We built an app in 2011 and now in 2021, we are using 2021 web technology in fundamentally the same app. So long as you're on the standard Ember path, Ember makes upgrading easy via documentation

and semantic versioning, long-term support or LTS releases, which are versions of Ember that receive security updates for an extended time after their release. And code mods and lints. Code mods are tools that automatically make the tedious syntax changes to your code

that you would normally have to do manually. Code mods can help ensure that you are using the latest patterns and platform features. And lints are static code analysis tools used to flag programming errors, bugs, stylistic errors and suspicious constructs, and they often use code mods to automatically fix violations in code.

But even in applications with weirdware, which I define as deprecated packages or experiments in code where we've strayed from the standard Ember path, those times when we've decided to roll our own, it's possible to stay current with some effort, even in a massive application.

We've done this over the last 10 years. Our app has a dedicated team that runs most of our upgrades, which helps a lot, but they do it in conjunction with product teams because they don't know how everything in the app works. But upgrading is possible even without a dedicated team, though it will be easier if you don't use any weirdware.

In a much smaller, more standard app, I was a dedicated upgrade team in addition to my product feature responsibilities. So this is the story of Square Dashboard. To give you some context, this is the commit visualization over the last almost eight years that Dashboard has been in its own repository.

And to give you a sense of scale, in 2020, we had an average of 140 developers contributing every quarter with an average of 1,500 commits per quarter. And by my count, we've had over 600 individuals contribute to this code base at one point or another in their careers at Square. But this isn't 100% my story to tell.

I joined in 2016, and then I switched to a non-Dashboard Ember team for about three years and came back to Dashboard in 2020. Several of my coworkers helped me write this talk, and I want to thank them for that. So let me take you back now to 2010. Wow, do you remember what the web looked like in 2010?

I honestly didn't until I saw this screenshot. At this point for Square, our main product was swiping a card on your phone and emailing or texting a receipt instantly. In 2011, we have a slightly newer looking website. It's still very simple, though. You can take a payment, you can see your balance, and you can see when your balance will be paid out to your bank account.

And in November of 2011, we introduced SproutCore 1, which was a precursor to SproutCore 2, which was later renamed to Ember, in our Ruby Mono repo next to our ERB templates. And the commit message for this says, first day of hacking. And that's exactly what it was. It was basically 100 lines of script tags.

In 2012, we had what we considered sort of our logged in web payment experience. It's so cute, right? The buttons have shading and depth. This is the view layer of our original Square Rails app. There's a simple tab of transactions, and you can click to view your receipt details, and you can filter your transactions by date.

In 2013, we started to break up our web properties into separate apps. Dashboard was already getting too big and slow, and early code sharing via gems and Git submodules didn't work well. And so we moved Dashboard into its own repository, and it was a Rails app, and we were using Ember Rails,

and we added Ember version 1.0.0.rc3.4. How's that for a version number? And in 2013, our app has some tabs across the top, adding more functionality as we are developing more features. In 2014, we did a total redesign and CSS rewrite,

and now this is where it starts looking much more like the modern web to me. And as you can see, we continue to add features across the top. In 2015, in January, we upgraded to Ember 1.7, and for reference, 1.7 was released in August of 2014.

At this point in time, upgrading wasn't a big priority for Square, and we didn't have a team primarily focused on doing it. This is also where we decided to start looking at our Dashboard navigation project and figuring that out, but other than that, there is not a lot going on at the moment with the Ember framework and Dashboard. We're busy building features. For example, we built and launched a Square payroll.

Ember wasn't being super high maintenance, and it just kind of faded into the background. In 2016, in January, Ember is still on 1.7 in Dashboard, and then in June, Ember 1.13 lands, and that was launched to the community in June of 2015,

so we're about a year behind. But luckily, we didn't get stuck on 1.12. So when I joined in August, we were on Ember 1.13, and I am told I dodged a bullet because I showed up late enough, or maybe I showed up right on time. In any case, a lot of people had a bad experience upgrading to Ember 1.13

because it was really painful, and Ember maintainers learned from that experience, and they try not to do that anymore, and they try to make upgrades a lot easier. 2016 was a year of more features. Everything at this point was written in CoffeeScript. That's because when we started Dashboard in 2012,

JavaScript was a very different language. ES5 didn't exist. ES6 was introduced in 2015, and so CoffeeScript was created as an attempt to expose the good parts of JavaScript in a simple way, and the code compiled one-to-one to equivalent JavaScript, and there was no interpretation at runtime, and so CoffeeScript was the way to write web applications easily,

and that's what we were using. But by 2016, we have ES6, and so we're starting to add new code in JavaScript, and at the same time, we were encouraging component use in Ember. Components had been available starting in 1.0, but we Sprout Core folks held on to the MVC structure a little longer.

So for me in 2016, I was learning Ember. I was learning ES6 syntax, and I built this cute component that shows you your subscriptions and your monthly charges, and in December, we upgraded Dashboard to Ember 2.0, which had been released in August of 2015. That brings us to 2017,

and I am dubbing 2017 the year of upgrading. This is where I think our dedicated team really shines. They were the ones driving this upgrade timeline, so product engineers didn't need to know how to upgrade our app, but they still worked with the product teams to verify that the features were still working,

and so this verification process and requiring many teams to work together means that our upgrade timeline is a little slower than you might expect. So in January, we upgraded to Ember 2.1 and 2.2, which had been released in the fall of 2015. In February, we got to 2.5, which was released in April of 2016.

In May, we got to 2.7 and 2.9, which had been released in July and October of 2016, so at this point, we're about six months behind, and in September, we got to 2.15, which was released that month, and so we're all caught up, and in December, we moved to an Ember CLI app,

and we had to rename hundreds of components to match Ember CLI conventions, which we did with a code mod, and we also upgraded to Ember 2.16.2, which had been released a couple months earlier. Around this time, CoffeeScript was deprecated in favor of ES6 and JavaScript,

and so we decided to do a CoffeeScript migration using a tool called Decaffeinate, which is a code mod that converts your CoffeeScript to JavaScript, and it was written by one of our developers and is an open source tool. We had coffee and donut parties, and we would be hanging out in a conference room, running the code mod all together, so it was a really great bonding experience

for dozens of engineers helping out with the migration, but now my name is on thousands of lines of code that I didn't actually write. At this point, we also have a team effort to manually eliminate partials. Components were becoming, and now are, the preference in the writer front-end community,

and this was an effort to move our code to match the current Ember path to make upgrading easier. In August of 2017, we figured out what we were going to do with our navigation structure, and we split out this navigation into a separate Ember app,

and so now, even to today, we have two Ember apps running on the same page, and one of our developers actually updated the Ember inspector to support two Ember apps, and that was pretty painful, but we got it working, and now you can choose which Ember app you want to inspect, but this is actually a much less active repository,

and actually, RenovateBot, which updates dependencies, is contributor number two. In 2017, we also created something that we called subapps. They weren't in repo add-ons, but for simplicity, you can think of them as in repo add-ons,

and we did later convert them to be in repo add-ons, and we used a code mod to move all of our files around, and this decomposition let us run fewer tests in CI, which made builds faster and less prone to dealing with flaky tests, which was a good thing for developer experience. It also gave us better code organization

because each product team had their own subapp that they owned, but it also created a lot of weirdware that we had to maintain over the years, and we struggled to maintain isolation between our subapps. So when the isolation wasn't perfectly enforced, developers could break our main branch by changing code that another subapp relied on

without knowing that the subapp was gonna break because CI wouldn't run the tests for that other subapp, and so their PR would pass and go green, but then the main branch would fail, and we used linting to help maintain isolation, but it definitely wasn't perfect.

In any case, I think people tend to underestimate how much experimentation you can do in Ember. We were experimenting with our dashboard navigation and with subapps. You know, at this point, we have two Ember apps running on the same webpage, and I think that Ember gives you more flexibility than you might think, and you'll see that as I keep explaining the next couple of years in dashboard history,

but I think you also have to balance that flexibility with your tolerance for weirdware. In 2018, in January, we created a first version of our CSS library that was released as an Ember add-on, and we had extracted common styles and components from dashboard to be used

across many of our Square Ember apps, and then we also upgraded to Ember 2.18, which was released that month. In April, dashboard got its first engine, and in August, we upgraded to Ember 3.1, which had originally been released in April earlier that year. In 2018, we also added a package called YRJS,

and this is based on Square's open source package called YR, which is designed to incorporate protocol buffers in Android and Java. We use protobufs for a lot of our service-to-service communication, and it's often easier for developers to create APIs for our dashboard front-end using protos,

but protobufs are the worst on the front-end, and so YRJS is what we built to make it a little bit better. One of our tools, one of our developers built this tool to make it easy to consume and use protobuf APIs in dashboard, and it also let us do a little bit of modeling without using Ember model or Ember data

or some other structure on the front-end, but this is definitely a weird wear alert for you. This package hasn't been open sourced, and I think we'd like to find a better solution, but it hasn't been top priority, but other than that, in 2018, we just keep building features, and we never really hit sort of a cliff of like,

we can't keep going because of the framework or whatever else, and that momentum is important because it helps our engineers trust Ember as a reliable, stable framework, and they continue building up their fluency with the framework's patterns, making them more efficient. In 2019, we rewrote the dashboard homepage,

and we added these widgets, and you'll notice that the navigation looks different. We ended up writing the homepage as an Ember add-on, which is starting to modernize our dashboard even more. In March, we upgraded to Ember 3.2, which was originally released in July of 2018.

In April, we got to 3.6, which was released in December of the prior year, and in August, we upgraded to Ember 3.12, which was released that month, so we were again caught up, and that is an LTS version. We also started doing more with Yarn workspaces. So Yarn was released by Facebook in 2016,

and we were actually pretty early adopters in dashboard and brought it in, and then Yarn workspaces were released with Yarn 1.0 in 2017, and we added them to dashboards shortly thereafter, but we didn't start using them earnestly until 2019 because workspaces were buggy for many of the first releases of Yarn,

probably until about 1.12, which was released in 2018 at the end of the year, and we actually ended up contributing a fix to Ember CLI so that it could find Ember add-ons in a workspace, and what we had experimented with and discovered was that in-repo add-ons work, and you can do that, but for us, workspaces were a better solution.

We had learned with our subapps that when you use in-repo add-ons, you don't really know where the boundaries are between add-ons and the app code and between individual add-ons, and Yarn workspaces let us keep our add-ons in the dashboard monorepo, which improves dependency management, while also delineating boundaries

using standard Ember add-on patterns, and then at this point, my team restaurant started moving our subapp code into a real add-on, which is an important move towards app decomposition with engines because engines wouldn't have access to subapp code or in-repo add-on code. At this point, we also added React

running concurrently inside of Ember in dashboard. There was a team that needed photo editing capabilities for a feature they were building, and that allows merchants to insert their own images into marketing emails that they send, and they decided they wanted to use a package called photo editor SDK, which was a React app, and so we ended up packaging the React app

into an Ember add-on so that we could use the Ember asset loader to asynchronously load and execute the entire React framework and app code, and we did extra work to make sure that React would be lazy loaded only when you visit that features page, so you won't always be loading React. It's important to note here, though, that we're not actually sharing any merchant context

with the React app. In 2020, we upgraded to Ember 3.16, which is another LTS, and we opened the PR in May, and unfortunately, it's still open because we had too many observers in Ember model that broke when we tried to get to Ember 1.13,

but even though we're behind, we're feeling okay because we're on an LTS. For a little background, Ember model is a lightweight modeling library for Ember with a limited feature set, and it was released as an open source project in 2013, and we started using it in Dashboard around that time, and its last release was in 2018, and we had continued to maintain a special square branch

to patch problems as we continued to encounter them, but we had ended up using Ember model for several, several years, and in 2020, it all came to a head, and we came to this crossroads. Ember model was weirdware, and it was breaking Dashboard, so like we had before, almost annually, we asked, is this the breaking point?

Is this where we decide to toss it all and rewrite it, and if we do that, should we rewrite it in React? And the answer was no. We decided that though the upgrade path was costly in the short term, there were so many benefits in the long term that it was worth it to migrate from Ember model to Ember data.

We'd get rid of the Ember model weirdware, and there would be better documentation and more community support for using Ember data, and we would also get more extensive functionality for the models that we migrated. We also realized that we'd be able to upgrade Ember more quickly in the future. And finally, rewriting in any other framework

we knew would be at least an order of magnitude more difficult than the proposed migration, although we didn't know the exact difficulty. The established Ember path has a lot of value, and so we decided to stick with it. So we started an Ember model to Ember data migration, and to give you a sense of scale,

we've converted over 800 models in about 500 files off of Ember model, and we're well on the way. We're not done yet, but I'm really excited about octane features to come that we'll be able to get once we're able to upgrade past 3.12 and to be more on like a standard Ember path again and Ember infrastructure, so we won't have to go through this kind of painful migration again.

In 2014, Square open-sourced a package called QUnit BDD, which stands for business-driven development for testing, which we used extensively in Dashboard. But in 2017, Square deprecated this package, recommending that folks use Mocha instead for BDD-style tests. However, we continued to use this package into 2020,

and we knew that it was weirdware, and so one of our developers wrote a code mod to switch from QUnit BDD to more regular QUnit modules, and another developer wrote a code mod to remove some custom assertions that we had built into Dashboard's QUnit in favor of QUnit DOM. And I really like QUnit DOM. I had used it on my other team

and was excited to have it back, and I think it's important to recognize that the Ember open-source community has a lot to offer, and I'm excited that we are going to continue incorporating more of it into Dashboard. In 2020, we also had to push for more engines. We created a generator for conveniently setting up add-ons and engines in our Dashboard monorepo.

I wrote my first Ember engine in the monorepo, and I ended up writing a lot of documentation about how to do it. And since then, I've taught a class on how to build engines internally, and we've seen an uptick in teams interested in building their own engines, and we've also started a TypeScript conversion.

So you may be asking, why engines? We have decided that engines are the future for Square Dashboard, because they improve development for hundreds of our engineers. They give us better code organization, like sub-apps did, and better understanding of what product teams own, which parts of code.

Engines are a new, and for us, a better isolation primitive, because it makes it less likely that we're going to collide with other teams, because our engines own their namespaces. Engines also let us share code between Ember apps, so we can have it running in multiple places with a single source of truth, which saves time for our developers

while giving our customers a better product experience. Ultimately, we hope that we, with enough lazy loading of engines, that the customer experience will be faster when loading Dashboard, because they'll only have to load the pieces that they need when they need them. And engines and their dummy apps make iteration much, much quicker for developers.

Running the Dashboard app or test locally can take anywhere from 30 to 60 seconds to do a full rebuild after making changes. Ember dummy apps and tests can rebuild in three to five seconds, and this makes developers feel more productive, and it just feels better. And in the future, we're looking forward to hopefully be able to deploy engines individually,

instead of requiring a complete deploy of the entire monolith when changes are ready to go out. And this will make it easier for teams to own their production code and not be blocked by other teams. And here we are in 2021, and we have come a long way.

So what made this possible? I think number one is all of the tooling. We used code mods and lints extensively. And lints were especially important because they let us make sure that during migrations, we aren't regressing and we aren't introducing a now bad pattern.

Another thing that was was a lot of time. Upgrading requires attention. We had a dedicated team that was anywhere from three to eight engineers, so it wasn't too big to maintain our app, and it has gotten smaller and more focused over time. And we also have an internal community of developers that are encouraged to work

on these sort of platform features inside of dashboard, in addition to their product work. Another thing that made this possible is Ember's stability. Upgrading and doing this over the last 10 years is part of Ember's philosophy, and that this is a good idea and a good path. Ember doesn't say start over, which is good because we've considered it a square

and we can't afford to start over. And upgrade paths are helpful, and LTS versions are the backstop when we can't upgrade quickly enough. And if you stick within the standard path and patterns, you can leverage Ember for a long time and still have room to explore.

And finally, the open source community. So Ember is opinionated and the patterns are widely used, which make it easy to Google and easy to transfer knowledge between Ember apps. I left after three years and ramped up to dashboard at the beginning of last year faster than my manager was expecting because I was fluent in Ember.

But also I think it's important to note that like, Weirdware is part of the Ember ethos and it's a sanctioned enough path that so long as you periodically revisit your decisions to see if you should change them, it's okay, you know, Ember doesn't want stepping off the path to be a full eject.

But I will say that it's the Weirdware that makes updating and maintenance difficult. But upgrading and reversing Weirdware decisions is possible and we are proving that even today. So today I hope I have convinced you that with Ember you can build for the long term, with Ember you can build resilient apps,

and with Ember you can build apps that evolve. We've used Ember for 10 years for our main front-end project at Square and we have chosen to stick with it. Looking ahead, we want to continue decomposing our monolith into engines and this is gonna require that we finish the Ember model upgrade

and that we move those models then into add-ons that the engines can access and also that we move global values into services for the engines. We're also looking forward to upgrading to Octane and good news, you don't have to get rid of jQuery to upgrade to Octane. But we are actually already using

some Octane features in Dashboard despite still being on 3.12, things like angle bracket components, native classes and decorators, the on and function modifiers, and splatributes. Currently we are not able to support Glimmer components and the attract property.

We're gonna have to continue removing deprecations to get to 4.0. We've essentially silenced a lot of deprecations instead of doing the work to remove them, to fix them, so we'll have to do that. We're gonna continue upgrading our test syntax and we're going to write more TypeScript. And yes, we're hiring.