Microcks UI future

[lbroudoux]

Hey Microcks community!

As we start a new year, I'd like to write a bit about the future of Microcks UI, hoping to generate comments, feedback and discussions.

What's the situation?

For many years now, Microcks UI has been built using Angular and the PatternFly design system. PatternFly has great resources that enables teams to create consistent and scalable enterprise products and the Microcks UI - even if it's not the more modern and fancy - does the job pretty well.

At the beginning (time of PatternFly v2 and v3), PatternFly was a set of patterns with multiple implementations (Pure HTML, Angular, React others...). However, with the advent of v4, PatternFly turns out to be implemented in React. This leads us to the situation where Angular users had no choice but sticking with PatternFly v3 and its supported version of Angular: Angular v8!

As of today, Microcks UI is then mainly made from:

• PatternFly: ^3.59.5
• Angular: ~8.2.14

with no easy way to move to newer versions - Angular is currently v19 and PatternFly v6 has just been released!

This put us in a bad situation because many of pulled transitive dependencies from those foundations are now outdated with a lot of CVEs as illustrated by the security vulnerabilities report of the frontend part:

Moreover the TypeScript version we rely on - forced by the version of Angular - is now incompatible with recent library released (see for example, this nasty trick we had to do to integrate Keycloak v26.0 directly importing it and changing it to fit our Typescript version 🤮 ).

We absolutely have to do something to preserve Microcks bright future!

What are the options?

Without further ado, here are the options I foresee -

Note

Please feel free to add some others if you have some ideas!

Option 1: Vendor and upgrade PatternFly + Angular to the most recent possible version

In this option, we fork and vendor the components of PatternFly Angular implementation we're using and make the job of updating them to the most recent Angular version possible. It means that we would maintain our own repository of UI components derived from patterfly-ng but updated to a recent Angular version. Bumping these components to a new Angular version can require a huge amount of work (see this upgrade guide)

Still - independently of the PatternFly components, we'll also have to upgrade our services, controllers and util Typescript classes to more modern syntax and paradigms 🤔

Option 2: Replace Angular/PatternFly by React/PatternFly

In this option, we'll typically drop everything and totally change the model from Angular to React. This is typically the same thing as starting a new UI from scratch, but we (this means mainly myself at the moment) have to learn a totally new (and huge!) ecosystem. Of course, we can still benefit from PatternFly OOTB components, upgraded for React but we also have to endorse the full learning curve of React.

Option 3: Drop the UI and start something else

In this option, we're dropping everything and starting from scratch a new UI. Choosing a new frontend framework is a hard topic (see https://roadmap.sh/frontend/frameworks) but some reports highlight some big trends (see https://virtuslab.com/blog/frontend/trending-frontend-technologies) even if - not yet - aligned with the download trends on NPM: https://npmtrends.com/@angular/core-vs-react-vs-svelte-vs-vue

Analysis

As of today, I tend to think that:

