Ng-News 26/04: Micro Frontends at Google

#angular #webdev #javascript #programming

Doug Parker from the Angular team shared insights on Micro Frontends at Google — isolation, Protocol Buffers, and when to avoid the approach. This episode also covers the TypeScript Go rewrite progress, and Angular DevTools Signal Graph updates.

Micro Frontends at Google

Doug Parker was a guest at the Angular Meetup Graz, which was this time more a podcast. Doug is a member of the Angular team, focuses on the CLI, and talked about Micro Frontends at Google.

A little bit of context. Google has a monorepo, which means all applications are within one repository. That does not mean they use Micro Frontend architectures. In fact, there has been some information (also on ng-news) where we shared the Micro Frontend approach of Google's Cloud Console, which is based on a huge micro frontend architecture using an iFrame approach, which is not used anymore.

Instead, the new concept is to do Micro Frontends in complete isolation. In order to avoid collisions with shared dependencies, Google plays it safe. They do not share anything at all. So a very autonomous solution. When it comes to shared logic, they use Protocol Buffers, where a service is not really shared between micro frontends but more a messaging infrastructure. Another requirement is that they have the need to combine multiple frameworks together.

Doug's approach is to see Micro Frontends as a contract between apps. In the end, there is an interface that needs to be implemented and the infrastructure takes care of the integration.

There are no plans to open source the solution once it is finished.

When should Micro Frontends be used? Whenever the underlying problem could be solved in a different way, then try out that approach before Micro Frontends. For example build times could be improved in different ways.

If there are hard UX requirements, a micro-frontend approach might be hard to implement.

Lastly, very often Micro Frontends are used to reduce the communication between teams. One has to ask first, if this is actually the goal, or if the opposite approach, namely, where people need to talk with each other more, should be achieved.

Status Update on Go Rewrite of TypeScript

Last year, TypeScript announced that they are going to rewrite the compiler in Go, which should bring performance improvements that might be an order of magnitude, so about 10 times.

This undertaking takes some time and consumes obviously all the resources of the team. Push-based posted about the current state. We are coming closer and the upcoming version of TypeScript 6.0 will be the last one written in TypeScript.

The Angular team follows and has already started to make their codebase ready for v6 as well.

#angular #typescript #js | PushBased

TypeScript is changing forever! v6.0 will be the last JS-based release before the complete native Go rewrite in v7.0. TS Team is officially transitioning v6.0 into "Maintenance Mode" to focus on the port. 🔥 Major Breaking Changes to prepare for: - Strict by Default: 𝘀𝘁𝗿𝗶𝗰𝘁: 𝘁𝗿𝘂𝗲 is finally the default. - No More Legacy Modules: Support for 𝗮𝗺𝗱, 𝘂𝗺𝗱, and 𝘀𝘆𝘀𝘁𝗲𝗺𝗷𝘀 is being removed. - Modern Targets: 𝘁𝗮𝗿𝗴𝗲𝘁 defaults to 𝗲𝘀<𝗰𝘂𝗿𝗿𝗲𝗻𝘁 𝘆𝗲𝗮𝗿> (Evergreen). - Faster Builds: 𝘁𝘆𝗽𝗲𝘀 defaults to [ ] (stops auto-including every @𝘁𝘆𝗽𝗲𝘀 package). - Enum Merging: Removed. - Side Effects: 𝗻𝗼𝗨𝗻𝗰𝗵𝗲𝗰𝗸𝗲𝗱𝗦𝗶𝗱𝗲𝗘𝗳𝗳𝗲𝗰𝘁𝗜𝗺𝗽𝗼𝗿𝘁𝘀 defaults to 𝘁𝗿𝘂𝗲. The Goal? A 10x faster compiler, but it requires shedding legacy weight. Links: - Maintenance Mode (TS #62963): https://buff.ly/BRBTweG - Deprecation List (TS #54500): https://buff.ly/Tb7QyGl The Angular Team has started preparing for it too: https://buff.ly/Tb5KSBS #angular #typescript #js

linkedin.com

Angular PR #66578

Miscellaneous

The Angular DevTools provide a visualization of the Signal Graph. The latest version received an update and now gives a much better view on the resource, which in the end is a group of different Signals belonging together.