 Rydyn nol. Rydyn ni'n gwybod hi. Rydyn ni'n gwybod chi o modd i Uiwn Nogolydd. Rydyn ni'n gwybod hi o modd i ymdrygu o'r tîm pannu cynnydd gyd o'r plwyau tusawdd ar gyfer weithi. Rydyn ni nol byd wedi ei busnes i'r nid o'r ystod. Nawr rydyn ni'n gwybod i'r Ady Appleton. Rydyn ni i fewn i nu ddwy wedi'u Twfyn, yn gallu cofodur y can. Rydyn ni i bobl i'n gwybod i'r hyn i. mae'r bwysig ewn gwahanol yn ysgol iawn. Mae'r bwysig hefyd wedi dweud i gael gwahanol. Mae ymlaen i'w yma, rydyn ni i gael cymdeithasio chi wneud gwych i gocardasio ar gyfer, iddynt wedi wnael grannu nhw, a'r anggl yn Eil's API. Hynny i'n dwylo bwysig y cwbl y mynd, mae wedi gwaith ymlaen a hynny mwyn amddangor o eu rhan o grannu cymdeithasio ar gyfer ymlwg. Roedd eich bod ar gyfer ei gweld, ydy'r cyfan gyda Maen nhw'n gweithio. Ychydig o'r cyfan cyfan gyda'r cyfan, y cyfan cyfan gyda'r ysgrifennu hwn, felly mae'n meddwl y cerdwyr sy'n gwneud eich cyfan cyfan cyfan gyda'r cyfan cyfan cyfan cyfan. Dwi'n dweud yw'r cyfan o'r dashbordd. Wryn o'r cyfan cyfan cyfan cyfan gŵr, yma'r gweithio rhan o'r cyfan cefnogi, ac mae'r cerdwyr wedi'i'r... Well, our application basically, our administration interface for users, this is what it looked like, it was one huge Rails app that was primarily like back-end rendered like a typical web application. And it worked pretty well and it met our current needs but it had gotten to the point where it had gotten into a bit of a mess and we'd sort of designed ourselves into a core and both in terms of the visual design and the user experience but also the design and the architecture of the code underneath it where adding new features had become incredibly, incredibly difficult. And we got to this point where we needed to add quite a large feature and we just couldn't see a way to do it without it taking months and months and months. So, instead of adding the feature, we just chucked it away and started again and built an Angular app to do the same job back by an API. So, before I dig into that, we've got in GoCardless, we have three types of user. We have a merchant who is the person who collects money. So, if you integrated your app with GoCardless, you'd be the merchant, a customer who pays merchant money. And then there's this third weird kind of user which we call a partner which is that there's this way that you can set up an API integration that manages merchants and customers at a sort of higher level. So, for example, we have an integration with FreshBooks, the online accounting people, and they will create merchants and set up the customer relationships and all that kind of thing. And each of these three different types of user have quite specific needs from their GoCardless dashboard and they want to see quite different things. And the reason that we kind of got into this mess with our dashboard being so difficult to change, we figured was that we tried to smush these three different users all into one interface. So, what we decided to do was focus just on merchants for a start because they're by far our biggest users. And we rebuilt just the merchant application as an Angular app backed by a fast Rails API that just talks JSON. And we really did have something up and running fairly quickly. It took us a little bit longer to flesh out all the functionality. But we were really pleased with how quickly we were able to build stuff and how easy it was to add new features. Not to mention the fact that the design in terms of visuals but also UX was much, much better and much more extensible as well, so that was nice. And on top of all that, it actually meets our merchant's needs better, so that was a bonus. So whilst we were building it, we started seeing all these patterns as we were building the application out. So, if we jump back to this first page, which is a list of your payments, there's a filters control, which controls what you see in this main table. You can filter it by date and that kind of thing. There's a little export button over in the corner which pops open a modal and lets you export CSVs of the data that you're showing in the table. A different page shows all of your customers, so you're a merchant you have customers set up. And again, we're able to filter the table, we're able to pop open a modal to export it. There's another control that lets you tab between different views and yet another modal to pop up yet another form. And just to drive the point home again on a page for plans, which are kind of this concept that wraps up a subscription, tabs, modals and so on. So Angular has this feature, one of its headline features is directives. And directives give you a nice way to wrap up self-contained bits of functionality. So you can take, you can imagine the markup that you might need to create a modal. It's like a link and then it's a div and the div contains all of the content for the modal and you need to write the JavaScript to show and hide the div and so on and so on. With Angular you can boil that down into one reusable component and just spit out a modal tag onto your page. And that kind of encapsulates all of the logic for creating a modal, which is really nice. If you've been following along with web components and how they're progressing, it's a really similar idea. You get to put this veneer over the top of all the messy complexity and just reuse it again and again. So in Angular directives you can back your directive with a template and with some JavaScript files that govern how that template behaves. So using this modal example, the template would look possibly something along these lines to begin with. So the link that Toggle was showing and hiding the modal and then the actual modal and the contents. Directives also let you pass data in. So in a similar way to how you might pass data into a function and then the function gets to operate on the data in its own isolated scope. You can pass data into a directive and then it's accessible from your JavaScript that backs the directive and also within your templates directly. So to take this example, we're passing in as an attribute on the HTML element, a link text piece of data with a value add customer. And then if we skip back over to the directive template you can render it out into the page with curly braces a lot like you do in handlebars. Angular's also got this cool feature called Transclusion which the way they describe it in the docs, it sounds really confusing and complicated. And I've heard Ember people, I think Tom Dale who I follow on Twitter, making fun of Angular through like Transclusion and all these obscure sounding terms. But it literally just means that you can put stuff inside your directive tag and then over in your template you get access to it. So what I've done here is taken the modal and completely emptied it out, added this ngTransclude attribute onto, you can add it to any element inside your template. And it effectively takes this and just spits it out inside the element that you have ngTransclude on. So what you end up with is being able to say I want a modal, I want the button to say add customer and I want the contents to be this. And you can just slap it on your page in a really like clean declarative way and not have to worry about the implementation once you've built it one time. Which is really cool and that's why Angular rocks and Ember sucks. Question? No. So yeah, I mentioned at the beginning I started playing with Ember a couple of months ago and one of the things that I, well I started playing with Ember and I started like following along with the Ember community and following some of the people who commits the core and that kind of thing. And one of the things that really struck me was how they all seemed really keen to, like they'll poke fun at other frameworks and that kind of thing, but they seemed keen to learn the good lessons from Angular or Backbone or whatever. And I was looking back through the Git history and it was about June Ember added Ember.component, which frankly is like exactly the same thing, it's just like a web component. And I mean it looks just like my Angular directed from before, the only difference being that instead of spitting out a HTML tag with angle brackets, you're spitting out a handlebar's helper with curly brackets. And it's really cool. You can do, yeah, you can do the exact same thing. And the template looks just like it ever did instead of having a like ng-transclude attribute, you just yield like you do I believe in Ember templates. And I've kind of been joking about how Ember sucks now, but I think the way that Ember approached this is I think they've looked at what Angular did with directives and directives are this like huge solution that lets you do less. Literally anything. The ng-transclude thing that I showed here, the ng-transclude thing that I've shown here, that's actually implemented as a directive as well. So you can have directives that are triggered from attributes, from elements, even from comments if you really wanted to. I don't know. But the thing that I want to say is I think Ember have taken all of that complexity and really bored it down to something that makes a lot more sense for like 80% to 90% of the use cases and just chopped away all of the other weird stuff that you kind of don't really need from the Angular solution. So we built our, back to our merchant dashboard, we built our merchant dashboard using these nice clean like composable chunks of UI. And we got to the point where like you build a new page, you just like get the data available in the back end from some kind of API call and then you just say render a table with this data, give it some filters, give it some mode as well. Like you just kind of chunk this together. It was really, really neat and cool. But as I mentioned at the beginning, we'd only done it for merchant apps and we had this problem of like those pesky users who weren't merchants but also needed a dashboard. So coming back to it, we also need to build a dashboard for customers to look at so that they can see what payments they're making. We also need to build a dashboard for partners to look at so that they can see how many merchants they're signing up, what kind of payments they're putting through and so on. And thinking about the realisation that we had in the first place that our Rails app was a mess kind of because we were trying to serve all of these people in one big application, we decided that we were going to build a separate customer app and a separate partner app. So we were going to support three different Angular apps and they were all going to talk to the same JSON API but in terms of what you load in the client, completely separate. So this is what our customer app looks like. And you can see that it's pretty similar. Like we've got the same navigation along the top, we've got the same tables, we've got the same little drop down thing up here. And when we started copying and pasting our nice modular directives from app to app, we realised that this kind of, it sort of felt like it defeated the purpose of breaking stuff out in the first place. We've got these awesome separate apps that share components and then, like shit, we've got to copy and paste up everywhere. But happily, we didn't. So the way that we got around this problem was by every time that we needed to use a directive which we'd already defined in a different application, we'd pull it out into its own little repository along with the tests that go with it and like the HTML templates, the JavaScript, all that stuff, pull it out into its own little repository and then load it back into the application using Bower, which I guess people are familiar with. It's like a front end package management system from Twitter. So then we've got loads of little repositories on GitHub that just contain the core bits of code that we need to make a directive work. Once you've separated all that stuff out, so we separated it all out for the customer app and then when we came to build the partner app, the final separate application that we needed to build, it was a really, really quick process. It took, like, a couple of weeks and the reason for that was that we were writing this glue code which sort of gets some data and builds the skeleton of a page and then just drop all these directives on, bring them in with Bower, drop in on the directive onto the page and it became a really, really quick thing to do and if we needed to build something else, I'm confident that we could do it really quickly, which is really nice. The other benefit that we saw was that if we found a bug in, say, the filtering directive that filters the table view, you fix it in one place, which is the central repository, you write a test to isolate the problem and then you just go to all your clients and run Bower update filters and it sucks down all the new code, builds it up together, we're using Grunt as well to package everything back up together and it's sort of like, you know how it's really cool when you use NPM with Node and there's a bug fix and you just pull it down and forget about it, you can do the exact same thing with your front end UI components, which was a real revelation to us. So that's what we did and that's how we did it. There were a few issues that we ran into along the way. We ended up creating quite a lot of repositories to the point where we actually split out a separate organisation. Our GitHub organisation is called GoCardless and we split them off into GoCardlessNG and just to drive that point home, 46 repositories we have on there and particularly the merchant app requires most of them and each one does quite a small bit of functionality. So I think probably if we were going to kind of have a do-over, we might think about grouping related bits of functionality together into one package. So say like a whole load of functionalities that maybe is specific only to customers that you want to show in two different dashboards or something like that and kind of I think try and put like a few more things into different repositories. Something else that we didn't do but that I think would work really well is also including the styles for the components. We had HTML and JavaScript but I don't think there's really any reason why you shouldn't be able to include CSS files as well and just like run through and pull them out during your build step. And the last cool thing is that it's allowed us to put all of these UI components on to GitHub. So all of those 46 repos that I showed you a minute ago are all on GitHub, github.com slash gocardless-ng, all open source and all available to anyone who wants to use them, which I think is a really nice little bonus. And that's me. Questions? Yeah, so the question was when we started building the Angular app, did we use any bits of the old Rails app? And the answer is no, we chucked it away completely. Even to the point where we, I said we had a Rails API that backed the new app, that was a separate app as well. It was like clean slate, start again, do it properly. Yeah, because I mean, my experience in Angular was that the first time that I tried to use it, I wanted to add some charts in my little dashboard and that was incredible with Angular. But I didn't want to replace all the information and the handling that I had about the local page, which is just a single page. It's easily made with Rails app and then I was trying to like remember inside a subsection of Rails and those two pieces don't work well together. Yeah. Yeah, so we had something similar actually, our Rails app. One little section of it used backbone to just kind of like try and provide a little bit more structure, which also got quite confusing and quite difficult to manage, yeah. Sorry, could you rephrase that? Do you say how do we manage creating branches for the main application? Yes. So what we do is our application, the Angular application is deployed into a bucket on S3 and then we have Fastly, which is a CDN running on top of that. What we do is every time you deploy a version it gets put into a time-stamped, a new time-stamped bucket on S3 and then there's a ping to the Fastly API that says like stop looking at the previous bucket, start looking at this bucket. And so we've got on S3 like a time-slice version of all the applications. Does that answer the question? Yes. Like how do you pull the components into the apps when you're deploying? Okay, sure, sorry. So we just check the, we run our install, which pulls all the components down from GitHub and puts them into a components folder, which we then check into our repository. So the next developer coming to work on it doesn't have to run our install, it's just, it's all there in the repository, which we've found to work quite well. The next step is the bar. So, yeah, it'll be a brave deal in that one. I did think of my last survey question that is, how many of you have written Angular applications? Thanks, everyone. Thanks again to everyone.