Integration Strategies

There are multiple integration patterns available for the integration of journeys generated with TALY generators. Three of those patterns are supported by the TALY Nx Generators:

• Standalone App
• Web Component
• Module, integrated directly in a parent app

1. Comparison of Integration Patterns

See here for the origin of this comparison and the surrounding discussion

Looking at the world of web based integration scenarios, traditionally there where three cases:

1. Legacy and untrusted content is integrated via iFrame 🧱
2. Applications consuming libraries/modules can integrate external code within the build process (SPA)
3. Linking to another application - this is what the web was built for 🔗

Today, the possibilities of integration have grown and we now have the following options:

1. iFrame this can be used in case a strong isolation is required, but is not the recommended solution for trusted apps. ⚠️ Beware of bad UX ⚠️
2. Web Components Web Components provide a strong isolation on the code level, which allows it to maintain dependencies independently (there are exceptions to that, for example, the dependency zone.js can still lead to conflicts). This strong isolation leads to multiple framework versions running in the same window. ⚠️ Beware of performance issues when loading multiple frameworks in the same tab ⚠️
3. Module Federation Module federation is similar to Web Components in terms of loading an external app into the host DOM. Here, the goal is to use as many shared dependencies as possible, to improve load and run performance. ⚠️ Beware of dependency conflicts and that module federation is not production ready ⚠️
4. Plugin/(Angular) Module Library The Library approach is architecturally similar to the remote module, the difference is, that the library module is known at build-time. The advantage of this approach is that dependency problems are detected during the build-time and library versions can be streamlined. The downside is, that each update requires building a new application build. Generators can help to automate this process by creating a standalone app or a library module. ⚠️ Beware of bigger deployments (all apps at once) ⚠️
5. SPA In many integration cases code is not shared on runtime but through libraries and then compiled into a single SPA. This case provides the best performance and protects against dependency problems that are only detected at the integration level. To scale such an approach across multiple teams libraries and monorepos are technologies and approaches that can be used here. ⚠️ Beware of additional tooling effort when running monorepos ⚠️

2. Conclusions on Build time vs. Web Components vs. Module Federation

If the goal is to provide the best user experience, we suggest to use build time as default. If a separation on deployments is needed with trusted code, then Web Components are the most widely used option. As an alternative to Module Federation, a build time library module integration can help achieving a similar experience for a fast loading SPA.