Complex Workspaces Q&A

[00:00:00]
>> Not only was I able in record time to create an application that is pulling from a mock REST API. I was able to create a second application that's also pulling from the same mock REST API that are sharing the same code and now they're sharing the same toolbar.

[00:00:22]
And so just use your imagination, this is like pretend castle in the living room but these concepts you can use to build up and extend onto this. Because kind of what I'm showing is this is how you build a house with Legos but all the techniques, all the concepts, they still apply it scale.

[00:00:46]
So with that said, does anybody have any questions about what I've covered in terms of sharing a common UI component across two applications within a mono-repo.
>> I have a question regarding libs.
>> Mm-hm.
>> Well, the shared libs. I was just wondering could for example a lib be just TypeScript for I don't know, like project provided it follows the angular package notation or should it just be straight like what we're working with right now?

[00:01:24]
>> So the question is, does a lib have to be or can it be just a regular TypeScript implementation as long as it follows the proper kind of angular notation to kind of inject it into the workspace? Or do we need to stay within kind of the confines of angular if I understood correctly, was that right?

[00:01:47]
And the answer is it really could be a lot of things, so I think it would definitely have to be TypeScript. But you can absolutely use a straight vanilla TypeScript lib and import it in. And so now this raises some really interesting opportunities in terms of, How much of your Angular app is actually Angular?

[00:02:23]
How much of your React app is actually React? And how much of it is just regular TypeScript? And so I don't consider myself a react expert, this is why I attend front end masters on a regular basis. But in terms of Angular, that a lot of what I do in Angular, and all my favorite parts of Angular are not really Angular at all, it's just basic TypeScript.

[00:02:51]
In so much that I can extract all these patterns out and use them really across the board in a lot of different places. And so all of a sudden now you have the ability to start to share some of that functionality not only across projects but across projects that are built on different frameworks.

[00:03:13]
And then you start to add in like micro friend and frameworks and federated modules, and we are living in the future. And so just to kind of challenge everybody to put their thinking cap on. Stop for a second and just think about where we think the web is going.

[00:03:39]
And the web is not going in a direction that you're gonna have a single dominant framework. Or you're going to have a single dominant technology other than I would say kind of TypeScript being the bytecode of the web. But as a whole, that what you are going to see, and I believe that a lot of people are philosophically aligned with this, is you're going to see functionality take the forefront and you're going to see frameworks start to kind of step into the background.

[00:04:11]
And I don't know if you remember three, maybe five years ago the rhetoric in the dialogue around frameworks was who's gonna be the best? And you would see these articles, Angular and React, there's gonna be blood in the streets. And it's just that is just not helpful, because it doesn't really help the end users, and so it is a larger extension.

[00:04:37]
When you start to think about the future and where we're going is I really want to challenge everybody to think about complexity that we see at the framework level, starting to just fade into the background. And I really believe you're going to start seeing applications that are really built with React Angular view and they're all coexisting, totally fine, because under the hood it's just JavaScript.

[00:05:07]
And so in a framework level, in a mono-repo level and I think really in an enterprise level that's the future. So super awesome question.
>> How would you adopt web workers or service workers into the whole space architecture?
>> So the question is how would I adopt service workers into the architecture that I'm proposing here?

[00:05:34]
Is that correct?
>> Yep.
>> And so my answer is that, You do it by extracting that functionality out. I mean, that's almost in a way web workers and service workers, they exist to extract and kind of run certain threads in parallel and do parallel processing and a lot of offline stuff.

[00:06:05]
And so as with anything that what you wanna do is, can I isolate or extract this out so that it's portable? Do I have service worker functionality that I can pick up and can I plug it into multiple applications? And could I possibly even publish it as an NPM package that could be used in any application?

[00:06:32]
And so in terms of the specific implementation details, it really depends on what you're building. But I would implement service workers just like I would implement Firebase or Socket.IO or anything else is that I would extract that out. And so for instance, if I was going to implement GraphQL, which would be a really cool fun idea, is that I would build a lib that would encapsulate that functionality so then it's portable.

[00:07:00]
Does that make sense?
>> Yep.
>> Can I create an Ionic application and use this structure?
>> So the question is, can you use Ionic within a mono-repo, specifically an NX mono-repo? And the answer is absolutely there are a few fiery hoops you have to jump through. It's not too bad, they're really good articles on the Internet about how to do this.

[00:07:30]
And I went on a rant one day to Adam Bradley, who is one of the co-founders of Ionic. And he was like, that's really funny because we actually just hired a person and they're entire job is really to integrate and basically make a lot of the Ionic ecosystem available within NX.

[00:07:54]
And so the answer is yes, they're working on it. And recently I did this and what happened is I had an entire Ionic application, which consisted of nothing more than a bunch of Ionic components that were 30 lines or less. Now think about that, because I already had my kind of admin portal thing where I could create read, update, delete.

[00:08:22]
And really mobile devices are primarily for consumption for reading, you don't do a lot of heavy form lifting. You can but in terms of I just want to see what football games are playing or whatever, I just need to pass information. I was able to spin up an Ionic application in NX and my components were again 30 lines or less and I was done in half a day because 80% of the work if not more was already done.

[00:08:52]
So super good question and definitely do that, it works really well. So the question is if you have an application, where would you recommend that your business logic goes? And the short answer is, you want to abstract that into a lib, typically, if you're using NgRx, which I recommend, there's other state management libraries I think they're all okay.

[00:09:17]
I like NgRx is that your business logic will typically, depending on the nature, will either go into a utility service and lib or if it's asynchronous, I need to send an email, I put those into effects. Because it needs to do something, and then based on that side effect if you will, then it needs to store that result back into state.

[00:09:40]
So that is I'm assuming some little prior knowledge to NgRx. I can elaborate on this kind of further, but I would say NgRx effects is probably the primary place for business logic to go into exist, because that's where you ultimately handle the control flow of your application.
>> Then next one is, when you begin to see multiple UI components and libraries, would you continue to keep them separate or would you group them together, creating a higher level library?

[00:10:19]
>> So the answer is if I started to see multiple kind of UI libs I'm presuming kind of single purpose one off UI libs that they exist. What I consider consolidating those into maybe a single more general larger lib, and the answer is I certainly would consider it.

[00:10:40]
I think you can abstract things out so much that the overhead to manage that is you no longer see a payoff. And I would rather see the one lib with 10 really good components versus 10 libs of one component and especially if I'm going to be using those together.

[00:11:12]
Now I understand why the Angular material team has broken all of their libs out into standalone modules. The reason being is that they're very, very aggressive about allowing you to only use what you want to use. But the trade off is that now we have to go create an Angular or a material module and put all of that in there, and so there is a trade off there for that.

[00:11:45]
But I would certainly consider it when you evaluate, the overhead of having to parse through these libs is higher than having them in a single place. So the answer is maybe, it depends, but I would at least think about it.