Architectures for huge Angular based enterprise applications | Manfred Steyer | AngularConnect

[Music] yeah thank you and welcome to this talk this talk is about angular and architecture and as mentioned i am manfred i'm a trainer and consultant i have even a slide for this and i'm doing a lot of consultancy as well as in-house trainings with companies mainly in germany sometimes in austria and other parts of europe i'm also part of the google developer expert program and i'm quite proud of this and i want to start thank you i want to start this presentation with a question who of you had ever the pleasure of starting a new project from the scratch oh nice nice it's a nice experience at least in my past it was ever a nice experience at the first day your project looks like this it is a green field with all those possibilities everything can happen here and then after some weeks it looks like this it is very cute as you see it does exactly what it is supposed to do but after some years it exactly looks like this guy here and now this isn't me at college this is the frankenstein monster you know the frankenstein monster this monster that was assembled of different body parts of different people and this is exactly what happens when we don't care about architecture we are adding one body part after the other one we are adding one use case after the other one we are adding several libraries and perhaps frameworks and maintaining such a system is really difficult and this is exactly what this talk is about in this talk i want to give you three ideas of how to avoid such a frankenstein monster within your projects i will start with something that is quite obvious i will start with nbm packages and then i will move on to the monorepo repository that is quite common nowadays in the area of angular development and as a third point i will speak about micro apps micro apps micro services micro front ends as you want to call them and of course at the end i will give you some guidance upon how to choose the right solution for for your very special needs for your projects and so on so first things first let's start with the nbm package approach the idea behind this is to subdivide a big system into dynabots and each part could be an nbm package that is installed on demand and integrated into your overall architecture and here i have a good message for you perhaps you have seen it since about six months using nbm packages especially creating nbm packages has been built in into the cli using the cli6 and above it's really easy to do something like this everything you do is newing up in your project and then of course you can move into this project and in addition to that and this is the new point you can create a subproject and the subproject here is a library a flight booking library that cares about a specific use case in my overall application in addition to that you can add further applications for instance this playground application here i'm using to test my library to execute my playground application i can serve it with this project switch and then when everything is good i can and she builds my library and this is creating everything you need to publish something using an nbm registry lot like the registry out there or a registry that is installed in your company and for publishing your stuff you know you can't just leverage this nbm publish command you will for instance append your company into handle registry for this it is really nowadays as simple as that in former days it was a bit more complicated and this way of subdividing a project have several advantages one advantage is you can easily distribute your source code amongst your colleagues you just publish it do the nbm registry and your colleagues can make use of it another advantage is you're getting versioning out of the box every time you publish your package you have to assign a new version and so your customers can decide upon whether to go with the current version or with an older version for reasons of compatibility for instance those are the advantages but of course there are also some disadvantages and i have placed those disadvantages on the next slide you can find them here so as it turns out all those advantages are also disadvantages let me elaborate a bit about this when it comes to distribution it is somehow annoying when you have to distribute your source code within one project using an nbm registry just imagine how this would look like first of all as the library developer you would implement your library you would assign a new version you would test it and after this you would publish it to the nbm registry and then you are changing the role then you are the application developer you would nbm install the package you would integrate the package into your application and of course you will find a bug won't you and then one more time you have to switch roles you are the library author again you will fix the bug you will publish a new version and so on and so forth so as you have seen in this little role play it is really annoying to use an nbm registry within one project another advantage that could be a disadvantage is versioning because versioning means that there are old versions out there and this means you can have version conflicts and somehow especially when it just comes to one project you want to force everyone into using the newest version this is not necessarily true when you want to share your source code with other projects but when it comes to one big project everyone should normally use the same exactly the same version and this is exactly where the second approach comes in i want to talk about today the second approach is called a monorepo approach or to say it's more precise monorepos a monorepo is just a folder structure like this that is checked into your source control and as you see here you have a big projects folder and this projects folder contains a lot of sub projects each and every subproject goes in one of those subfolders here that means everything is puts together the best thing about this monorepo approach is that you have this node modules folder here you have only one of those node modules folders it means each and every sub-project is using exactly the same version of your dependencies exactly the same version of angular of bootstrap and of all the other dependencies just imagine what would happen if you used angular 5 here and angular 7 there and then imagine that you are using those sub projects together i guarantee you hell would break loose if this was the case here we are good we are here we are on the safe side because we are forced into using exactly the same versions of all dependencies and this is the first advantage i have here everyone uses the latest versions but not only of your dependencies but also of your other projects because the other projects the other sub-projects are just in the folder next to yours you just have to do something like you know point point slash project name slash this file or that file and you get the newest stuff from the other parts of your software and of course as mentioned we don't end up having version conflicts another advantage is you don't have the burden of distributing libraries you just need to create a new folder and that's it that's really a piece of cake if you ask me and there is a lot of experience out there with this approach google is using it quite heavily facebook is also using it quite heavily and in some areas of software development it is also the default solution for about two decades who of you is using.net or visual studio yeah some of you in this case you know this solution uh the worldof.net is calling this a visual studio solution which is nothing else than a big folder that contains subprojects belonging together or who of you had to use eclipse so far yeah some of you also in eclipse there is the notation of a workspace which is just a big folder with subprojects the best thing about this monorepo approach is that it isn't a one-way street you can move back and forth very easily just imagine this here is your mono repository a quite simple mono repository and let's say the source code here is quite major we've worked on this for half a year or something like that when you wanted to share your validation library with the rest of the world or with other project teams you could very easily take it out and put it as an nbm module into an nbm registry and doing so other project teams or even other people around the world could make use of it to be honest this is exactly how angular is built they are building angular within a mono repository that means they are testing everything together this makes sure that angular 6 works seamlessly with angular form 6 and angular common 6 and angular core 6 and angular router 6 and so on and so forth and when they are done they just publish it to an nbm registry for the rest of us and we are then just nbm installing it so you have all the possibilities even though you are starting with a monorepo structure if you like this idea of the monorepo i want to encourage you to have a look at nx nx is what i'm calling the sugartip on top of the angular cli nx is extending the angular cli with very nice additional features and most of them are quite in handy when it comes to mono monoribus i want you just to see one of those features one of them is a possibility to display your project structure in a graphical way that means you can display which sub-project is accessing which other sub-projects and this is quite important when you want to prevent this frankenstein monster because when each and every library of your system is accessing each and every other library you have a mess you have a big ball of mud because in this case you cannot exchange anything because everything else depends on it it is just one feature that helps with monorepos within this knowable nx toolkit so we now have a lot of advantages we don't have the burden with distributing libraries we don't end up with russian conflicts and we finally managed to subdivide a big project into tiny abouts this is the advantage but there are also some disadvantages and you will find them one more time on the next slide you will find them here so one more time it turns out that all those advantages are also disadvantages because having a lot of subprojects is also a disadvantage when they talk to each other and normally they do and talking to each other is an issue because every time one component of your system talks to another part of the system you are creating a contract and contracts are hard to change if you don't believe me just try it out in the next break just try to change your renting contract immediately or your marriage contract you will find out it is not easy at all changing a contract involves a lot of discussions it involves finding new solutions and perhaps you have to find an intermediate solution it also takes some time to get there to adopt the real world to the new solution in the new contract so somehow this is a pity this is especially a pity when you have several teams because that means those teams need to coordinate each other and that means they have to do a lot of meetings and sometimes you have the impression that you are spending more time with meetings than with producing source code and you know it in big companies this very often ends up in political discussions it is very often about company politics another thing you are decreasing here is maintainability you cannot easily change something because the other team might depend on it and that means that you are ending up just with one architecture and just with one framework and having just one architecture having just one framework going with such a one-size-fits-all solution is really a pity when it comes to long-term projects especially business projects have to be maintained for 10 or 15 years and in the course of 10 or 15 years a lot of things can show up new technologies new use cases and perhaps you need a completely different architecture for the use case that shows up in seven years and this approach here of course is taking out a lot of flexibility and this leads me to the third approach i want to speak about today it's about micrographs the idea of micro apps is quite simple and it is everything but new the idea is not to write a big system instead of this you are writing several tiny systems that don't needs to interact with each other or if they need to interact then very seldomly so you have self-contained systems that can be created by self-contained our darkic teams in the backhands this approach is quite common nowadays everyone is speaking about it they are calling it micro services when you take this approach and put it to the area of front end development you have something like a micro app or micro front ends this is how we are calling it today and of course this brings a lot of advantages we are minimizing the amount of contracts we have we can do a separate deployment as well as a separate development in each order and you can mix and match technologies as well as mix and match architectures each tiny micro application can have its own technology stack and its own architecture or to put it in another way you can use the best technology decisions for each of your tiny applications and now of course the question is how to implement such a thing and one answer would be one answer would be to go with hyperlinks this is the simplest approach and i think hyperlinks are quite a valid solution i mean hyperlinks are here for about 20 years and to be honest i have never ever heard someone to say a bad word about hyperlinks in this case you would end up having several single page applications and they would point to each other by means of hyperlinks this is something like google is doing of course as mentioned google is using the monorepo approach quite heavily but besides this when you look at the google suite you have several applications and those applications are dealing with almost one use case and when you need another use case when you need another application you are following links within this menu here so you could switch over to google docs or do google sheets and so on and so forth the advantage of this is it is quite simple but one disadvantage is you will lose state every time you are moving over to another application you will lose your state and you need to load a new application and this is exactly what we wanted to prevent when we've invented single page applications but as it turns out for some scenarios like a product suite it is a good approach and a simple one by the way the most important aspect of this whole talk can be seen on this slide here i'm putting a lot of emphasis into it namely in germany to be more precise in the country that is called lower saxony it is a federal country of germany there is a village called steyabek i'm so proud of it they have my name in it is someone here from lower saxony yeah i love your people thank you you are the greatest thanks cool so let's go on with the boring stuff uh with the technical stuff when you are doing this approach then you have something like shared widgets you have to care about sharing widgets to provide something like a consistent ui and for this it would be a nice idea to use something like web components and guess what in the area of angular we are happy because we have angular elements and they allow us to provide framework neutral components components that can be used with each and every framework even with vanilla jazz of course sometimes hyperlinks are not enough in those situations you need to provide a shell a shell that is capable of loading other single page applications on demand in this case you will not lose state what do you think what is the simplest but also ugliest solution to loads one single page application into a shell which is also a single page application iframes yeah i don't know about you but every time i'm hearing the word iframe i'm getting this strange feeling in the stomach no just kidding sometimes iframes are just the right solution because they allow you to integrate third-party vendor applications you can even integrate something like um like legacy applications let's say bhp applications or asp.net applications they don't need to be single page applications and they provide a really good amount of isolation that means the application in the first iframe cannot influence the application in the other iframe bugs are isolated as well as the layout cannot influence the other side another approach you will find nowadays when searching for this is bootstrapping several single page applications that means you have one index html and you load several bundles with different single page applications into it hopefully in a lazy manner hopefully you will do it using lazy loading and so one angular application and one angle.js application and one vanilla js application ends up in your browser and for this i have prepared a demonstration let's have a look at this what you see here is just a shell application it's written with angular and the only task of the shell application is loading other self-contained applications into this working area this is what i'm calling my blue angular client i can also load a red angular client as you see here on the next step those applications are really self-contained they can also run in standalone mode that means one beam can concentrate on this client it can do its testing it can do its extensions it can publish it when it's done and after publishing the shell will loads the newest version of it into this working area let's click to payment uh what's what's happened here i promise you i don't know this logo i have never seen this logo before i'm an angular guy i promise you but in my point of view this really shows that we can now mix and max match technologies within one shell application and perhaps someone of you is still using angularjs who is still using angularjs one okay so perhaps uh micro apps are one solution for migrating everything here i have wrapped my angularjs application and i've imported it into my shell what you're seeing here is what i'm calling the macro architecture the overall architecture but of course when you go to the inside of one application you have also something like a micro architecture micro architecture means you are reusing widgets from other clients to bridge the gap and as you see here here i'm using a widget from my green giant and a vanilla chess-based widget as well as a widget from my blue angular client okay so this seems to be quite a nice approach and it has some advantages you're ending up with several small and decoupled projects that can be created with their own technology stack individually and this is about mixing and matching technologies not because we want but because we have to when we think about a software system that needs to evolve over a decade or over a longer time period we have our dark kick teams they can work on their own they are self-contained and we have a separate development as well as a separate deployment and the team can have its own decisions those are the advantages and one more time there are disadvantages and oh meanwhile you know this game those are the disadvantages those are the disadvantages because all those advantages come with the fact that we have to load several bundles into our browser and it also means those bundles cannot be as optimized as with a monorepo because the bundles are created individually that means you cannot have something like overall optimizations like overall tree shaking and so on and somehow you have to take care about ui consistency this is also a disadvantage or let's say a challenge you need to solve okay so far you have seen several approaches to structure a big application to provide this frankenstein monster and of course now the question is which solution is the best for your very needs and the answer is well it depends it is really difficult to find the answer i'm discussing this a lot with different customers and it is really difficult because let's be honest every one of us just wants to have the advantages no one of us wants to go with one of those disadvantages and that's why you will very likely end up in cycles when discussing about something like this to prevent those cycles to shorten those discussions a bit i've created a decision tree of course the decision tree is not the last word on this but it's proved to be in handy to find a first good architectural candidate to find the first good decision the first question i would ask you is do you have a lot of shared state do you need to share a lot of state between your apps and ask the user need to navigate a lot between them if you say no there is little of this you have something like a product suite something like office 365 or the google suite and in this case just start with tiny single page applications with less complex ones and connect them using hyperlinks if you say hey i have a lot of shared state and users navigate back and forth all the time the next question is do you need to integrate legacy applications or do you want to have a very strong isolation because you are integrating third party vendor applications and when you say yes then consider iframes of course you will not win an architectural award with this but sometimes iframes are the right solution especially when you have behind the firewall system this is not the right solution for a public website you will not build the next amazon using iframes of course when you say no i don't need those legacy applications the next question is do you need a separate deployment or do you even need to mix and match technologies do you need our dark kick teams and when you see no i don't need this stuff then you would go with the monorepo approach if you say yes i need this then consider bootstrapping several clis if you say no i don't need this mixing and matching of technologies consider repositories so we are coming to the end of this talk if you say hey i've liked this doc check out my blog i've written a lot a lot of articles about this this is currently one of my main topics and even if you say hey this was an awful doc check out my blog anyway perhaps i'm better at writing than at speaking who knows okay so let me sum up we have seen we can use packages and bm packages to reuse existing source code between several projects and then we have seen we can go with the monorepo to subdivide a big application into dynabars and we have also seen there is this micro app approach and it is about decoupling projects you get several tiny self-contained projects for using packages you can go with the cli6 it's baked in now for using mono reboost you can also go with the cli6 as well as with nx of novel and for using micro apps you have several approaches you could go with hyperlinks like google you could use iframes for legacy stuff you could bootstrap several single page applications one last thing i want to give you please prepare the frankenstein monster within your applications because it leads to a very uh unmaintainable architecture so thanks for coming you will find all my material on my blog have a nice day and enjoy the conference thank you [Music] you

Channel: AngularConnect

Views: 14,724

Rating: 4.9294119 out of 5

Keywords: angularconnect, angular, angularconnect 2018, angularJS, angular conference, javascript

Id: YU-fMRs-ZYU

Length: 30min 41sec (1841 seconds)

Published: Fri Nov 16 2018