Power of AngularDart and Trustwave's Customer Portal (Dart Conference 2018)

Power of AngularDart and Trustwave's Customer Portal (Dart Conference 2018)

Show Video

So. That picture of me that was up there before this, started, was back in 2015, when I was lucky enough to present at the first art summit as you. Can see there's not the gray hair up in that picture that is not a direct reflection, from, working on angulardart, it's exactly. The opposite actually so so, I'm Eric Warner I work at Trustwave on the portal infrastructure, and today we're going to talk about the power of angular dart and how we built out our customer portal taking advantage of it so. Let's, go over a little bit at the beginning of what we're going to cover so at first we'll talk about building out a large-scale, portal, and what, that means for trust way portal development, kind of set the landscape, in the view that we're looking at and then, we'll look into what, we were looking for when we went into a new UI initiative. To, get off of our leg legacy. Technology, where we're using then. We'll look at what did we consider, at that time when we were going down this endeavor what was out there what was in the landscape, before we made the wise choice a, picking. Dart and angular dart and then we'll jump into what, we've taken advantage with in dart as far, as building out a base component, for our teams to use to develop with taking. A valley to shelf routing and deferred loading, to lazy, load our portal as it goes through as the customer goes through our portal take. Advantage of UI components, and building those out for our teams to use and then, also the tools that we have taken advantage of and why we chose dart to begin with. So. Trustwave portal development, we have a large-scale, portal that we build that, has about 15 distributed, teams that. Is about 50, plus developers, that are divided, across these teams and they, build about 35, different applications. That, take advantage of a thousand, plus Java services that we built on the backend using spring some. Of those are part of our portal infrastructure, that we build out but, a lot of them are from our product service teams for the the services, that need to support the views that are built out for those products, we.

Have 40,000. Unique. Global users that log into our portal, one, portal, on a daily basis so all this is brought together from, our team development, that takes place and we, got to make sure that we bring it into one build and leverage. Whatever technology, we're using to build out some sort of framework that the teams can take advantage of. So. We'll, go back a little bit it was 2013. We. Had a legacy, portal that was built off of using, flex with flash and we all know what's happened with flash it's died it's dead the browser's, have caught up with what we, could take advantage of at that time it was a good choice back then but. The browser's have caught up so we were looking for what's next what are we gonna go to so what, were we looking at at that time there was you know the team development II had to take advantage of but we also had to look at new requirements, coming in so. We wanted to make sure that we could build out a portal framework and that for our customer experience when they came to our portal I had a quick initial startup time we didn't want them sitting there and waiting for the, download to take place we wanted it to pop up quickly for them that, means also we wanted to lazy load our portal the, teams as they work on these views that they're putting together for their products, we, don't want it to download all at once and have this big memory footprint, within the browser we, want to incrementally, grow, the portal as a user goes through it we. Want it to be fast rendering within, our UI components, so there's not a lot of waiting for the user as they click through and we want to take advantage of something that we call in the past deep linking where we could send, URLs. To our customers, that they could click on and go right to the area within the portal so they don't have to log in and dive in from there and also that they could bookmark, these URLs to get back quickly to the area they wanted to go to within our portal. Then. There's a team development, that we've discussed previously we. Have a unique, look and feel that Trustwave that we go off of for, our portal, so we want to make sure we have a set of shared UI components, that the teams can use that. Are built in a consistent manner with, the proper styles so they don't have to worry about that when they build out their products this, goes along with also a base component, that they can leverage and use as well that, they can rely on that's going to build in and bring, in services, for their for, the base things like security and locale information, that they don't have to worry about on their side so they can concentrate on their product we.

