I am very much in support of everything Scott described in the previous email in regard to the shared component library being the successor to the legacy NiFi FDS library. I am really enjoying the NX monorepo architecture and shared library the new UIs use, and it is something I'm leveraging in my work updating Registry's UI.
3. > > *Decouple Registry Into Its Own Repository* > - After the *nifi-fds* upgrade, NiFi Registry (and other NiFi UIs) can > be moved to a separate repository and consume *nifi-fds* as an npm > package. Maybe once we get to this point it won't be necessary to > move > Registry to a separate repository but it would at least be possible. I support this option if the community decides in the future that Registry must move into its own repository once again, but this would also mean more overhead with versioning and release management. Not a deal breaker, but keeping all the UIs together as an Nx monorepo like they are now is a more simplified approach. On Fri, Mar 7, 2025 at 10:37 AM Scott Aslan <scottyas...@gmail.com> wrote: > Hello everyone, > > Great discussion on modernizing NiFi Registry! Upgrading to the latest > Angular and related technologies is crucial, and we should also leverage > the extensive work already completed in NiFi 2. > > When we originally built NiFi Registry, we introduced *nifi-fds > <https://nifi.apache.org/projects/fds/>*, a reusable component library > distributed via npm. The goal was to provide a themable, reusable set of > components across the NiFi ecosystem to ensure a consistent user > experience. However, when developing NiFi 2.0, we opted not to use > *nifi-fds > 0.3.0* due to significant changes and improvements in Angular Material. > Instead, we implemented NiFi 2 as an *Nx monorepo* with a *shared component > library* built on the latest Angular and Angular Material versions. This > library now provides a customized and themable set of reusable components > for: > > - *NiFi* > - *Custom UIs* (e.g., JoltTransformJSON and UpdateAttribute) > - *Content viewers* > > As others have pointed out in this thread, any modernization of NiFi > Registry should align with this shared component library from the NiFi 2 Nx > monorepo. Additionally, since *nifi-fds 0.3.0* is based on outdated, > unsupported versions of Angular, it also needs modernization. In effect, > the *shared component library in the NiFi 2 monorepo is the modernized and > upgraded nifi-fds*. Once the Registry UI has been modernized and part of > the NiFi repo we essentially just need to go through the steps to release > the shared lib as *nifi-fds v0.4.0* (or consider making it *v1.0.0*) and > publish that package to as nifi-fds. > *Proposed Approach* > > 1. > > *Upgrade Registry Within the NiFi Repository* > - The ongoing work by Shane and others to upgrade NiFi Registry should > be integrated into the same repository as NiFi. > 2. > > *Upgrade and Release the Shared Component Library* > - Once Registry is integrated, we should release the shared component > library. > 3. > > *Decouple Registry Into Its Own Repository* > - After the *nifi-fds* upgrade, NiFi Registry (and other NiFi UIs) can > be moved to a separate repository and consume *nifi-fds* as an npm > package. Maybe once we get to this point it won't be necessary to > move > Registry to a separate repository but it would at least be possible. > > This approach ensures that all NiFi UIs remain *aligned, consistent, > maintainable, and modernized* within the latest Angular ecosystem. Looking > forward to hearing your thoughts and collaborating on the best path > forward! >
