Hi All we have some Pr…

5 minute read

Hi All,

we have some Projects that we wannt to combine into an NX Workspace and wannted to hear your Opinion about it.

Current State: 1 Large Monolith Software written in http://ASP.NET|ASP.NET Web Forms (~ 20 Years Old) with not even MVC.

What we wannt: Create a Place where we can “rebuild” the Moduls from or current software into microfrontends.

What we did untill now: Create a small Design System with Lit Element and an Lerna /Yarn Workspace.

What now? We wannted to use Angular for the first Module (later if ppl wannt they can use react or what ever) and use our Web Components. The Developers of the Angular application and the Design System will be the same guys (only for a limited time, later the team will only build Web Components).

What would you recommed, should we move the current design system and angular stuff into one NX Workspace ( all future “Moduls” will be apps, and the Design System will be a lib) And if we build it inside one NX workspace how should we handle the “component” development with different core technologies (every component has its own package.json and litle dependencys, in nx i only saw one place with package.json for all  [but i am realy to new into nx no know ]) can or is it even wannted form nx to a lot of small apps with custom dependencys? and how do i simlink that? I have alot of question if you guys say NX is the way to go :smile:

Looking forward for your reccomendations / tipps!   Thank yoU! :pray: Burak


Nx is the way to go. See point 5. Once settled that, I would look at this as an opportunity to design the software how it should be designed. Modular and scalable. You probably have more experience than i do, but here is something that i wanted someone to tell me a long time ago. If i could start from scratch:

  1. Algorithm design(bigO, etc).
  2. System design: UML or at least a mental map of modules and how things relate. Truly understand your domain(by domain I mean processes, workflow, actors, etc. If the app places an order, get the architecture right).
  3. Best the best use of OOP, FC, RC, etc when needed. (FC: Functional programing, Reactive Programming) Make your classes or files loosely couple and highly cohesive.
  4. Keep it simple, KISS, but get your design patterns right. Observer, command, visitor, factories, strategy, etc. If you do point #2, it will be much easier.
  5. FRONT END: Angular allows you to create multiple apps or multiple libraries. True microfrontends in angular is still in the baby stages, it is up to you if you want to go down this path. I would start with multiple libraries and try to make your apps small, really small. You do this but creating libraries. Follow the UNIX mindset.
  6. Rely heavily on reactive programming. Use rxjs and ngrx following best practices and patterns. I make emphasis on patterns.
  7. Add documentation. Compodoc is a good start https://compodoc.app/
  8. Test your apps. Dont let your code rot. It starts rotting by not writing tests. Unit test and e2e.
  9. Follow SOLID principles. Keep your components lean. Use services for logic and api calls, but make sure each service serves one and only one purpose.
  10. Use nestjs for backend.
  11. Use graphql or prisma.
  12. DOCUMENTATION: Compodoc and swagger. Document your api.
  13. Write unit test and e2e. Write your test first.
  14. Follow steps 1-4 for backend stuff.
  15. If you are thinking about microfronends, why not microservices. Nestjs supports microservices. What else would you add or what would you change?

See https://indepth.dev/tiny-angular-application-projects-in-nx-workspaces/ by

See https://www.angulararchitects.io/aktuelles/module-federation-light-using-microfrontends-with-angular-already-today/ by

Also refer to https://indepth.dev/the-shell-library-patterns-with-nx-and-monorepo-architectures/

This book by will be helpful to you https://leanpub.com/enterprise-angular

Just be aware that it will be a lot of work to do it in this way. It would probably be easier to rebuild it from the leaf nodes of your DOM and up, using React or Vue.

Hello Guys, thanks for all the nice Informations, i think i have a lot for read today :smile: One question i have right now is.

In the examples i always see a global lib with styles that gets included the normal way. Is there any good reference for the “Web Component” approch you guys know in this time of workspaces. ofc. i can create 1 lib for every component (that would be like 100 libs ~) than i have to take care of there dependencys etc.

We than can use this Components inside our Micro Frontend APps and in the Old fasion Product

Would angular material or primeng repos give you an idea how to do it? I am not suggesting using them, but learning from their experience one could create a library that easily exports styles. Primeng has libs for different platforms, angular, react, java, etc. One way to go is seeing how they develop these libraries. I am assuming web libraries share the same css files, but they are exported in different ways. In your case the angular apps and web components would share the core files, but they would have a superset library that is in charge of the platform. I wouldnt think you need to create 100 styles libs for 100 apps.

The Problem we see in repos like angular / primeng is the global css file. If we look at the Structure of Primeng https://github.com/primefaces/primeng/tree/master/src/app/components at there 80+ components they have 80 folder with js,html and basic component css (like our approuch) but the component need the global css file to get his design. So the Component are not encapsulated) If we look at The Web Component appouch that is geeting popular we see https://github.com/material-components/material-components-web-components/tree/master/packages this component lives without global css and works. We can modify the css with a global theme file too. But this wont brake stuff

So my only problem right now is the package.json that i have for every component (cuz we can host every component on npm and install where ever we need)

without installing the full system