Want To have quick, dev cycles, we want to have our developers, be able to make. Changes, see, it in the browser right away and not have to wait for some compile step to take place before they can see what their change was so we can deliver quicker a short. Learning curve was something that was on our list as well we. A lot of our developers are both you. Know back-end, developers, and then we have purely UI developers, but most of them work full, stack development, so we wanted to make sure whatever technology we picked was. Intuitive, to them and there was a short learning curve so they could come up to speed quickly and start building this out and then of course testing, involved in it the components, we build on our team in the portal infrastructure, we want to make sure we can test them so we supply out good components, for our teams to use and. Then you look into the tools that need to come with this as well if we have this team development, we need to make sure that we can have core sets of libraries, and we, can bring this all into one build that goes out so we need the dependency, management on top of it a good, IDE. Integration. And then be able to do continuous integration builds, out to our test areas, with our DevOps team and then product teams to production. So. Back. In 2013. When we looked into this you can see there's just a plethora of choices out, there that we can pick from so. You most of these are JavaScript. Frameworks, and that, right, off the bat kind of made me sick to my stomach a, little bit when you look at the team development, we were doing and trying to bring this together and then, also you know there was GWT, at the time and we could have gone backwards, and went that way but we wanted to pick a technology, that was gonna stay in the front and keep, up with the times and always increase and get better and better and something, that we can stay out of the spaghetti code land of JavaScript, we're, building, that bringing that into one building going forward just made me kind of just quiver a little bit. So. Say hello the dart and angular dart so, it's back in 2013. Again I keep going back in the time machine and we're sitting there and we say hey look, at the dart SDKs out here let's check it out so, what we started doing is some prototyping, and then, we started doing some brown bags internal, with our engineering, teams and we are building just some command line talking to WebSockets and bringing it in this was even before the the, packaged, HTML, was out there for building any type of UI so, what did we discover, at that point well, we discovered that this is a complete. SDK, with a core set of libraries and tools that, we can leverage for, building out our portal. Going forward, it was very its, supports. High quality tools large scale like I said and then extensive, libraries, that were out there that we could pick up from other people that are contributing, third-party. Libraries, so. This was something that, I mean from a background that we have some Java developers, or no matter what software language you were coming from it was, we were getting feedback through, the brow it's like this is very intuitive for me it's I can pick this up very quickly and it has everything that I've leveraged in the past in other languages, and I can take advantage of it and I don't have to play around in the JavaScript, land on these things as. A great cross-compile, over to JavaScript it's like oh that's great because we got to make sure that we can support all the major browsers that are out there and then, the the one that really sold us at the end is when the switch came in dart to go to strong mode we, were already building out dart to be very strongly, typed for building, with the other developers, that were use to this from the languages they've built in the past so, when dart made the decision, to go full strong mode it just hooked us even more as we started going down a pipe and those announcements kept, going and it was evolving, over so, now that we picked the dart SDK we're, like okay this is what we're going to use we, still needed a web framework to go on top of it so, we started looking into angular all the way back at angular 1.0, and that's the initial prototype and actually the initial portal that we were launching internal, that we built off of so why did we like angular so much well, this, is just piggybacking, off of what tom was talking about earlier is that based, off the templates, and the event bindings, events.

And Binding is the routing dependency. Injection, from everybody. In our company that's worked on services on the back end it was all within job and spring so they understand, this - a dependency, injection, and the power of it and then, pipes and then angular components, was announced. Last year and came out and it's like great, now we have a core set of libraries we can share so, we've watched angular, evolved, from 102, to getting. Broke off to being internal, to Dart and getting off the JavaScript, builds and we've seen over time how, it's increased, Co, sizes, shrunk speed. Of download has gotten better and better and we've, seen the improvements, that we've built at our portal so, we are very happy at this point the decision we've made because it's made us very, quick, and up to speed on where the browser is going and also being. Able to leverage using. Dart angular dart to meeting our requirements. So. Andrew, is a developer, that's on my team on the portal infrastructure, side and he, came to us from a JavaScript, background in a dotnet background. And he. Was able to pick it up and come up to speed very quick, he discovered, that he's not battling, things that were in JavaScript, before but dart just coding it worked, the way it was supposed to work out of the box so. This, is just proof, that he. Came in he got up to speed he was delivering, components, that were production ready in about two to three weeks and our, teams were starting to use them so, it's a very nice language they can come up to speed very quickly, and. Then Keith is on the other side and he's been at Trustwave for years, all the way back to our legacy portal and he comes from a Java background and, on, the Java side is the same type of experience, it didn't matter what type the software language background, you were coming from picking. Up dart was intuitive and quick to pick up and you can deliver quickly. So. Now that we've, decided on dart. And angular dart we. Also during this UI initiative, that we were going off we wanted, to rethink, our portal, design our. Legacy, portal was built off with the concept, of each. Application, was, its own module that would load in but, we wanted to break this down, to our customer, not by what products they were provisioned, to but, more intuitive. Looking, areas, within our portal in that top blue area that, they are accustomed, to across their products so. This is just a small subset at the top of the blue area of like home assets, buying support, that. You can find at the top of our navigation, below. There depending on what section you pick, you, would get a set of menus this, is where a user is provision to certain, based, off the products they have what menus they will get so, our portal kind of grows for them as they log in so they could just maybe have home in assets or assets and findings and the menus that are underneath there from. There of the user clicks on one of those menus, this. Is where the team development, comes in that the product team is built one of these elements and it loads within the stage from that point so, this is the vision, that, we had going, forward when we wanted to build out this new UI and the approach that we wanted to take so. How did we use dart. And angular dart to achieve, this vision that we had. Well. First thing it came down to was building, a base component. We, needed a contract, with our development teams that we knew when this component, loaded in we, knew how to interact, with it, also. This base component, needed to make sure that it took care, of some of the base, lifecycle. Events and we can hook into them for, loading things for the user such as locale, information. Because we're a global company or, security, information or, security, or properties.

