One approach for creating SPA-based clients for microservice environments is loading several Web Components into a page. Using an example, this post shows one way to implement this idea. For this, it leverages Angular Elements which allows to compile Web Components out of Angular projects. [Mehr]
In my two previous blog posts, I've shown how to leverage Schematics to generate custom code with the Angular CLI as well as to update an existing NgModules with declarations for generated components. The latter one was not that difficult because this is a task the CLI performs too and hence there are already helper functions we can use.
But, as one can imagine, we are not always that lucky and find existing helper functions. In these cases we need to do the heavy lifting by ourselves and this is what this post is about: Showing how to directly modify existing source code in a safe way. [Mehr]
People ask me on regular basis how to use SPAs, esp. Angular-based ones, in a microservice-based environment. The need for such microfrontends is no surprise, as microservices are quite popular nowadays. The underlying idea of microservices is quite simple: Create several tiny applications -- so called microservices -- instead of one big monolytic applications. This leads for instance (but not only) to smaller teams (per microservice) that can make decisions faster and chose for the "best" technology that suites their needs.
But when we want to use several microservices that form a bigger software system in the browser, we need a way to load them side by side and to isolate them from each other so that they cannot interact in an unplanned manner. The fact that each team can use different frameworks in different versions brings additional complexity into play.
Fortunately, there are several approaches for this. Unfortunately, no approach is perfect -- each of them has it's own pros and cons.
To decide for one, a software architect would evaluate those so called architectural candidates against the architectural goals given for the software system in question. Typical (but not the only) goals for SPAs in microservice-based environments are shown in the next section. [Mehr]
Even though the word iframe causes bad feelings for most web devs, it turns out that using them for loading SPAs in a micro service based environment -- aka micro frontends -- is a good choice. For instance, they allow for a perfect isolation between clients and for a separate deployment. Because of the isolation they also allow using different SPA frameworks. Besides iframes, there are other approaches to use SPAs in micro service architectures -- of course, each of them has their own pros and cons. [Mehr]
Diese Woche habe ich drei Workshops auf den Angular Days in Berlin gemacht. Nachfolgend finden sich [Mehr]
Although tuning an application's performance can be difficult, sometimes all we need to do is laying back and waiting for the next version of the used framework. This especially holds true for Angular as the Core Team is working constantly on improving things under the hoods. A good example for this is the conciser code the Angular Compiler emits beginning with Version 4 or the Angular Bundle Optimizer that transforms code to make it more treeshakable.
On more of this optimization techniques landed with 5.0.0-beta.4 about two weeks ago. It allows the compiler to remove unneeded (consecutive) white spaces from text nodes and to remove even whole text nodes that only contain white space characters. This leads to less code emitted by the AOT compiler and therefore to smaller bundle sizes as well as faster start up times.
In this post I'm describing how to use it, which performance gains I measured when applying to an example application as well as how this approach works under the covers. The example application I've used for this can be found in my GitHub repository. [Mehr]