Use of Components Between Frameworks about micro-frontends HOT 11 CLOSED

@ido-ran I bet you are not the only one, wanting to break the good old AngularJS monolith apart. :)

I am currently employing a complete micro-frontend architecture based on some of the shown principles here in a of course closed-source project. The basic building blocks are web components for a composition framework that are composed in a host app. That way you can distinguish three types of components:

• feature components (which are roughly the same as presented here)
• ui components that are simply representing encapsulated UI widgets
• service components that do not have any UI at all

If you stick to some simple conventions, this allows the components to be completely technology-agnostic, enabling you to utilize the same components in any current web application framework.

Coming back to your question - re-using your good olde AngularJS code will be tricky. AngularJS (and Angular 2+ as well) is a framework not meant to built components, but to build component-based SPAs. Although it is possible to use Angular (and even AngularJS) for building web components, IMO it is not feasible.

Directives (though effectively strongly discouraged with Angular 1.5+) do not translate very nicely into a composition framework built upon web components - (because they alter the behavior of existing elements and are very technology-specific).
Services are perfect candidates for service components if you manage to extract their state into a central state (like Redux). Actual AngularJS components may be good candidates for either UI components or feature components.

Without knowing your code base of course, I can only make wild guesses, but I'd say, if your

• core business logic lies within services, than extract it into service components, use those in your current app and they will allow for re-use in any framework (with you coming from Angular, the logical choice would be Angular 5+) that you could run in parallel for a soft migration
• core logic is in an abundance of UI components + directives think about a migration to Angular 5+; of course vendor lockin will still be a problem, but you won't have to re-learn everything and can re-use existing AngularJS knowledge.

We are currently developing a small project, utilizing just service components; but for building technology-agnostic UI web components both Stencil and Skate look promising.

from micro-frontends.

hello @ido-ran
you may also want to check OpenComponents as a way of creating micro-frontends and enable you and your team to break down your current presentation into smaller parts; this platform that we use and maintain at OpenTable is helping us to achieve what you just described.
Happy to talk more about that anytime soon.

// cc @matteofigus @nickbalestra

from micro-frontends.

@ChristianUlbrich we have an abundance of UI components 😄 We tried the Angular migration but we found it's very hard, especially because we have a lot of components and we will not migrate everything from AngularJS to Angular in the coming years.
Angular does provide a migration path to upgrade and downgrade components but the result is a mixed codebase where it's hard to understand which templates are AngularJS and which are Angular.

@mattiaerre I'll look at both OpenComponents and OpenTable, thank you.

from micro-frontends.

Did you take a look at Web Components and frameworks that compile to those as a possibility for sharing components between frameworks?

from micro-frontends.

No, can you please add links if you have something specific?
I'm looking mostly on how to reuse AngularJS components because that's my use-case.

from micro-frontends.

Well, I think your AngularJS components cannot be reused as Web Components (I might be wrong, though). My intention was for the future path to create reusable components that are not tied to a framework, eg. through. https://stenciljs.com.

from micro-frontends.

@ChristianUlbrich I've looked at OpenComponents and it doesn't look right for us because we run our app both as SaaS and OnPrem. AFAIU the OnPrem option will not be possible because of the need for access to the registry.
It does look very interesting and I'll keep learning that, just one thing jumps immediately: even if everything works like magic I'll now be dependent on OpenComopnents, right? 😄

from micro-frontends.

@ido-ran I have only skimmed through OpenComponents. Their approach is another vendor-lock in as you have already guessed - you need a specific client and a very specific API. Interoperability with (future) frameworks and technologies is thus questionable. While I won't argue that it obviously works for them with OpenTable it is not something I would advise for a long term architecture. The core idea of micro-frontends as they are presented here is, that there is no additional API - but just the DOM. Taking that further, one will end up with real Web Components. In our approach (just plain Web Components) we have a similar registry setup though (allowing for deploying components independently of the actual frontend app and if the need arises, without reloading of the frontend app).

As an example, if you use Web Components as the building block of your composition framework you get many things for free - (Chrome|Firefox)DevTools DOM Event Breakpoints and enhanced UI, interactive testing of your components (just .dispatchEvent() from the console or breakpoints) in any browser and in the case of Angular (2+) nice eventHandling integration (you can do stuff like <my-component (CUSTOM_EVENT)="handleCustomEvent()"></my-component>)

from micro-frontends.

@ChristianUlbrich I agree, the OpenComponent solution doesn't looks like good fit for me because the app I'm working on is deployed both to cloud providers, but also on-prem - specifically to support scenarios where deployments do not have access to the internet. While it is possible to install the registry as part of the deployment of our system, it defeats the purpose because we'll never deploy anything else to the registry so it's mostly adding pain without any gain.

I agree with you on the part of having a different vendor-lockin will only make the matters worth - now I'll have 2 vendor lock-ins 😉

You can argue that the solution offer by micro-frontends is having a new vendor lock-in on WebComponents, which looks like a good bet but it's still a bet. - do you agree?

from micro-frontends.

@ido-ran Vendor lock-in means, that you employ a technology that is either proprietary and/or controlled by one vendor alone. Angular for example is at least on paper open source - though it is obvious, that the biggest features are developed internally and not open at Google - but it still is a proprietary technology, i.e. there is only one supplier and one runtime to run Angular.

Web Components are open and they are a standard. The core feature Custom Elements are a standard browser API, there are multiple polyfills and it is up to you, which framework to use to develop them.

So, no Web Components are not a vendor lock-in. If you would have asked me, whether it is a sure thing, to bet on them for future web development, I would have said yes :). They are the natural native way of composing micro frontends.

from micro-frontends.

Sounds good.
I'm no longer working on that app but I will take the lessons with me.

I'm closing this issue as it seems to run its course.

from micro-frontends.