Information. We, didn't want to have each one of these development, teams doing this on their own they, should just concentrate on the product that they they, build out and this has always been our vision of how we build a portal infrastructure, so. Within this class that we built out this base portal, component, you, have it, implements, base, angular, lifecycle, events, with. True inheritance that comes with since the angular 4 came out with components now. Teams don't have to worry about implementing, these lifecycle, events they. Can still get hooks in them but we, wanted to be able to have this in the base component so we can tie into them so, you look on the ng on an it override, that we have this, is where we load in locale. Information, that's been specified by the implementing, component, security. Information and properties, information, and then, based off this component, I'll show on the next slide they have hooks into when this information, is loaded so they can react to it within their implemented, view also. Within here we have a component. Service, taking advantage of dependency, injection, this. Allows us on this component service it binds multiple. Services into it so then its dependency, injected into our base component, for things such as routing, and other, services, we need to call an our base component, so. Now we have this base component, ready to go the teams can implement and go from there and they can rely on knowing, that they have this base functionality, they can take advantage of so how does a team implement. This so. Now the developers, teams basically. Extend. Off of the. Base portal component, this is an example from the asset search component that, we have within our portal so this is a menu of a component that would line up under the area of assets. And. Within here we still do the dependency, injection of the component service so it can get to the base component. So it has a handle on it but, then you look at three overrides, that were within, this class of the implementation, you, have on locale loaded on security. Loaded and on properties, loaded so, the one we're going to look out specifically, is the implementation, under security, loaded. So this function, is going to be called from, the base component once, the security information is loaded for this component so, this team that's developing, this view can, rely on at that point hey I need, to check a permission, on a resource, and whether they have the execute, permission for the search button it, is permitted method comes off the base component as well so they don't have to be looking through that cache to find that out so, now the team can rely, on hey let me do that check for that resource. Tie. It to a boolean that I can tie it to my backing HTML template, with binding, and that buttons, gonna be enabled or not now. We have this base component, we know how to communicate with and we know how to it's, got a contract, within our portal framework so, now our teams can build independently, and know, when we go to the main deployment, and goes out that components, gonna work correctly. But. They built it out now how how do we go about loading, it into our portal and also, initially, I was talking about well we want to make sure that we keep the initial download, time. For our portal very quick and we want to lazy load things in well. This is where we take advantage of routing and deferred loading within our portal so. At the top URL, there you see this, goes into our production environment and you have the bolded assets, first that ties to the top menu area so that means when that route comes in whether, they clicked on it or whether there was a bookmark, it's gonna highlight, the, blue assets, area at the top that has been selected from.

