> Hello, everyone. Brandon, are there? Yup, I'm here. How you doing? I'm good. We made it. We're
here. We are fashionably Yeah, fashionably right on time. Well, welcome, everyone to the anywheres-ever NxConf.
I can hear applauding over the livestream. Let's check the Slack channel. Stream is live. Yeah, we were ready to go about an hour ago, but Brandon had to go put makeup on. That's right, I mean look at this face, I have to get, it takes a lot of work to look like this, so I had to do my due diligence. Mm-hm. But we've got 90% of the technical kinks worked out so we decided to get started here and we've got a few things to go over before we jump in. First we want to say thank you. Thank you to everyone who's attending and made time out of your day to come be with us today and see some great talks, and have some fun, hopefully along the way.
Yeah, also want to say thank you to all the people who submitted talks, lightning talks, we got a bunch of awesome talks, and we hope to see some of the talks -- the extra talks that were submitted given in future conferences, or future areas, so looking forward to that. And then we want to say a special thank you to our sponsors. If you go to the next slide, Brandon. Jeff: Thank you so much to our sponsors that made it easier for us to do some great things, like paying speakers, getting live transcription for the event, getting high-quality video editing, and production. So thank you. I'll say each one individually, thank you, Nrwl, of course. They
keep me in business. They keep my mortgage paid. Thank you, oasis digital, great fans, brain brainl y -- Cisco, I'm not going to say great things about every company, we got to get going. Ionic, thank you, thank you so much for the support. XLTS dev, thank you, Frosty, same with hero devs, and thank you all for being part of this and helping us to put on a great event. Brandon: Yeah, like I say, we got a lot of support, sponsors, attendees, everyone. It's all around and we really appreciate that.
I also want to mention the hashtag for the conference. If you're on Twitter, you're living that Twitter life, use the #NxConf2021 hashtag or whatever your social media of choice is, be share to share that out. So people know where you are. Jeff: I'll go to the next slide so people can see the hashtag. There we go, #NxConf2021 Brandon: Yeah, we got it in big bold there, so you won't forget it. You know where you are, but other people need to know where you are.
Jeff: If you tweet it with NxConf 21, no upwill know where you are. It doesn't work that are. And importantly, we have -- before that, we have our Slack channel.
If you want to talk with other folks during the conference, engage with speakers, organizers, attendees, attendees join the Nrwl community Slack. It's a great place to ask questions of other people, get ideas, but we have a special channel just for the conference, called #nx-conf-2021 and that's kebab-cased, that's what we agreed on, right? Brandon: Kebab, snake, describe that. That's the Slack. Join that channel, and chat with other folks attending the conference. And finally, we have our Code of Conducts, and this is something we take really seriously at Nrwl, we want everyone to have a great time.
Even though this isn't in person, we're all in the Slack channel together, so it's important to be mindful of other folks and not make anyone uncomfortable, not harass anyone, not make inappropriate jokes, we've defined the guidelines for what behavior is acceptable in our Code of Conduct that you can visit at this link below, and we'll be enforcing that in all the interactions with the rest of the conference. Now, Brandon, I'm going to duck out so I can make my grand entrance for my keynote, OK? finally, thank you. Appreciate it. All right, and with that, we just got me now, so here we go. Want to welcome everyone again. While Jeff gets ready, I'll just introduce, you know, the founders of Nrwl and creators of Nx, Jeff and victor who will be giving us our opening keynote that talks about where Nx is today, the future of Nx and I think with that, we'll kick it over to Jeff and Victor. Jeff: Nx.
I'm Victor -- ... (Entrance music) [applause] [cheering] Jeff: Hey, everyone, welcome to NxConf. Hey, Victor, are you there? Victor: Hi, everyone and welcome to NxConf. Jeff: I'm Jeff Cross, cofounder of Nrwl, the company behind Nx. Victor: I'm Victor, I'm a cofounder of Nrwl and I'm an Nx and NxCloud architect. We're so excited to kick off the first-ever NxConf today.
[cheering and applause] Nx is four years old and today we want to celebrate how far Nx has come in four years, we're not going to spend too much time looking back, but we are going to take a look back at how far Nx has come, what Nx looks like today and how it's still evolving. Let's start with Nx evolution and that's my pig, Cheddar. We announced Nx the first release at a case called Angular Mix in 2017 in October. And originally it was a tool for managing large codebases with large teams with multiple Angular applications, or mono repo is another way of putting the focus. Since then it's coming a long way from being an original tool for Angular apps it's now an extensible build framework and the secret to Nx's success is we don't build it based on second-hand guesses of what our users need. We actually build it from the pain that we experience from working alongside our enterprise clients to build applications.
Which explains why 48% of the Fortune 100 companies are using Nx. We want to look a little bit at some other metrics of note. With some caveats that we're not trying to brag about how amazing Nx is.
We're trying to make it clear that Nx is a solid tool with a thriving community and you should feel safe betting on Nx. If we get any credit, it's that we started Nx and we maintain the core of it, but the growth really has been because of the community around Nx, people contributing to it, people building plugins for it, and people using Nx. Another caveat is that measuring open source is hard. Anyone can download Nx and we don't have to know about it, so we have to look at some of our internal data, as well as some externally available data to try to paint a picture of how Nx is growing, what that growth looks like, who's using it and we'll share some of that in these slides.
So fortunately, there are few indicators to understand how Nx is growing. One thing we measure traffic to the Nx docs on Nx.dev. Now, in this chart you can see that in June we had 57,000 unique users, actually more than that in July and August. A lot of that was traffic for the conference, so we stopped it in June to try to be honest about how much traffic we receive normally. And that's great growth, we want to see that up and to the right. We also don't want people to have to visit our docs too much, so we want Nx to be intuitive, so we don't try to improve this number.
It's just a number we look at in terms of seeing a trend. Another metric we look at is monthly NPM installs and this is another thing that everyone installs their dependencies differently, so we don't look at this as a way of saying these are how many people are using Nx. We mostly look at it in terms of seeing trends in growth and as you can see, Nx has grown quite nicely and the past month, or in August, it was installed more than 2.
4 million times, which is almost a 4X increase since last August, so in one year we've increased the downloads four times. In 2014 we focused on adding more ways for Nx to get easier for local builds. Nx is already good by for rerunning the tasks that only needed to be run, which saves a lot of time.
We trod a mechanism called computation tasking, so you could record tasks outputs locally so saving potentially many minutes or tens of minutes on certain tasks, which combined makes a big difference on the amount of time spent running builds and tests. This had a huge impact on build times for the teams we worked with. But while computation caching made a significant difference in each independent environment, we knew we could significantly increase the frequency of caching and so we created NxCloud and launched it in April of last year, 2020. It's a SaaS product but people can use the tools even if they're not paying for the product.
And we're happy to say that because of the free utilities and the things we've done to make it easier for teams to adopt it and to subscribe to Nx Cloud, we've seen quite a tremendous growth since last September, so we had 3K connected workspaces then and now we're up to 24K. Some of these are paid, some of these are not paid, but we like to see that -- our goal is to have Nx Cloud make sense for every workspace, we're happy to see so many workspaces taking advantage of it. I'm not going to go into too much detail, but Kirils from Nrwl is going to talk on Friday at 3:00 eastern. The success of Nx is credited to the developers using Nx, as well as the developers contributing to making the Nx ecosystem thrive, and this starts with the Nx Core Team.
On the Nx Core Team at Nrwl has grown so much in the past few years, we can't even fit them in one slide, unless we make them really tiny and then we can fit them. But we're pretty proud of the team we've put together, but they're only one part of the picture. It takes lots of people to make the best framework on the market, and in fact, we have on the Nx repo itself, we have over 176 contributors as of today. We want to say thank you to everyone who submitted code, created an issue or helped make the Nx docs a little bit better. And you can show your support by giving it a star on GitHub. Go
ahead, do it right now, I'll wait. OK, and of course we couldn't call Nx a build framework if it wasn't extensible. In the past few years the Nx Core Team has spent a lot of effort to make it more accessible so the community could build great plugins, the same as the first class plugins we built and the community has definitely stepped up and made a mazing plugins. Over 40 different plugins for different uses and even different languages. You. Now I'm going to pass the baton to my BFF Victor Savkin who's going to show Nx today and what it means to call Nx a build framework. Victor: Today I want to tell you what we mean when we say Nx is a good framework.
Then I'm going to talk about Nx, the core, plugins, integrations and finally I'm going to tie it all together so hopefully it all makes sense. So what is good framework, right? Let's look at those common goals. Some of them are centered around technology.
Things like dev setup with a build system to be fast and generate no waste. If you don't have to do something, like you already know that it's not going to be successful, then don't. They want the system to be stable, no flaky tasks, things like that. They want to be able to integrate different technologies, right? Tools, languages, frameworks, and again it's not as easy as just putting it all together.
The harder part is staying up to date with it. Like evolving your system as those technologies changes and they change at different rates and those teams don't talk to each other all the time, so it's actually a harder problem than it seems. They're also like team-centric, you know, like consistency, best practices, you want to make sure different parts of your application looks that you follow the best practices of your community or your organization. You can create new artifacts with relative ease.
you can refactor things and here I don't mean renaming, a field, what I mean is you have an old version of the API and you have a new version of an API and you want to transition the systems from the old one to the new one gradually without breaking anything, that type of refactoring. And of course you want to have developer mobility and collaboration. As a developer, I should be able to move one part of a project to another one and feel right at home. Know how things run, how I can run it, etc.
And also as a backend engineer, a designer, I should be able to work together and feel that we can communicate with each other more effectively, right, that we talk about the same thing. So some of those goals are more important for the green project, smaller systems and startups, some of them for larger systems, enterprises. But they all matter to everyone, right? Is just to a different agree.
That is why the whole point of separating startups and enterprises I think is bogus, right? Most teams kind of desire the same thing, it's just the priorities can differ a little bit. What's interesting with that, all of those goals, aren't just build tools, right? These are goals for all DevTools. VSCode for example is a good answer for them, in the editor ID space, right? The code scales with the size of your projects, and is fast. It provides plugins for different technologies, gives you integration, refactoring technologies.
And they can go from one project to another one and still understand what's going on. Frontend and backend engineers can work together, using the same tools, right, and which increases collaboration and they can feel productive. Right, so what's important in here, that VSCode gives you all that with this architecture. They give you a small and simple core, but most of what you get from it, you get via plugins, so you take a bunch of plugins, you compose them, you install them, you configure them, and that is your custom edited experience. Many of those plugins are still plugins, so you can assemble a fairly custom edited experience with VSCode without having to script anything, right? It's not hard to assemble custom experience, like if you were an E lisp user or -- you can offer a lot of custom stuff and have a very unique experience that only you have. But not a lot of people do that.
costly to maintain this. You don't want to architect your edited experience in addition to architecting your system, right? So our Nx is like a VSCode for build tools. So we share the same philosophy. When we talk about build framework, this is what we mean, right? We don't main Angular or Ruby on Rails or anything like that, there is no library versus framework, anything going on here, right? A build framework is simply a set of building blocks you can use to create your custom, dev build setup that mediums meets your needs and the needs of your organization, but in the same way in a way that you don't have to architect the way you build framework from scratch.
You can assemble your experience, that's what Nx is trying to do in the sort of build space, right? Great degree of customize ability and easy to use. see what I mean. Who components does Nx give you so you can achieve that. So there are two three main sections of Nx that I want to talk about. There are plugins and integration. The core part is the CLI with all its core capabilities. Let me cover some of them, right, or some of the ones that we are are worth talking about.
Nx knows how your projects relate to each other, what depends on what, without your having to tell it. No bugs JSON files, etc., right? Nx can look at a lot more and do it more efficiently, right, faster, and as a result, the graph, the project graph it gives you is more granular, is actually more representative of the actual dependencies, right and it works with our technologies, as well. With Java, etc.
obviously you don't have to use JSON files. Is and it never builds tasks or does the same thing twice. It works across machines, CI or dev machines, right, meaning that the CI machine computed something, I can get the results of that computation locally, super-fast.
And it's sort of hard to describe it, right, without showing, but we tend to a lot of small details, for example, correctly in particular on Windows, right? We are able to show you from cache, the STDR that looks exactly. It's much harder than it seems. Next, Nx supports code generation, you can create new artifacts, libraries, components, etc. And that's not that challenging. It also supports code generation that I talked about before. Make it work well, Nx comes with a virtual file system that tells you how to write really, really powerful code and I'm going to show you some of that later on. It works with previews, with dry runs, it's integrated need tors, it's much more powerful than what we see normally, right, in systems that support code generation.
Nx supports distributed task execution, which means that Nx can take a command, any command, and run it across multiple machines, but providing the dev ergonomics of running a certain machine. So dependencies between tasks, I respect t you know, it's all working fine. If you run a command, Nx can just take that command, run it on 20 machines, and those machines will share files, do whatever is needed to make sure the command succeeds, right? But the result is you as a developer see all of that as if it's one machine. I'm not aware of any JavaScript tools that can do that.
There are heavy duty tools like Basil that can do that, they're hard to use, so no one in the JS space uses them, right? Once you have that, you can scale your workspace to a much larger degree, right, and the more things we see, is a basic -- and that stops working very quickly, right? Finally, Nx can look at for example the pull request and it can figure out what might be affected by this change. Right? What projects might be broken, etc. , such that you can only test or build that section of the workspace, instead of redoing everything, right? So, now let me show you how to use Nx core so you can see it in practice. All right, let's create a new Nx Workspace using the NPM preset and the preset is sort of analogous to plug and play. Let's have a look at JSON, just a few packages.
I can generate a new project and here I'm using the NPM package generator to create something that I can use to create anything, right? I can see the preview of what would be generated in the bottom. Now let's look at the project, it has a JSON file with a test script, right? If I run it, I will say, Hello World and internal it. Get the computation caching for free, we didn't have to configure anything, it just works.
Let's add two more projects, B and C, and let's import A and B, OK? For our next dev graph we will see that the relationship between B and C is not Nx. And if we check a change to A and make a change to A, we will see that Nx knows that A and C might be affected by this change and B just can't be, right? Again, we didn't have to do anything, but it just works. Without us having to create a dependency in the JSON file, right? So how much configuration did we generate to make it work? Let's take a look. So Nx to JSON configures the the whole Nx system, right? It would be the same even if we had 1,000 projects, OK? So it's a very small file.
Next, let's talk about plugins, so plugins can customize some aspects of the core, like workspace analysis, task running, artifact storing, caching, all of those can be changed by the plugins. Plugins can also depend on each other. That's an important property, right? If you want to get consistency in use, you have to have it, and to have that, the plugin APIs have to be composable. And that's what we did and you will see it in a second, OK? So plugins are customized. There are two big parts that most folks see right away. One of them is generators.
Plugins can offer generators, but it's important to know that it's optional. You can create files from scratch you can use your own version. That is fine, right? doesn't care. Plugins can add files.
projects, new pages, etc. They can change existing files, right? You can for example add a new page and perhaps change some configuration to match that, right? That's an important thing, it's hard to do because if you want to do this well, you have to transform ASTs and do some fairly sophisticated stuff. Nx offers validations and defaults. It's toolable. They're dry runnable, meaning that Nx comes with a virtue file system so you can pretend you're writing the generator to see what would happen, right without actually changing your file system, and finally the editor integration.
So you can right click and create things using a fairly metadata UI. Let's look at an example. Let's generate a generator. The schema of the JSON file describes the inputs of the generator and Nx CLI can transform and validate input based on this schema, and we also have a DTS file with the same schema, right, and finally the generator itself. This one will be too long because we've generated a bunch of files that are useful for when you ooh want to use, but it's not super-useful for this particular presentation because it does too much so I'm going to remove most of it and instead I'm going to do what most companies like to do, which is to wrap an existing generator. It's very easy.
A generator is a simple child function and it can return -- the NPM package doesn't have any side effects, so I can just ignore the return value. The real magic of Nx generators is not necessarily this piece, right, this is very, very simple, is a set of utilities Nx provides by Nx DevKit. Nx DevKit is a package you can import that you can use to write your own generators. Very handy thing that are easy to do with DevKit and actually quite hard to do if you start from scratch. Plugins can also offer custom executors.
they're optional. You don't have to use them. If you have Nx JS application, feel free to invoke a script within Nx and the rest of Nx as I pointed out before, will work, so everything here is optional, however, it is very handy. So an executors is sort of a typed NPM script, right? Can be used to express long-running tasks, which is fairly challenging, again with validations to make sure. Toolable, and of course integrated into your editor.
Let's look at an example. Similar to a generator, an executors has a schema file and it's used by the CLI and by editors to An executors is just a function that takes options and this one brings some information to the console. But you can change it to for example invoke another Nx integrator. For example for the app to be updated is basically impossible with NPM script. Finally, plugins can offer migrations.
And it's hard to overstress how important this is, but eh the idea essentially the idea is that it can do the adjustments for migrations similar idea that applies to the source code. You can say hey, I'd like to update from version 10 to version 12, I'll update everything in my repo to make sure it works with version 12, OK? Here I have a workspace in Nx if we run Nx my greators, Nx is going to find all the information used installed in this workspace, by the end of this process, Nx will know what your package to JSON should look like, to have a consistent workspace, and what you need to change in the source code to make sure that your source code matches the new package to JSON, right? It will of course update Nx configuration itself, but everything with regard to the tools you use, Nx knows how -- or the plugins know how the tools change and the migrations for Nx are going to update the conflicts for those tools to make sure they keep working. As you install the new integrations, right? As you can see, Nx has updated itself, right and the Nx dependency has been bumped up to 12.1. We can run migrations to make sure the source code matches on the backend of JSON. As you can see it's a small migration, so not much has happened right to keep our workspace working correctly and very often this is everything we need to do.
Nx updates the package joins UPK JSON up dates the JSON to make sure it matches. It's still a huge improvement over some block that needs to change. It's still much, much easier to be up date to da its with the tools you use when you use Nx migrate. The last part of Nx is its powerful integration.
I would like to know that they all depend on Nx core, not on Nx plugins, meaning that if you -- regardless of what you have in your workspace, you can install or build your own plugin, all the integrations will work perfectly. The editor experience with the plugins is a very cool thing, we put a lot of work? , you get in general a lot of assistance, especially for larger workspaces. Refactoring and things like that, so please check it out. Nx Cloud gives you distributed caching, distributed task execution and analytics, we'll be talking a lot about Nx Cloud in this event, so please check out those docs. GitHub integration is a feature enabled to Nx Cloud, but it's fairly stand alone so if you just want to use this, you can enable it and ignore the rest of Nx Cloud, right? It's a very handy thing that allows you to see at a glance what has happened on your API, right, in a way that is a lot more large workspaces-friendly.
If you have to run tests against 1,000 projects, just looking at AST out is not going to be that useful. OK, so now let's take a look at the goals I talked about in the beginning, right? Some of them are task orientation goals, some of them were team Let's see how Nx team can help you provide good answers toward those goals. So you can be very fast, with those features, you can make sure your CI is under 15 minutes for a workspace of any size. Things are affected, you need to be stable, you don't have to run things you don't have to run, can help you different tools to work together and help you compose things, right? Migrations is a huge deal if you want to be up to date with the technologies available, right Again, generators, lint checks, helps you be consistent and follow best practices, migrations is a big deal as refactoring, right? Moving from an older version of an API to a new one and finally the discoverable CLI is a big one. I can go to any part of my project, go to any project in the workspace and know what's going on. OK, thank you? . Oh, I gotta go, sorry about that. Thank you, Victor, that
was great. All right. To the final part of the presentation. I want to talk about something that's really interesting to us and really next step in our evolution as a company at Nrwl.
We're always looking to make Nx better and one of the ways we do that is by building applications with teams and building applications ourselves and seeing what the pain and what the challenges are of building modern applications but we only get a small piece of the challenges that our customers actually face by working that way. Big corporations operate in a lot different way than we do and we're a team of tens of engineers compared with a lot of our customers who are working with hundreds of engineers, have their own complex policies to work within, on enterprise security restrictions, and so we -- one of the things we've gotten really good at is listening to our customers, sending things out, seeing what sticks, seeing what feedback they have and figuring out how we can make Nxs better for them. So I want to talk about some of the things we've been learning from our customers and I'm going to break that into three parts and then talk about what we're doing to address it. The three parts are evergreen Nx, information security, and scaling Nx. So firstly, we want Nx to be an evergreen tool, and by that we mean we want teams to always be on the latest stable release, we want it to be basically free, no friction in the process of upgrading to Nx core as well as Nx plugins and ideally community plug plugins, as well. We want the process to be painless, so we want to automate as much of that process as possible.
Most teams most of the time have a pretty easy process, up grading Nx, sometimes there are corner cases or reasons that people have a hard time to keep up with,in. Sometimes it's hard to justify the effort to update dependencies very often so we've seen teams fall behind, sometimes two or three major versions behind if they get stuck on anything. So for teams who want to stay evergreen and have the latest greatest Nx all the time, we've got something for you. But before we get to that, let's talk a little bit about Nx Cloud. So when we released Nx Cloud last year, the main thing it did was distributed caching and it did that that well. We got lots of feedback on things we could do to make Nx Cloud more enterprise friendly.
One is we encrypted but we didn't have end to end encryption where you could encrypt it so even we couldn't see your assets. We added that to the Nx Cloud, the public version, but is also available to the Nx private Cloud. But teams said they still wanted control over their assets, the build artifacts. So we introduced Nx Private Cloud and we did this in a way that you can run Nx Private Cloud, you've got distributed caching, you've got distributed tasks execution, these two things can save companies thousands of hours a month. And the built-in analytics are there, so you can understand what's working where the greatest opportunities for increasing your productivity are.
And one of the greatest is the run details view where you can get insights into each run, like a pull can request run or running a locally, you can dive into everything that's going on in that, and understand if -- why you have a cache miss or what failed, and really get to information quickly. We released Nx private Cloud, it's got all the same things as Nx public cloud and you can run it on your own servers, the only thing is we added the ability to talk to billing securely so you don't have to go through a contract with us, you can still manage it the same as if you were on Nx Cloud but what we heard from our customers is even that is not enough. They need to be abling to run it in complete isolation without any outside access and we get it, that's a legitimate policy to have. You don't want to trust too much some tool that you're using from a third party.
You want to be able to totally block access to outside network and control it yourself. So we've got something for that as well. But I want to talk about one last thing, one final point before I talk about what we've got. And that's how to scale Nx. We provide a lot of resources to help teams figure out how to do Nx effectively, even with large teams and perhaps hundreds of apps and libraries in a single workspace, but sometimes things can be difficult to figure out on your own, like if we partitioned our libraries differently, could we have more cache hits? Or could we make separate things in a different say so we're not affecting everything when we touch certain libraries? Could we do anything more to get Nx's build operations so our team can move faster.
So to address these needs of large organizations and complex workspaces we're excited to announce a new subscription service from Nrwl called Nx enterprise. As Nx evolves we're just an email or video call away to help you get the latest, greatest improvements to Nx core and official Nx plugins. With enterprise, you can run Nx Private Cloud in complete isolation, inside your network and with a fixed annual subscription, so you have more predictable spend and procurement teams love that.
Everyone wants to be able to predict what you're going to spend. We'll work with you to come up with a subscription that makes sense for your team. And as we release new versions of Nx Private Cloud we're available to help you work with configuring it. it's a self-managed thing, you need a little bit of support from the people working on it to make life easy. Nrwl's primary business for the past five years has been consulting and engineering, building apps alongside our clients and these services are usually provided by having dedicated engineers working alongside client teams for an extended period of time, months or years.
But now with an Nx enterprise subscription, Nrwl's Nx experts can work with your team to make your workspace as fast and ergonomic as possible without needing to commit to large projects with dedicated engineers. If your builds break, Nrwl will help. If your builds end up taking longer than they should, Nrwl will help you figure out why. We've been working towards this model with several customers for some time now and we're excited to formalize Nx Enterprise into something we can offer to the Nx community. This isn't a one size fits all program. We work with each team to figure out what makes sense for them.
Nx Enterprise is available today, and we're gradually adding more clients to the program. Go to nx. app/enterprise to learn more and to figure out what subscription might make sense for your team. With that, I want to thank you all for being part of our first-ever Nx conference. Thank you, and enjoy the rest of the conference.
Judge Victor: Thank you so much for your time and enjoy the conference. [cheering and applause] Brandon: And we're back. Jeff: Yeah, I never left, but Brandon, you can't give away the secrets, Jeff. I'm just saying. We gotta hang out. We're here for the whole time, Jeff: Yeah, I'm exhausted after giving that keynote, though.
Brandon: Yeah, I can tell, you had the music blasting and whatnot, it was a great time. Jeff: What was your favorite part, Brandon? Brandon: My favorite part was Nx Enterprise. And I'm all about the community, so talking about the team, and everything that goes in Nx, those are my two favorite parts.
Jeff: Did you know we had 176 contributors to Nx. That was a lot, huh? that. I am that is a lot. I'm glad to see that number getting bigger and bigger.
Jeff: Thank you, Jeff and Victor for that keynote. Brandon: You're thanking yourself, that's what you're doing? Jeff: Thank you, Jeff, I know you were up late last night, so a special thank you to you. Are we taking a break now or I think we're going to power into the next talk, right, try to make up for lost time. Brandon: Yes, power right into the next one Jeff ... and this is a good talk, you don't want to miss it.
Jason I often refer to him as the co- -- he's had such a big impact on Nx and has been involved with the community, as well, so he works with Fortune 500 companies across different industries to help them develop like Google and he's a fellow Nrwlian as I mentioned before, and so he gets work with a lot of our clients helping them do big amazing things. He's also an enthusiast of board games and like many other folks at Nrwl, he's a mechanical keyboard enthusiast which I've never understood, but I can respect. Brandon: There are more than a few keyboard enthusiasts in Nrwl, I might say. I'm right there on the borderline, but I haven't quite made it. Jeff: Yeah, resist. It's an expensive hobby, from what I understand. Brand on: Key caps. That's all I can tell.
Jeff: Key caps, I could get that. But the coolest ones are weird shapes and I don't know how you would type on them. Well, let's welcome Jason Jean to the stream. Hello, everyone, welcome to the first-ever NxConf.
My name is Jason and today I'm going tock taking you on a journey about how companies launch their first products and why Nx is a vital part of this process. My name is Jason and I'm an architect at Nrwl, you can follow me on Twitter at @FrozenPandaz, and I want to tell you a bit about myself, first. I work in the Nx Core Team, which means that I work on things like the DevKit, task execution, and also project graph analysis. Also, over the last few years at Nrwl, I've had the opportunity to work with ten different companies across probably 50 or more different teams. Some of those companies come to us and they will have a large codebase that they want to migrate over to Nx and we definitely help them with that.
However, other projects, three of them that I've worked on, had nothing. They wanted to launch a brand new product, and they wanted to it with Nx and I think I've learned a few lessons from working on those projects that I'd like to share with you all today about how Nx is a vite willa piece of this process and how it enables them to be successful. So let's start by defining Go-To-Market. For going to market I'm no expert at launching a company or anything, but I have worked with those projects and I'm going to define Go-To-Market as taking a rough idea of a business and achieving market success with it. Including building the pro product itself.
So the first thing we want to do is build and MVP. MVP means a minimum viable product which means for our development team we're going to want to deliver an initial version as soon as possible to users, so we can start getting feedback about how we can provide value to them. We're going to want to start building features as soon as possible, but before we do that, we're going to have to set up some stuff like build configuration, linting, unit testing and end to end testing. This all seems like a chore so Nx has a command called create-nx-workspace. Then we can skip straight to building features and working on MVP.
After we've begun building features, we want to keep it as low effort as possible. Nx allows us to do this by working quickly and efficiently. By, working full-stack, we're going to be building the frontend in the seem repo as our backend. This allows it to share between the API and the frontend. Some things such as interfaces and utility function are going to need to be shared across the backend and front-end so we don't want to write that stuff twice. Along with sharing code, working full stack is also going to allows us to easily onboard new developers.
Because we're starting with a small team at first, while we're building our MVP, we might quickly decide to onboard more developers, when they developers start, they can pull down the whole repo, including the API and the frontend and get the development environment set up quickly. So this is how Nx is already beginning to provide value, as we embark on our journey to launch our product. But instead of me creating a presentation about it, let me also show you how we can do that. So if I jump over to my editor here, we're going to create a project that's going to show us facts about Nrwl's everyday, right? We're going to call it Nrwl facts of the day. So we're going to start off by writing some HTML and we're going to call this Nrwl fact of the day. Then under this, we're going to have our fact , and let's go ahead and get this from an API.
instead of hello, we want a fact, and we're going to get this from API/fact. All right. That's about it for our frontend. One last thing, let's make sure that instead of getting the message, we get the message out of the message. And we're going to need to wrap this in a map.
Now with that out of the way, let's go over to our API: For our API, we're going to want an endpoint that's going to have the name "fact. " It's going to return the message and I'm going to have the message from the service just be a string. Instead of "get data," why don't we call this" get fact," and let's generate some facts. I'm going to do this in a separate library, going to call it Nrwl facts and we're going to write some facts out for Nrwls, export a constant, name Nrwl facts and we're going to say Nrwl s have tusks, and narwhals do not like to be in cap tist captivity, in fact, there are no narwhals that are in captivity that I know of today.
We're going to return a random item from this array. OK? I'm going to go back to our controller, this should all be correct. Just to be consistent, let's say, instead of get data, it's get fact. All right. Let's start our frontend, as well as our backend. And let's see how we did.
So I go to local host 4200, we have our narwhal fact of the day and that is that narwhals do not like to be in captivity. All right, this is a minimum viable product. I think we can show this to some users and see what they think. Let's head back to our presentation. So now that I've shown you how Nx allows us to execute quickly for building an MVP, let's start finding a target audience for our product.
When we're finding a target audience, we're going to have to change the product numerous times frequently to better suit our customers as we learn more about what makes it valuable to them. Nx encourages the use of libraries which is going to allow us to do several things. One of these things is it's going to be able to separate our concerns. When we're concerned about just facts, we know where those are.
And when we're concerned about how to display those facts we know that's in the frontend. Separating concerns is going to allow us to easily identify where we need to make a change any time we need to make a change. Also because we're learning about how the different parts of our product are coming together and how they interact with each other, this is the perfect time to build abstractions for our product so that later on we can reuse these abstractions and be more effective later on. The other thing that is going to be important when finding a target audience is that some of the changes are going to be quite large, they're going to affect our whole product and we're going to want to make those changes as quickly as possible. So we can use atomic changes and work on all the different parts of our changes all at once without having to jump between different repos and different commits and all those things.
By working atomically we're going to be able to make any large-scale changes simpler. Overall Nx allows companies to be more adaptive, and this is going to allow them to more quickly find their target audience. So let's go back to our product, the narwhal fact of the day and not everybody loves narwhals, unfortunately, I know they're amazing animals but I personally like pandas more and I know that Jeff also likes pigs more.
So why don't we allow the customer to pick their favorite animal and show them the fact about that for the day? So let's go over back to our code. I'm going to start in the backend this time, and the first thing I'm going to do is go to our service and make it a little bit more abstract. Instead of facts always being the narwhal facts, let's define some animal facts and say that narwhal facts are just under the key of narwhals. Now for getting fact, I can pass in an a animal that I want to get a fact for and I'm going to get the animal facts at the key of the animal.
I'm also going to need to expose to the frontend what kind of animals are available so I'm going to create a method called get animals and I'm going to return the keys of animal facts. Now that that's done, we can go over to controller, and we can create an endpoint for getting animals. This is going to return a string array. And it's going to return the service.getanimals. Also for end point, let's change it so that we can have an animal fact.
This is going to be a param in our URL called animal, which is going to be a string. We're going to be able to pass that into our service and we're going to get a fact about the animal that we want. Now for the frontend, let's go into our components. First thing we're going to want to do is we're going to want to list some animals. So this is going to come from API /animals and we're going to get a string array out of this. Then we're going to want to select an animal , just pass an animal, and we'll say this selected animal equals animal.
Then we're also going to assign the fact to something. We're going to say the fact can either be an observable of a string, or it can be null. Because if we don't have a select animal, we're not going to have a fact. And this is going to equal null at first.
But when we select our animal, we're going to be able to say that this .fact $is going to equal that, and we're going to change our endpoint from API/animal OK ? So all we have to do is make sure that this is a property, that's a string, and set it to an empty string at first, gonna make that not private. We don't need the string, since we defined it as a string. In our HTML, before we give people the fact of the day, we're going to need to select an animal. And let's move all this stuff into our different div here, and above this, we're going to say, "what is your favorite animal? " and now we're going to have a list of buttons with each animal and we're going to get that from our list of animals. Whenever we click the button, we're going to want to select our animal, and instead of narwhal fact of the day down here, we're going to call it. -- we'll call it selected animal fact of the day.
Alrighty? Now, let's see if everything works. So if we refresh the page we're not seeing our animals. Let's see why that is. API animals : Our API call is failing. Let's see why that is. We go to our controller, we have not defined the path.
So let's give it a path or it's going to be a get request, and we're going to want animals. OK? Now that that's done, we're able to get our list of animals, first being the narwhal, so our narwhal fact of the day is narwhals do not like being in captivity. Now that we can choose our animals, let's add more animal facts.
Just like before, I'm going to create new facts, and I'm going to say that I want tomorrow some panda facts, which are my favorite animal and also let people get facts about pigs. So for pig facts, let's export pig facts pig facts = an array, we'll do the same for panda facts. And panda facts are going to be pandas love eating bamboo, and also pandas love sleeping.
Now that we have more facts, let's go back to our service, and we'll add these to our animal facts. So we'll have panda, panda facts, pig, pig facts. OK. Let's go ahead and restart our API real fast.
And now we're going to be able to go back to our application. Refresh, and now we can select panda and get panda facts for the day, pandas love sleeping, pandas love eating bamboo. Pigs love belly rubs, narwhals have tusks.
Awesome, I'd say we've made this application a little bit better for our customers and we're almost ready to launch, so let's take a look at the next step. For the next step in our journey, now that we have a product that we are happy with, we're going to want to make sure that this product and our company can grow in the future, so we're going to establish a path for growth. We want to ensure that our business can scale. As we want to grow revenue-wise and maybe even enter new markets, we want to make sure that the code that we've written so far is going to be scalable towards the future.
One way that Nx helps do this is giving you the ability to add new applications. We've already built a lot of infrastructure in a short time, but in the future, we're not going to want to do that again. Even though it was easy, we'd much rather reuse the same infrastructure we've already built. When it comes time to support new platforms, maybe enter nouvelles new develops or way in the future when we want to enter more markets, Nx allows us to do this easily. The next thing that Nx allows us to do as we start to grow our product and our company, it's going to grow in complexity, as well, luckily because Nx puts everything in one workspace we're able to provide a holistic of the code, and therefore your company, for you to understand.
The best way to get a holistic understanding is to run Nx dep-graph. This is going to show you all your projects and how they relate to one another and it's going to allow you to identify where changes need to be made, if there are products available or maybe just understand why two things depend on another thing. If you want to learn more about the dep-graph, make sure to check out Philip's talk tomorrow where he's going to be using the dependency graph to shove to solve some issues that you might run into.
We've had some best practices that we want to establish in our company so that all the developers can work the same way. To do this, it would be important to maintain our boundaries between modules. We create different kinds of libraries that serve different purposes and some projects might not want to depend on other projects.
Whenever this happens, we should get an error, if for instance, the frontend should not depend on the facts directly and instead they should call it through the API, we can throw an error when someone too is to do that in the code. This is going to prevent our code from becoming a ball of mud, even as it becomes more complex. It will stay organized and we're going to be able to understand how things relate to each other. Also, you might have your own terms of best practices for your own organization, and it's going to be important to create lint rules to enforce that. Check out James' talk tomorrow about how you can use ESLint with Nx to create rules that are specific for your organization and help you enforce your own best practices.
And, at the core of Nx, we have an intelligent build system which is going to allow us to keep being consistent and efficient as we scale up our product and company. By using the affected command, we're going to be able to limit the scope of our projects that we worry about at a time, based on the change. After retesting this part of the workspace, we're going to be able to say that our change is valid and we can deploy it with confidence, we're not going to worry about the other parts of the workspace that don't matter to us right now, and this is going to allow us to stay efficient.
The other thing along with Nx, you can use Nx Cloud to provide remote caching, this means that when one developer builds an application, other develops don't have to build it on their own laptops and instead can get the artifacts in remote cache. This is going to make it very easy to onboard more developers as we grow our business. These developers are going to be able to save time by pulling down artifacts from remote cache they can. The other thing that we're going to want to do with Nx Cloud is contribute our task execution, because we have a lot of projects in our workspace and it's ever-growing, we're going to eventually reach a point where we need to affect everything at once.
Even on a really powerful machine, this is going to take a long time, so being able to distribute these tasks across multiple machines is going to allow your workspace to scalene further. Kiril will be giving a talk tomorrow on optimizing your workflow using Nx Cloud. You should definitely check it out as I think you'll learn a lot. Now we're going to be able to support our growth in the future, let's take a quick look at our application that we've built so far, and see how some things work together. First thing I'm going to do is commit what we have right now. And then we're going to see, if I add a panda fact , such as pandas live in China, he we want to see what gets affected by this change.
So I can run the affected dep-graph command , and I'm going to see that not only is panda facts affected, because I've added a new panda fact, but also the API is affected, as well. If I select all the projects, I'm able to see that the frontend is not affected and neither is the interface for the API. I can also see that narwhal facts was not changed and that pig facts was not changed.
This means when I go to test my application, all I have to do is test panda facts. Also, as you can see by this dep-graph, we still have a holistic view of our application. We know that we have a frontend, and we have a backend, backend has some facts, and we have an API interface which is shared between the two. This dependency graph is going to be really important as we grow the complexity in our project, and it's going to allow us to maintain that holistic understanding. If we go back to the presentation, now we've seen a longer journey from taking our initial product into market, how Nx helps us along the way. Executing quickly when building MVP is going a Lou allow us to ship our MVP as soon as possible to our customers and then we can adapt quickly as we find our target audience and how we can provide value to the market place.
And finally as we decide how to manage our product, we want to establish a path of growth and Nx is going to give us a scalable architect that's architecture that's going to grow with our company. Thank you. That's my talk for today. And I hope you enjoy the rest of the talks here at NxConf and while listening to those talks, maybe keep in mind that when you need to launch your next project, keep Nx in mind to consider using it to ensure that you're successful. Thank you. Brandon: And we're back. Hopefully I sound you know, somewhat better this time. Can you hear me OK? OK, maybe it wasn't me this time. Maybe it was --
Jeff: Sorry, I was muted this time. Brandon: There you go, first the people say I sounded like a robot so I was going to do this on the camera to let you know the robot wouldn't do that, right? So there it is, it's settled. I see you in the chat. Jeff: All right, thank you, Jason, that was great as per ush. What's up next, Brandon?
Brand on: You next up, we have Manfred Steyer, who is of course well known in the Nx community, Angular community, just all over the place. So he'll be up doing the next talk, and I will go ahead and introduce him, Manfred is a trainer, consultant and programming architect with the focus of Angular. He is also a GDE and trusted collaborator on the Angular team and has written for O'Reilly, German Java Magazine, which is fun, and windows.
developer and of course he regularly speaks at conferences, NxConf being one of them. Jeff: One of my favorite things about Manfred is he every once in a while sends me care packages from Austria, with Austrian soda and chocolates and other things and it's so good and he sent me one recently and I haven't told him this yet. I told him he sent it to the wrong address and I texted the guy at the old address to say hey, did the package come and being in Arizona the package had been delivered when he was on vacation and it melted everything inside the package so the guy threw it away when he came home.
I imagine it was a puddle of exploded soda cans and chocolate all over his driveway so I'm sorry, Manfred, I'm sure it was delicious. Please send another one. Brandon: I thought you were going to say that the person who was at your previous address says no, it's not here, and you kind of drove by one day and you saw him eat chocolates. Sitting on the porch popping bonbons? Brandon.
Saying thanks, Manfred eating your chocolates. Jeff: I should have gone by and checked his garbage can to see if he really threw it away. Brandon. . : Trust but verify, right? Hello.
Everybody I want to start with a picture, namely with this person here. Who remembers her? bell? I give you a tiny hint, namely whoosh whoosh whoosh whoosh. Yeah, she was from the Knight Rider team. She was Bonnie. Back then when I was a child, I did not even recognize that Bonnie had a Ph.D. Somehow that was not a topic for me back then. And I really liked Bonnie.
Somehow she inspired me to do stuff with computers, because she was really good with this stuff. And I think she was one of the reasons why I told my parents they should buy me a computer. I told them I might need it for school, which was not totally true, but also not totally wrong. However, when I'm thinking back to Bonnie, one thing only works in Hollywood: Namely, Bonnie was a one-man, a one-woman show.
And this does not work in engineering nowadays, because engineering, computer science, and especially software engineering, is it a team sport, isn't it? We need to coordinate several people in order to achieve a given goal, and sometimes we even need to coordinate several teams. Because software is getting huger and huger, and so one team might not be enough. And you can imagine coordinating several teams is even harder.
But Nx got us covered. With Nx we can define several folders with several libraries. And I really like it to define one folder per business domain. For a business domain that flects this or that aspect of our business, like booking, check-in, and luggage here.
All those domains are domains of handling flights. However, you can even go one step further. More and more people start implementing micro-frontends, which is basically nothing else than creating one application per business domain. That means if we want one application and we can team of its own to all of those applications. They can work
independently. They can do their own decisions and because those teams are tiny teams, they can really work in to provide business value on a regular basis, they don't need to coordinate with each other, they don't slow down each other. However, if you talk about micro-frontends, we also need to talk about runtime integration, because this is what we need when we go with micro-frontends. The thing is, and I'm really sorry for this, the user is not interested in the micro-frontends. The user is not interested into any technical details. All we want to have is an integrated solution and so we need somehow to load all those tiny micro-frontends in something I call a shell at runtime.
The shell does not know all those micro-frontends up front, because they are deployed and developed and even compiled independently. The shell only knows them at runtime when it loads this or that micro-frontends it's its working. This is when I have the example of the micro-frontend on the left and I'm loading it into the working area on the right. Doing something like this was really difficult in the past.
In the past you needed a lot of tricks for this, however, since about a year, we have Webpack module federation, which is really the missing link here. It makes this straightforward. And now, we can say, well, let's just put each and every micro-frontend into a repository of its own, to maximize the freedom, the flexibility of those teams.
So that all those teams can do their own decisions, so that all those teams can choose their own version of the frameworks to use, and even the frameworks. One team might go with Angular, another team might go with React. They issues what they want, and what helps them to achieve their goals. This would be one approach. However, beware of what you wish for, as they say.
Because even though this is possible with micro-frontends, it brings a lot of disadvantages to the table. For instance, if you do this, if you distribute your source code into several repositories, you need to share your shared libraries using NPM. And we all know sharing libraries for internal purpose via NPM is everything but fun. We need to version them, we need to update the versions, we need to deploy them, we need to install them over and over again.
Also, we can end up with version mismatches. Because this all is about runtime integration, and so it might happen that we are loading at runtime two micro-frontends that don't fit together, that use versions of Angular or React or something like this. And then I guarantee you, all hell breaks loose. And so, I want to discover here with this talk if it is possible or how it's possible to combine Nx with module federation, because module federation is really great when it comes to runtime integration, and Nx has all those other issues solved. With Nx it is easy to share a code, with Nx it's also easy to prevent version mismatches, because everything is co-located.
I want to start with a general discussion about mono repos versus multi-repos in the context of module federation. Then I want it to go into module federation in general and then I want to talk about some considerations that are important when combining federation with monorepos, or to say the least with monorepos in general. But first of all, let me introduce myself, I am Manfred, my focus is Angular for enterprise scale operations. I'm doing a lot of work in this area in consultancy, and so I'm helping a lot of companies around the world.
Besides this, I'm quite connected to the Angular community as you see here. If you're wondering where this accent comes from, well, I'm from Austria, I also do a lot of stuff in Germany and as mentioned, I'm always happy if I can work together with people around the world. Currently I'm doing this remotely, which really works well.
OK, let's get started with the first topic. This is the discussion about mono versus multi-repos. And I want to start with multiple repos. Here you see several micro-frontends, devisedded subdivided into multiple repos, this gives us the most complex.
Each team can use its own framework, each team can use its own framework version, each team can make their own decisions, they need to coordinate. Plus, everything is isolated from each other, this is one of the goals. We want to have isolated micro-frontends, so that one micro-frontend cannot interfere with another one. And this goal is achieved with quite strict borders, namely with the borders of our micro-frontends and of our repositories. A repository border is quite a strict one.
Grabbing over this border, using something from another domain, is nearly impossible, at least it cannot happen by incident. I know there is something like get 'sup modules, but you really need to do this on purpose. This is one of the advantages here besides having the highest amount of flexibility. However, as mentioned before, this comes at a cost.
For instance, sharing libraries is really a nightmare, because you have to share libraries via NPM. What does that mean? Well, that means you have to implement the library, you have to assign a version number, you have to publish it. You have to integrate the library in your application, you have to find that there is a backend there, because there are always bugs in there, and you have to file.
you publish it, you reinstall it, and you find ought there out there is another bug and this happens all the time until you are you're crazy. So as you see here, it's not easy to share a code via NPM. Another issue, I also mentioned it shortly at the beginning is you can end up with version mismatches. If everyone can do what they want, we might end up with version mismatches in the shell, because the shell does not know the micro-frontends up front.
And so it might b
2021-09-20