DSpace 8 Angular : library-based architecture proposal

Goal 

This proposal has the goal to try to provide a solution in order to be able to modularize the DSpace Angular architecture. This need was already expressed during one of the last dspace visioning meeting group :  

https://wiki.lyrasis.org/display/DSPACE/DSpace+Product+Visioning+Group 

So the main porpouse is to define and to provide a new architcture allowing, for example, that the dspace’s core functionalities could be used by an external plugin which is not part of the dspace’s code repository.

How? 

Our application has been built using a monolithic architecture, where all the components and functionality are tightly coupled within a single codebase. While this approach has served us well till now, it has also introduced challenges in terms of the ability to introduce new features and updates independently from the codebase. 

In order to move to a more modular architecture, we propose to migrate from a monolithic approach of building apps to a library-based architecture  here each feature is built in isolation.  

Why? 

With the current monolithic architecture if any DSpace adopter needs to implement an additional DSpace feature/addon they can’t depends on the application code. Because, if the addon depends on core functionalities, helpers functions, or shared components in the application, it means it depends on application code and this breaks the libraries dependencies direction. 

Moving to a library-based architecture allows to break down our Angular application into smaller, self-contained libraries or modules. These libraries can be reused across multiple projects or addons. The application can depend on these libraries just like it did before, but now in a more structured way. 

With a library-based architecture, we can separate different concerns and responsibilities into individual libraries. This separation enables better organization and maintainability of our codebase. For example, we can have separate libraries for core functionality, UI components, data services, authentication, and more, making it easier to modify specific parts of the application. 

Implementation Plan 

It will require massive code changes and refactorings and probably will make breaking changes, so that’s why it’s recommended to start it with DSpace 8. 

We can incrementally introduce these changes, by firstly analyzing our existing Angular application and identifing functionalities and components that can be separated into individual libraries. We should consider to break down the application based on different concerns such as core functionality, shared UI components, data services, authentication, or any other logical divisions that make sense for us. 

How to deal with it? 

Moving all things to libraries will create a lot of files, and they will need to be managed. Also, we will need to fix the build rules because we can’t build the application before building the libraries it depends on. So, we will need a build orchestration tool, and that’s where the NX comes in.  With NX, all these can be done in a predictable and standardized way. 

How does all these help?  

• Faster builds (build caching) 
• Better code reuse (specific libraries for each usecase)
• Faster dev time because of provided schematics
• Better code visibility (project deps graph)
• Dependency contraints
• Easy to introduce new addons without caring about build time or bundle size 

Helper links: 

• https://nx.dev/more-concepts/library-types 
• https://nx.dev/more-concepts/dependency-management 
• https://nx.dev/more-concepts/code-sharing 
• https://nx.dev/more-concepts/creating-libraries
• https://nx.dev/more-concepts/applications-and-libraries
• https://nx.dev/more-concepts/how-project-graph-is-built
• https://nx.dev/recipes/environment-variables/define-environment-variables