There We need to know well what's the menu underneath, that area that we want to go to well. It's the search area for the asset search that's where the bolded area on the on the the, end of the URL is so, no, matter how they got to this destination it routed to this area within the portal now. This search is, tied. To a specific element name, that's been developed, by one of our teams and that's, how we determine at that point Wow ok we have this element we, need to put this on the stage but we want to make sure when we load that in that. It's just not already in the in the JavaScript. File that's initially downloaded. We want to make sure we load that in at the point that the customer. Or user wants, to access it so that's the point we want to defer load it into the element stage. So. How do we do that so. This comes with deferred loading so. The first thing you're going to see it is you're going to import, in your. File that the asset search component is within, but. I'm not importing. The asset search file I'm, importing. The template, file, that's. Not there until it goes through the compiled time step so this isn't here during development time but is there at run time so. We want to make sure that the first comment, at the top of this file this, is just basically telling the IDE and the dart analyzer hey, ignore. This I know it's not here at this point so don't give me a nice red squiggly, underneath it ignoring. It's gonna be there at runtime. But. Underneath there you don't just import this as a regular library we, wanted to furloughed, this in so we want to make sure that we're telling the compiler that hey don't, include this in the main JavaScript, file create. A part file that can be loaded in during runtime when it needs to be accessed so, that's where the deferred as and, we name it off as asset search view. So. Now we have it deferred, but. Now we need to make sure how do we load this in using angular and make sure it shows up in the UI when we go through well. The next point that we have in here is we have an app view child annotation. That's basically saying I'm looking for a marker in the back HTML, to a named. Element called stage and I want to bring in that in as a view container. Reference, and I'll call that stage so, now I just have a hook on an element in my back in HTML, and this is where I'm gonna load my component, next to at this point, next. I got to make sure that I have the component, loader from angular dependency. Injected, with into my stage component, here so. I make sure that there's dependency, injection bring it into loader so now I have a handle on the loader so. Now just real quick I should have said this in the beginning this is really shrunk down just to show the relevant pieces there's other things that go on but I just shrunk this down to what we need to show to to, to. Have an example the deferred loading so, the next step is there's this load view component with the element, so when the menus clicked on I know what the element name is and usually there's a bigger you know case, here switch case to determine which deferred library and I'll load in but, I already know here so I shrunk this down to, loading.

Into Asset search view so I need to do an async await at this point and a wait for loading in that library after, I have a handle on that library I need, to emit the reflector, which is going to tell angular. To. Make sure that the component submitted so that I can get a handle, on the component, factory at the. End of this statement I get a reference on NASA's search view with asset search component, with the bolded NG factory at the end I wanted to highlight that because that's another area, that's not there during development. Time but will be there during runtime so. Now you have the handle and a component factory it's been deferred loaded I have to handle it on it within my backing to our class but. Now I need to call the loader and make sure it's instantiated, within the UI so, now I load next to the stage component, this component factory. Boom, there you got it it's loaded, into UI for the customer, so as they've gone through our portal, it wasn't. Loaded until they went to that area so, that means the customer can bid and provision, for many many different views within our portal but, we're not going to download that into the browser and during, the time I've have that memory consumption until the user wants, to go to that area. So. What does this look like after it's gone through the dart2js compiler. Well. On the left side you see without deferred, loading you, have one monolithic huge. Javascript, file that, means that every component they've been developed, by our teams is in, one file and. So at the beginning of the portal loading for a customer to be one down load time there's a little little. Spinner that shows and they're waiting and they're like hey can this portal load no we want to keep it small so on the right side you see it's broken up into many many, many different part files those, are different part files from the deferred loading as we import these in so. This means those aren't going to be loaded into the browser until, the user navigates to them. So. Tom Smith has been with us since our legacy, time and is he's just stating here he's how, great it's been to leverage the portal components, that we developed within our portal taking advantage of angular and it's it's made it easier for our teams to work. Independently and come up to speed quickly and, know that things are gonna work within our portal framework. So. Now that the teams have this base component, what, about the. UI components. That they need to use I mean they have the base component but they still need to build out the HTML that's gonna render to our users, well. We. Have taken advantage of angular components, and built. Out our own core, package, of it's called UI annular, that houses all of our components we've, extended, off of angular components, because it's very easy. Take advantage of different utilities, they have and also extending, off adjust based components, to adding more functionality, that we needed proprietary. To Trustwave, also. We have our own unique style, at Trustwave, and angular components, is built off the wonderful, material design but we have our own unique style at Trustwave so, it's been really easy for us to put our own styles, on these components as well so. If you look on the right side this is just our demo. Project, that we have internal, at our company that's, just running through all the, components, that we've leveraged. And take advantage of and this, is adding our own styles, on top of angular components, in some of our own custom building components, as well. But. What a what if in your company there's already a JavaScript, library you have because you're converting over from, JavaScript. To Dart or there's a library out there that you want to take advantage of that's. Not already been ported over to dart or angular Dart, well don't worry you, can still take advantage of, JavaScript, Interop so, you can use JavaScript Interop. Build your own angular, dart wrapper around it using that facade that you built out and take, advantage of that javascript, library so, we've done this for two of our components, for charting and for our rich text editor and this. Is our portal, live in production, on the right, side they're an animated gif that we built and that's showing our main dashboard use. Taking advantage of high charts, through. JavaScript, interrupt. But.