• Option 1 requires a big effort and is not viable in the long term: PatternFly v3 Angular is intended to disappear. Period. These option could have made sense a few years ago, but as of today, I have the feeling that we're too late.
• Option 2 requires a huge effort with an important learning curve (the React ecosystem is huge as it's not an all-in-one) but does not prevent us from being in the same situation in a few years when the PatternFly team will choose the replacement techno for React
• Option 3 - whilst also representing a big effort - may provide a more controlled and incremental way of doing things. Moreover, it allows us to select just the tools, the components libraries and the vendoring process from the beginning.

I have already started studying and will focus the next weeks on investigating Option 3 unless some people help and convince me that other options may lead to better results.

To help in the choice of a new stack, I think some points from our past experience are super important:

• Ideally we'd like to not rely on a third-party component library so that we can directly manage upgrades ourselves on just the components we need. ShadCN seems to be a good pick on that
• We should have the lowest learning curve possible - not relying on fancy JIT/AOT/Transpiler but sticking with pure JavaScript the most possible and benefiting from TypeScript help on the IDE. Svelte and SvelteKIt look very appropriate,
• Having a lightweight and fast development environment to make web development simple again. Vite seems perfect for that.

Additional requirements

• Pure SPA to keep it lightweight to deploy
• Dark Theme (see 🧛‍♂️ Accessibility > Please add (or explain how to add a theme) Dark theme (for the 🤓 ) #1427)
• E2E testing framework available and used from the start (https://playwright.dev/ ?)
• To Be Completed...

Follow-up

While I should have written this entry a few months ago, I already started a prototype of it using SvelteKit. This ongoing PoC is located here: https://github.com/lbroudoux/microcks-sveltekit

Feel free to check it out but also to react and comment on all the things above! Your inputs are crucial and your help more than welcome!

[soGit]

Link to the previous discussion microcks/hub.microcks.io#17

[kaos]

I think I agree with most points presented. Would discourage option 1 as more work than it's worth.
Option 2 could make sense, as I think React will be here for quite some time before there's another hotter project replacing it.. but,
Option 3 I think gives the most control with the least bloat, hopefully giving the best conditions for being a long term viable option.

I would understand a move to React, but it feels a bit heavy, and I agree with the concerns that you may end up in the same situation again in the future.

Personally, I really like Svelte and SvelteKit, but have not used it more than on a smallish hobby project to try it out.

Another option I find interesting is https://elm-lang.org/
Perhaps a little bit too niche, but it has some similarities in the design to Svelte, and appeals to my functional programming style preferences, as a Erlang enthusiast. Highly recommend having it on the radar ;)

[lbroudoux]

Thanks for the feedback, and glad to see you enjoyed Svelte and SvelteKit!

The PoC at https://github.com/lbroudoux/microcks-sveltekit is going well, and we now have all the different layers implemented: models, API clients, services, pages, UI components based on ShadCN and Bits-UI, and custom UI components. I have to say I really love the development experience - even though it looks like crap at the moment as I'm a total noob on CSS and Tailwind 🤣

I think I'll pause from now to take time to gather more feedback and investigate other alternatives.

Thanks for pointing at https://elm-lang.org/ - will have a look at it.

[soGit]

I propose to start from hub.microcks.io and focus on the Frontend folder first (because the main point is to develop an migration approach for Microck's FrontEnd related projects).
To move iteratively, we might need to update dependencies to the lates minor versions (check PR microcks/hub.microcks.io#24 )
after that, let introduce "prettier" so, we have consistently formatted code across the project.
Along that we need to define the core functionality, so hight level e2e test can be created to avoid manual checks and simplify refactoring. https://playwright.dev/ can be used. (check PR microcks/hub.microcks.io#58 )

[lbroudoux]

I agree that https://github.com/microcks/hub.microcks.io/ could be a good candidate for pushing a first round of improvements. However, instead of minor upgrades on the current front end, I would prefer to start a full-blown new experiment with the possible target.

And a big +1 on integrating e2e test framework from the beginning => I'm going to add this to the requirements list.

[soGit]

@lbroudoux in terms of proposed options:
For Option 1 – we can stay with angular, but replace PatternFly with anything else (eg. angular material).

For Option 2 – I believe that framework selection should not be leaded by framework used in a ui component library.

For Option 3 – we might consider astro as well, it allows to work with multiple framework and allow easily prerender static content (Example. hub.microcs.io can be prerendered, server as static, and later on even used without backend).

Also we might use framework-agnostic UI components library like: https://shoelace.style/ based on web components. The limitation here is that SSR for web components not always works well.

[lbroudoux]

I think you have a good point here regarding astro and https://hub.microcks.io ... Thinking about it these last few days: I think we don't have exactly the same requirements and contexts on both the Microcks App and the Microcks Hub...

However, because the Microcks App somehow integrates the Hub UI components with its UI, it would be nice to reuse stuff/components from the Hub and share some common grounds.

Also, I think you're right when you said that the Hub could be pre-rendered or use SSR - though the Hub is also exposing REST APIs consumed by the Microcks App. Ideally, if technically possible, we could have something like:

• The Hub UI being pre-rendered / SSR with exposed REST API,
• The Hub UI being integrated into the App and working in full SPA mode, using the exposed REST API of a remote Hub instance.

I didn't know about https://shoelace.style/ but I had a look at https://next.shadcn-svelte.com/ for the PoC. Looks nice. How would you compare both tools/approaches?

[pplancq]

Hello everyone,

I am a React developer and a friend of @SebastienDegodez, who invited me to join this discussion. He thought that my perspective might be helpful. I don't yet have an in-depth knowledge of the Microcks project, but from what Sébastien has told me, it has piqued my interest.

From what I understand, you're considering revamping or modernizing your frontend. I'd like to share some thoughts on the matter.

I believe there's no inherently right or wrong solution. The choice of technology shouldn't be driven by the fear that it might become obsolete in the future. After all, your original choice probably wasn't guided by that concern, even if today your component library has become outdated—which is unfortunate, but such is the nature of technological evolution.

To facilitate your decision, it's essential to return to the core of your needs and address them directly. What are your expectations for this new frontend? Do you need Server-Side Rendering (SSR)? Is accessibility (A11Y) a priority for you? Is Search Engine Optimization (SEO) a major concern for your application? These are all questions that should guide your choice.

Regarding the technology to adopt, I would recommend React. Not just because I'm a React developer, but because it's a flexible and powerful JavaScript library for building interactive user interfaces. It is widely adopted, with around 42% of developers using it, and benefits from a massive community as well as a rich ecosystem of resources and tools. Supported by Meta (Facebook), React offers high performance through the use of the Virtual DOM and promotes a component-based architecture, which simplifies the development and maintenance of web applications.

In summary, the choice of your front-end technology should be guided by your specific needs. Clearly identify what you expect from your application, then select the tool that best meets those requirements. If you have specific questions about React or how it could address your needs, I'd be happy to discuss it further.