Join our weekly discussion about how to build top end Angular applications and become an Angular expert.
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular–6102018/support.
php/*
Join our weekly discussion about how to build top end Angular applications and become an Angular expert.
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular–6102018/support.
Episode SummaryIn this episode of Adventures in Angular Tomas Trajan, an angular elements expert, breaks down how to use angular elements for the panel. Tomas explains that angular elements are great for very specific use cases. Tomas starts by describing a scenario with a large enterprise with tens of developer teams and hundreds of developers, they have a few choices on how to organize their applications. The first option is a messy monolith. The second option is using monorepos and Nx. The final option is to use a multi-spa solution. Tomas explains how the multi-spa solution works. This solution consists of 80 stand-alone applications, on the same page and share components. Tomas outlines the common problems when using the solutions and how using angular elements combat those problems. The panel moves on to considers how you know if you should use angular elements in this way. Tomas provides two questions to ask yourself when deciding whether or not to use angular elements. The first question is, are you in a multi-spa scenario? The second question is, are components shared across applications? If the answer is yes for both of those questions then angular elements can only help the situation. In last week’s episode of Adventures in Angular the panel interviewed Victor Savkin about using monorepos and Nx. The panel asks Tomas to compare the strategy of using monorepos and Nx to his strategy of using multi-spa with angular elements. He explains why an enterprise might choose multi-spa over monorepos. He also gives the reasons the organization he is working with chose to work with multi-spa. Aaron asks for clarification for using elements in these multi-spa projects. Tomas goes into great detail, breaking down the way multi-spa and angular elements work together. They walk through it together using consumer profiles as an example. Tomas explains that using his approach all the applications update components all at once using angular elements. The panel considers the benefits of using Tomas’s approach and which scenarios it would work best for. Aaron expresses his appreciation for all the work Tomas did and the problems he overcame then bundling his solution in a library together so developers can just use it without all the pain. The library can be found on Github. Tomas tells the panel that there has already been some community contribution to the library. He describes some of the pull requests they have received along with the plans they have for angular elements. The topic turns to mismatched versioning and how the bundle will work. Tomas explains that the only problem they have seen with mismatched versioning is with zone.js. He shares some workarounds to the problem and promises that they are working on a solution. The episode ends with the panel listing all the major benefits that an enterprise can gain from using the multi-spa and angular elements approach. It will save them money, allow teams to work together, create and isolation. Tomas also shares some of the new features available in angular elements today. Panelists
Episode Summary Victor Savkin, former angular team member and now cofounder of Narwhal Technologies Inc or Nrwl, returns to Adventures in Angular to teach the panel about monorepos. Victor starts by explaining what monorepos are and why you might need one. Monorepo style development is when multiple projects developed in the same repository and the tools used to manage code between those apps. There are many benefits to using monorepos as Victor explains to the panel, such as sharing code between apps. Monorepos help you see what's going on in reality as well as helps you take control of the structure of your code. It also allows for more interesting deployment strategies. Victor talks briefly about his time at Google, working on the toolchain and using a large monorepo. After the panel asks about the costs of using a monorepo strategy, Victor explains that there are many perceived costs that are actually false or easily overcome. The first perceived cost he tells the panel about is how people get confused and believe that apps have to be deployed together when they really have to be developed in the same repository. The second is the fear of misplaced ownership, that some other developer will come along and ruin their code. Victor explains that ownership can be configured and controlled so that no one you don’t trust can touch your code. The next myth developers believe about monorepos is that it doesn’t scale and especially when it comes to performance. Victor explains that when the app is set up correctly and testing used correctly this isn’t a problem. The final perceived cost is that Git will break. Victor debunks this by explaining that you would have to be doing extremely well in order for Git to be a bottleneck and even then there are ways around that problem. Victor explains the one real cost and that is you have to change the way you code. The panel discusses a few different coding styles. Victor recommends getting used to single version policy and trunk-based development. He defines trunk-based development, explaining how it works and why it is better for monorepos than long-range branch development. Victor sees two types of groups who want to get started in monorepos and he explains what they most commonly do wrong. The first is greenfield projects who jump right in without thinking about it and eventually crash. The second is teams with a giant app and through a monorepo in hoping it will help them structure their app. He explains there is a right way to start using monorepos in both situations. Asking the important question is how to get started. Agreeing upon the structure, naming, ownership, are you going to build the frontend and backend in the same repo, and the answers to a bunch of other questions will affect your work the most, even more than the tooling you use. Some of these answers will be specific to your company where others will be universal, like naming and ownership. With other tools for monorepo out there, the panel asks Victor why Nrwl decided to build their own tool. Victor explains that the current tools on the market do not do it all. Lerna only does one thing great and Bazel is very selective on who can run it. Nrwl is hoping to marry Bazel to Nx, so they can allow everyone to use Bazel. They want Nx to support all tools and even Windows. The panel wonders if Nx is perfect. Victor explains that it nearly there. Nx is pluggable and easy to use. It is easy to learn. Victor explains that they really care about developer experience at Nrwl. Nx is free and opensource so everyone can give monorepos a try. Resources for learning about monorepos are discussed. Victor invites everyone to watch the ten-minute getting started video on the Nx website. He also lets the listeners know about a new book coming out mid-September and it will be more organizational based than the last. The panel wants to know what comes with Nx. Victor explains that Nx gives you modern tools by setting up Cypress, Jest and other tools for you. Because Nrwl is a consulting firm, the panel hopes that Victor will have an update on the trends. Victor shares his view that trends don’t really tell you anything about the true status of a framework. How many downloads a framework has doesn’t show the longevity of that framework. Frameworks being used to make large scale apps that will be around for years is how you can tell the longevity of a framework. From that perspective, Victor feels that Angular is doing really well. To end the episode, Shai Reznik recalls how passionate Victor was about NgRx a few years ago. He asks Victor if he still feels the same way as before. Victor explains that NgRx is pretty well most of the time, has great docs, is well maintained, and he would still recommend it.Panelists
Sponsors
Sponsors
Sponsors
Sponsors
Sponsors
Sponsors
Sponsors
Sponsors