Also We're looking for that again we're saying we want the tools IDE integration. Well, you. Get now with the dart plugin with an IntelliJ, and we, take advantage of intelligence, we're also a java company. As well for our back-end services, so now our developers, can work within one ie within, IntelliJ. On both, dart and on. Our Java side we get the code analysis, the code completion the refactoring I wasn't. Able to build a real complicated, gif on this side because recording, myself coding, just didn't work very well but, this is the dart reformatting. That takes place the dart formatter, and I. Have, to say I love the dart formatter coming from the Java side and all the battles and arguments, over formatting. And going, back and forth it's really nice that dart comes out with just one formatter, and you can tell the teams there's. Formatting, already, within stick. With it we're not going to come up with. Now. The teams have built out all these different packages, and we talked about earlier it's like well we need some sort of dependency management, to bring this all together well. This really sold us using dart as well we, have our own internal pub server that, we publish, all the core packages, up to that the teams can take advantage, of and they also publish, their views. Up so we can bring it into the main build that want to talk about later on so, we've fallen in love with the semantic versioning and that takes place that Kevin. Was talking about earlier we. Use the current syntax, on it and we avoid a lot of breaking changes and conflicts, that come in so, on this slide here is that it's just an example pub spec yeah Mel that shows the URLs of our internal pub server that would take an advantage of to bring in some, of our core packages, to one of our component, libraries that we build up. Now. We need to bring it all together okay, the teams have worked on their views and we need to bring it into one, main build so, on the right side is, our. Main, pub. Spec gamal that's in our main build I think. It's about 35, plus packages, that we pull in from our main internal, pub server into one build so, our teams can work independently, they, can publish off their packages, and no one we build this off we pulled in with the semantic versity and make sure we pull in the, proper version from our teams this, avoids breaking changes so because we make sure we handle the versioning correctly, and if there is a breaking, change that comes from one of our core components, we make sure we notify our teams at that point. But. We also need to make sure we have automated, builds, we, had this in the past and we wanted to make sure we could do this with dart as well so, we use Jenkins, as our, continuous, integration build, server and. We have built off a process, within there that, runs two, to three times a day on the, main portal framework build so our teams can make sure they deploy their packages, it'll be brought in and go off to our test networks so.

On The right shows our main build and this, is going through at first a pub upgrade to bring in the new packages, does, a pub build after that, point it goes ahead and tours up the entire build sends, it off to our internal nexus server and then, our devops teams pick, it off from there and, deploy it off into our test networks so, really our hands, off at this point so, our teams can work independent, of the portal framework and they can rely on knowing, that this is going to go out into the test networks on top, of that we, have we added some traceability, into this automated build in the, backing HTML, we put in when the deploy date was what the version went out so. That our teams our development teams can say hey did I make it into that deploy we, also put, out and only our test network deploys the pub spec lock file so they can look at that out there and say oh man I didn't. Make it I missed it this window but I know it's gonna be in the next window my newest version. So. A trust wave we are extremely. Happy with our implementation, of angular Dart in Dart we've been internal, at the company for about, a year and a half internally. Using, our portal we, went beta at the end of last year and I'm happy to announce this quarter one we have gone GA in front of our customers, it's. Worked wonderful, for us. And we're looking forward to coming up soon with. Dart, too and also. Angular 5 the, dart dev compiler we want to start using to get out of using dartium, and going straight into chrome and with the dart dev compiler and this. Quarter we're starting to develop our mobile solution, within flutter so we're going to take advantage of our middle layer our, business layer and we have a core packages, to take advantage of those core services on the backend and just, focus on the UI for our mobile solution. Thank. You.

2018-01-28 03:27

Show Video


I'd also like to see James Damore.

What is the difference between Angular and AngularDart, excluding the TypeScript/Dart difference?

Congratulations Eric! Very nice presentation and work!

They started from the same source base, but the code has diverged quite a bit in the last 2 years. We've had a big focus on move towards features that improve size and speed (and deprecating/removing features that hurt size/speed).

Yup. They look a lot alike now. They will remain so for a while, I'm pretty sure. But the feature sets are diverging.

I see, so going by what you just said, this means that the feature sets of both versions(forks?) of angular are different too, to an extent?

Other news