Forem: Martin Choraine

🧪 Speeding Up Spring Integration Tests: Lessons from Context Caching

Martin Choraine — Sun, 20 Jul 2025 07:44:45 +0000

At Pleenk, like in most projects I’ve worked on, the number of tests inevitably grows over time — and with it, the execution time. As feedback loops get longer, developers lose effectiveness, and eventually motivation to test. That’s when issues start to creep in.

One common way to maintain fast feedback is to prioritize unit tests. They are great for testing individual components in isolation and for exploring edge cases. But they’re not enough. Nothing gives me as much confidence as a good integration test — one that verifies that components work correctly together in a real configuration.

This is the story of a developer trying to reconcile confidence and speed, to write effective integration tests and ease the pressure on an overloaded CI pipeline.

⚡ The Myth of the Minimal Context

It all started with a simple intuition:
"If I reduce the Spring context size in my tests, they’ll run faster."

I wrote a test with a minimal Spring context, loading only the configuration and beans strictly necessary. Result: from several dozen seconds (sometimes minutes) of bootstrap time, I went down to just a few seconds. Victory.

Encouraged, I decided to apply this strategy more broadly. But when I tried to generalize it across all tests, the outcome was very different — and that’s when it all fell apart.
Running the full suite led to slower execution overall. A huge letdown.

A single test ran fast, but running multiple tests together had the opposite effect. Why?

🔍 Understanding Spring’s Test Context Cache

The culprit: Spring’s test context cache, which I previously knew only superficially.

After some digging, I discovered that Spring optimizes test time by sharing application contexts across test classes — if it can. If the framework detects an identical context has already been built, it reuses it. Otherwise, it rebuilds one from scratch, which is costly.

Spring generates a cache key based on many aspects of test configuration:

Context Loader / Initializers: via @ContextConfiguration
Test-specific customizers: @DynamicPropertySource
Context hierarchy: via @ContextHierarchy
Active profiles: via @ActiveProfiles("test")
Test properties: via @TestPropertySource

If the key differs (or the context is marked @DirtiesContext), Spring creates a new context.

👉 Running a test in isolation with a minimal context is fast.

👉 But running many tests with slightly different contexts destroys cache efficiency and adds overhead.

Lesson learned: by trying to optimize individual test speed, I had accidentally killed shared context reuse across the suite.

🧪 The `@MockBean` Illusion

Another tempting idea is to create a large, generic context that can serve many tests — minimizing the number of context rebuilds.

But quickly, reality hits:

You have to initialize everything
Deal with irrelevant side effects
Prepare data for unrelated layers
Understand complex interactions

Tests become brittle, slow, hard to read.

Enter @MockBean, a widely used solution to isolate parts of the application.

And at first glance, it’s perfect:

Simulate irrelevant dependencies
Keep tests focused
Code remains clean and controlled

But here’s the hidden cost: each use of @MockBean alters the context configuration. Even adding or removing a single mock breaks the cache key, causing Spring to rebuild the entire context.

What seems minor for one test becomes a massive overhead across a suite.@MockBean is powerful — but extremely dangerous if you care about fast execution. Yet, it’s ubiquitous. I’ve seen it in most projects, training courses, and online tutorials.

🧱 Modular Monolith Architecture to the Rescue

At Pleenk, our application is a modular monolith — a single deployable unit structured into business modules. Each module is strictly isolated according to hexagonal architecture principles:

Separation of domain logic from infrastructure
No direct calls between business modules
Communication via ports, gateways, or events
Clearly defined and controlled dependencies

We call this a modulith:

A design that combines the deployment simplicity of a monolith with the modularity and maintainability of microservice-inspired architectures.

Most integration tests only target one or two modules, never the entire app.

So why not configure only the modules we care about — and mock the rest?

🛠️ The Solution: Declare Modules, Mock the Rest

The goal: test a selected part of the application, while mocking all unrelated modules — without breaking the context cache.

🎯 Strategy

Dynamically declare which modules to load
Mock beans from all other modules
Preserve a stable cache key so that contexts are reused across tests

After much research, I found no out-of-the-box tool. But I stumbled on an overlooked Spring API: ContextCustomizerFactory.

1. Custom `ContextCustomizerFactory`

This interface lets you customize the application context at test time.

Our implementation:

Reads the list of target modules from a custom annotation
Detects beans belonging to other modules
Replaces them with mocks (via Mockito)
Defines a cache key based only on the selected modules

👉 All tests targeting the same module set reuse the same Spring context.

// This factory is used to customize the test context based on the selected modules
class ModuleTestContextCustomizerFactory : ContextCustomizerFactory {

    override fun createContextCustomizer(
        testClass: Class<*>,
        configAttributes: List<ContextConfigurationAttributes>
    ): ContextCustomizer? {
        // Check if the test class is annotated with @ModuleTest
        return testClass.getAnnotation(ModuleTest::class.java)?.let { annotation ->
            ModuleTestContextCustomizer(annotation.value)
        }
    }

    private class ModuleTestContextCustomizer(
        private val modules: Array<Module> // These are the modules we want to include
    ) : ContextCustomizer {

        override fun customizeContext(
            context: ConfigurableApplicationContext,
            mergedConfig: MergedContextConfiguration
        ) {
            // Inject a BeanFactoryPostProcessor to customize beans before instantiation
            context.addBeanFactoryPostProcessor(configureBeanFactory())
        }

        private fun configureBeanFactory(): BeanFactoryPostProcessor = BeanFactoryPostProcessor { factory ->
            factory.beanDefinitionNames.forEach { beanName ->
                val beanDefinition = factory.getBeanDefinition(beanName)
                val className = beanDefinition.beanClassName

                if (shouldBeMocked(className)) {
                    mockBean(beanName, className!!, factory)
                }
            }
        }

        override fun equals(other: Any?): Boolean {
            return other is ModuleTestContextCustomizer &&
                modules.contentEquals(other.modules)
        }

        override fun hashCode(): Int = modules.contentHashCode()

        private fun shouldBeMocked(className: String?): Boolean {
            if (className == null || modules.isEmpty()) return false
            if (!className.startsWith("com.pleenk.backend.modules.")) return false

            val isInTargetModules = modules.any { module ->
                className.contains(".${module.packageName}.")
            }

            return !isInTargetModules // Only mock if the bean doesn't belong to the selected modules
        }

        private fun mockBean(
            beanName: String,
            className: String,
            factory: ConfigurableListableBeanFactory
        ) {
            val beanClass = Class.forName(className)
            val mock = Mockito.mock(beanClass)
            factory.registerSingleton(beanName, mock)
        }
    }
}

2. A Clear Annotation: `@ModuleTest`

We introduced a custom annotation to define the modules needed by the test:

@ModuleTest([Module.NOTIFICATION, Module.PROFILE])
class NotificationIntegrationTest {
    ...
}

Its Kotlin definition:

@Target(AnnotationTarget.TYPE, AnnotationTarget.CLASS)
@Retention(AnnotationRetention.RUNTIME)
@SpringBootTest
@Transactional
@AutoConfigureMockMvc
@ActiveProfiles("test")
@ContextCustomizerFactories(ModuleTestContextCustomizerFactory::class)
annotation class ModuleTest(
    val value: Array<Module> = [],
)

It wraps common test setup annotations and passes configuration to the factory.

3. Cleaner Injection: `@AutowiredMock`

To improve readability, we added an @AutowiredMock annotation — which behaves like @Autowired, but signals that the bean is mock-injected:

@ModuleTest([Module.NOTIFICATION, Module.PROFILE])
class NotificationIntegrationTest {

    @AutowiredMock
    private lateinit var kycApi: KycApi

    ...
}

This small detail makes it easier to distinguish real vs simulated dependencies at a glance.

📉 The Results

With this strategy:

✅ 50% faster overall integration test execution
✅ Fewer contexts created thanks to smarter reuse
✅ Consistent test design across the team

Developers now write tests that are more focused, faster, and easier to maintain.CI is more stable. Feedback loops are tighter. And most importantly: confidence is back.

🚀 What’s Next?

This strategy is still evolving. Some ideas we’re exploring:

Enable org.springframework.test.context.cache logs to track context reuse
Avoid loading internal beans from modules that are only accessed via HTTP or controllers
Write an internal test strategy guide to align team practices
Build a tool to analyze test context reuse: identify which tests share or break contexts, and which config deltas cause unnecessary context rebuilds

Got ideas or feedback? Share them in the comments or reach out — I’m always interested in learning new test strategies for complex Spring apps.

🧭 Final Thoughts

By combining modular design, precise context control, and a few Spring internals, we’ve found a sweet spot between test speed, confidence, and maintainability.

If your team is facing:

Slow CI builds
Flaky or long-running integration tests
Inconsistent test structure

I hope this experience gives you some inspiration.There’s no silver bullet — but a thoughtful strategy can make a big difference in both product quality and developer happiness.

🧪 Réduire le temps d'exécution des tests d’intégration Spring : retour d’expérience sur le cache de contexte

Martin Choraine — Sun, 20 Jul 2025 07:37:19 +0000

Chez Pleenk, comme sur la plupart des projets où j’ai travaillé, le nombre de tests finit toujours par exploser. Et avec lui, le temps d'exécution. Résultat : les feedback loops s’allongent, les développeurs deviennent moins efficaces et finissent par se détourner des tests. C'est à ce moment-là que les problèmes apparaissent.

Une idée très répandue pour obtenir un feedback rapide consiste à favoriser les tests unitaires. Ce sont eux qui permettent de tester chaque composant de manière isolée et d’explorer des cas extrêmes. Mais ils ne suffisent pas. Rien ne me donne autant de confiance qu’un test d’intégration, qui garantit que plusieurs composants fonctionnent bien ensemble, dans leur environnement réel.

Voici donc l’histoire d’un développeur qui a voulu concilier confiance et rapidité, écrire des tests d’intégration efficaces, et soulager une CI en surchauffe.

⚡ Le mythe du contexte minimal

Tout a commencé par une intuition :

"Si je réduis la taille du contexte Spring dans mes tests, je vais les accélérer."

J’ai donc créé un test avec un contexte très limité, ne chargeant que la configuration et les beans strictement nécessaires. Résultat : je suis passé de plusieurs dizaines de secondes, voire minutes de bootstrap, à quelques secondes. Victoire.

Motivé par ce succès, je décide de généraliser l’approche. Mais lorsque j’ai tenté d’appliquer cette stratégie à l’ensemble des tests, les résultats ont été tout autres. Et c’est là que tout s’écroule.

En exécutant toute la suite de tests, le temps global explose. Plus lent qu’avant. Douche froide.

Le test lancé seul s'exécute plus vite, mais c'est l'effet inverse lorsque plusieurs tests sont lancés ensemble. Comment expliquer ce phénomène ?

🔍 Plongée dans le cache de contexte Spring

Ce phénomène vient du cache de contexte Spring dans les tests, que je ne connaissais alors que de loin.

Après quelques recherches, je découvre que le framework propose un mécanisme pour réduire le temps d'exécution en mutualisant les contextes entre les classes de test. Si le contexte a déjà été construit, il peut être réutilisé — sinon, il est reconstruit, ce qui coûte cher.

Spring utilise une clé de cache composée de nombreux éléments pour déterminer si un contexte peut être réutilisé :

Context Loader / Initializers : via @ContextConfiguration
Test-specific customizers : @DynamicPropertySource
Context hierarchy : via @ContextHierarchy
Active profiles : via @ActiveProfiles("test")
Test properties : via @TestPropertySource

Si la clé change (ou si le contexte est marqué @DirtiesContext), Spring considère qu’il doit reconstruire entièrement le contexte.

👉 Lancer un test isolé avec un contexte minimal est très rapide.

👉 Mais lancer toute la suite avec des dizaines de contextes légèrement différents coûte très cher.

Moralité : en essayant d’optimiser les tests isolés, j'avais en réalité détruit le partage du contexte entre eux.

🧪 L’illusion du `@MockBean`

Face à ça, une autre idée paraît séduisante :

construire un contexte Spring suffisamment général pour être partagé entre tous les tests.

Mais on se heurte vite à un mur :

il faut tout initialiser,
gérer des interactions inutiles pour le test,
injecter des jeux de données dans chaque couche,
comprendre des comportements qui ne concernent même pas le test…

Les tests deviennent alors longs, fragiles, illisibles.

On en vient alors à une pratique très répandue : utiliser @MockBean à outrance.

Et en surface, c’est parfait :

on simule les dépendances non pertinentes,
on garde un test ciblé,
le code reste clair.

Mais cette simplicité a un coût caché : chaque @MockBean modifie la définition du contexte et casse la clé de cache.

Ce qui peut sembler anodin à l’échelle d’un test devient, à l’échelle d’une suite complète, un véritable multiplicateur de lenteur :

Spring reconstruit un nouveau contexte à chaque test, même si un seul mock change.

@MockBean apparaît donc comme un outil puissant… mais extrêmement dangereux si l'on cherche à optimiser les temps d’exécution. Et pourtant, c’est une approche très répandue : je l’ai retrouvée dans la majorité des projets, des formations, et des tutoriels que j’ai croisés.

🧱 Une architecture modulitique pour structurer les tests

Chez Pleenk, notre application est un monolithe structuré en modules métiers. Chaque module est isolé selon les principes de l’architecture hexagonale :

séparation stricte entre métier et infrastructure,
pas d’appel direct entre modules métier,
communication uniquement via ports, gateways ou événements,
dépendances bien maîtrisées et explicites.

Nous appelons ça une architecture modulitique :

Une approche qui combine la simplicité de déploiement d’un monolithe avec la modularité et la maintenabilité d’une architecture orientée microservices.

Je ne vais pas entrer dans les détails ici — cette architecture mériterait son propre article — mais il faut juste comprendre qu’elle nous permet de limiter les interactions entre modules.

Et côté tests, on observe que chaque test d’intégration couvre un ou deux modules maximum, jamais toute l’application.

Dans ce cas, pourquoi ne pas configurer uniquement les modules concernés… et simuler les autres ?

🛠️ La solution ?

L’idée : tester une partie de l’application (un ou deux modules), tout en isolant intelligemment les autres, sans casser le cache Spring.

🎯 Objectifs

Déclarer dynamiquement les modules à inclure,
Moquer les beans des autres modules,
Conserver une clé de cache stable pour mutualiser les contextes entre les tests.

Après de longues recherches (et quelques désillusions), je n’ai trouvé aucun outil clé en main pour faire ça.

Mais en explorant les entrailles de Spring, j’ai découvert une API peu connue : ContextCustomizerFactory.

1. `ContextCustomizerFactory` sur-mesure

ContextCustomizerFactory est une interface qui permet de personnaliser la création du contexte d’application pour les tests.

Notre implémentation :

récupère la liste des modules à booter,
identifie les beans des autres modules,
les remplace par des mocks, des implémentations factices ou spécifiques,
définit une clé de cache basée uniquement sur les modules inclus.

👉 Tous les tests ciblant les mêmes modules partagent alors le même contexte Spring, même s’ils diffèrent sur d’autres points.

class ModuleTestContextCustomizerFactory : ContextCustomizerFactory {

    override fun createContextCustomizer(
        testClass: Class<*>,
        configAttributes: List<ContextConfigurationAttributes>
    ): ContextCustomizer? {
        // On vérifie que l’annotation @ModuleTest est présente sur la classe de test
        return testClass.getAnnotation(ModuleTest::class.java)?.let { annotation ->
            ModuleTestContextCustomizer(annotation.value)
        }
    }

    // Customizer principal, qui injecte les mocks au moment de la création du contexte
    private class ModuleTestContextCustomizer(
        private val modules: Array<PleenkModule>
    ) : ContextCustomizer {

        override fun customizeContext(
            context: ConfigurableApplicationContext,
            mergedConfig: MergedContextConfiguration
        ) {
            // Ajout d’un post-processor pour intervenir sur les beans avant leur création
            context.addBeanFactoryPostProcessor(configureBeanFactory())
        }

        private fun configureBeanFactory(): BeanFactoryPostProcessor = BeanFactoryPostProcessor { factory ->
            factory.beanDefinitionNames.forEach { beanName ->
                val beanDefinition = factory.getBeanDefinition(beanName)
                val beanClassName = beanDefinition.beanClassName

                // Si le bean appartient à un module externe non testé, on le remplace par un mock
                if (shouldMockBean(beanClassName)) {
                    mockBean(beanName, beanClassName!!, factory)
                }
            }
        }

        // Utilisé par le cache de Spring pour déterminer si le contexte peut être réutilisé
        override fun equals(other: Any?): Boolean {
            if (this === other) return true
            if (other !is ModuleTestContextCustomizer) return false
            return modules.contentEquals(other.modules)
        }

        override fun hashCode(): Int = modules.contentHashCode()

        // Vérifie si un bean doit être mocké : il doit faire partie d’un module "externe"
        private fun shouldMockBean(beanClassName: String?): Boolean {
            if (beanClassName == null || modules.isEmpty()) return false
            if (!isExternalModuleBean(beanClassName)) return false

            // Si le bean appartient à un des modules testés, on ne le mocke pas
            val isFromTestedModule = modules.any { module ->
                beanClassName.contains(".${module.packageName}.")
            }

            return !isFromTestedModule
        }

        // Remplace un bean par un mock Mockito
        private fun mockBean(
            beanName: String,
            beanClassName: String,
            factory: ConfigurableListableBeanFactory
        ) {
            val beanClass = Class.forName(beanClassName)
            val mock = Mockito.mock(beanClass)
            factory.registerSingleton(beanName, mock)
        }

        // Filtre les beans qui viennent bien d’un module applicatif Pleenk
        private fun isExternalModuleBean(className: String): Boolean {
            return className.matches("""com\.pleenk\.backend\.modules\..*""".toRegex())
        }
    }
}

2. Une annotation explicite : `@ModuleTest`

Pour transmettre la liste des modules ciblés à notre ContextCustomizerFactory, nous avons créé une annotation maison :

@ModuleTest([Module.NOTIFICATION, Module.PROFILE])
class NotificationIntegrationTest {
    ...
}

Et voici son implémentation (en Kotlin dans notre cas) :

@Target(AnnotationTarget.TYPE, AnnotationTarget.CLASS)
@Retention(AnnotationRetention.RUNTIME)
@SpringBootTest
@Transactional
@AutoConfigureMockMvc
@ActiveProfiles("test")
@ContextCustomizerFactories(ModuleTestContextCustomizerFactory::class)
annotation class ModuleTest(
    val value: Array<Module> = [],
)

Elle simplifie aussi le setup des tests : plus besoin de multiplier les annotations, tout est encapsulé dans @ModuleTest.

3. Une injection explicite, lisible et familière

Dans le test, il ne nous reste plus qu’à injecter les beans réels ou mockés, comme on le ferait avec @MockBean.

Pour améliorer la lisibilité des tests, nous avons aussi introduit une annotation @AutowiredMock.

Elle ne fait rien de plus qu’un @Autowired, mais permet d’exprimer clairement l’intention et d'aider à la relecture : "ce bean est injecté sous forme mockée dans le contexte."

Voici à quoi ressemble un test typique aujourd’hui :

@ModuleTest([Module.NOTIFICATION, Module.PROFILE])
class NotificationIntegrationTest {

    @AutowiredMock
    private lateinit var kycApi: KycApi

    ...
}

Ce petit détail aide beaucoup à rendre les tests plus lisibles, en distinguant clairement ce qui est "métier" de ce qui est "simulé".

📉 Résultats

Avec cette stratégie :

✅ Temps d’exécution divisé par deux pour nos tests d’intégration,
✅ Forte réduction du nombre de contextes créés,
✅ Meilleure homogénéité dans la façon d’écrire les tests.

Les développeurs écrivent des tests plus ciblés, plus lisibles, plus rapides.

La CI est plus stable. Le feedback est plus rapide. La confiance revient.

🚀 Pour aller plus loin

Cette stratégie est encore jeune, et nous continuons de l’améliorer.

Voici quelques pistes que nous explorons ou utilisons en parallèle :

Activer org.springframework.test.context.cache en DEBUG pour surveiller la création, la réutilisation et l’invalidation des contextes.
Éviter de charger certains beans internes inutiles lorsque les tests n’interagissent qu’avec la couche d’exposition.
Documenter la stratégie dans un guide d’équipe pour harmoniser les pratiques de test.
Développer un outil d’analyse des contextes Spring utilisés en test : L’objectif serait d’identifier plus facilement quels tests partagent un même contexte, quels tests en créent un nouveau, et quelles variations brisent la mutualisation. Ce type d’outil nous aiderait à rationaliser les contextes existants, mieux comprendre les zones d’optimisation, et favoriser la convergence vers une architecture de test plus homogène.

Partagez vos idées ou retours d’expérience en commentaire ou contactez-moi directement — je suis toujours curieux de découvrir d’autres approches !

🧭 Conclusion

En combinant une architecture modulitique, un contrôle précis du contexte Spring, et quelques outils bien choisis, nous avons trouvé un compromis durable entre vitesse, confiance et maintenabilité.

Si vous faites face à :

des temps de build trop longs,
des tests lents ou instables,
ou un manque d’uniformité dans les pratiques de test…

J’espère que ce retour d’expérience vous inspirera.

Il n’y a pas de magie, mais une stratégie réfléchie peut vraiment faire la différence dans la qualité de vos tests — et de votre quotidien de dev.

Configure Angular environment injector with Standalone Component

Martin Choraine — Thu, 05 Jan 2023 14:57:53 +0000

Since the arrival of Standalones Component with Angular 15, NgModules are now completely optional.

It is still necessary to declare providers to configure the root injector of the application.

With modules, it is possible to import other NgModules that define their own providers like HttpClientModule, BrowserAnimationsModule, RouterModule, etc.

Without the modules, it is necessary to declare these providers when bootstrapping the application. Fortunately, there are functions provided by angular to facilitate the declaration of these providers. For example:

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(routes),
    provideAnimations()
]})

Here is a non-exhaustive list of functions to set up regularly used providers :

Core

importProvidersFrom(): Sets up providers collected from a given module

Animation

provideAnimations(): Enable animation
provideNoopAnimations(): Disable animation

HTTP

provideHttpClient(): Sets up HttpClient service and configures it with some features

withInterceptors()
withInterceptorsFromDi()
withXsrfConfiguration()
withNoXsrfProtection()
withJsonpSupport()
withRequestsMadeViaParent()

provideHttpClientTesting(): Sets up a mocked HttpClient service

Router

provideRouter(): Sets up router functionality for the application

withInMemoryScrolling()
withEnabledBlockingInitialNavigation()
withDisabledInitialNavigation()
withDebugTracing()
withPreloading()
withRouterConfig()

provideLocationMocks(): Sets up a mocked router for testing

NgRx

provideStore(): Sets up the global store
provideState(): Provides additional slices of state in the store
provideEffects(): Sets up given effects
provideStoreDevtools(): Sets up debug functionality
provideMockStore(): Sets up a mocked store

Angular Universal with Standalone Component

Martin Choraine — Sat, 17 Dec 2022 19:52:32 +0000

With the arrival of Standalone Component with Angular 15, it is now possible to do without @NgModules entirely. This opens the door to new possibilities.

It is now possible to bootstrap an Angular application by providing an entry point component with a list of providers in the main.ts :

bootstrapApplication(AppComponent, {
  providers: [
    provideAnimations(),
    provideRouter(routes)
  ]
})

However, with this new approach, it is not yet possible to simply take advantage of the server side rendering (SSR) with Angular Universal because the function ngExpressEngine only takes a module parameter and not a component:

import express from 'express';
import { ngExpressEngine } from '@nguniversal/express-engine';

const app = express();

// Set the engine
app.engine(
  'html',
  // Bootstrap and render NgModule with express adapter for `@angular/platform-server`
  ngExpressEngine({
    // Take a module but we would like to provide component
    bootstrap: ServerAppModule
  }),
);

app.set('view engine', 'html');

app.get('/**/*', (req: Request, res: Response) => {
  res.render('../dist/index', {
    req,
    res,
  });
});

On the other hand it is possible to use manually the render function provided by @angular/platform-server.
This forces us to redo the work done by Angular Universal inside ngExpressEngine but it's the only possibility while waiting for the support of standalone component :

import express from 'express';
import type { Request, Response } from 'express';
import * as fs from 'fs';
import { renderApplication } from '@angular/platform-server'

const app = express();

app.engine('html', async (path, options, callback) => {
    const document = fs.readFileSync(path, 'utf-8')
    const { req } = { ...options } as {req: Request, res: Response};

    // Bootstrap and render a Standalone Component 
    const html = await renderApplication(AppComponent, {
      appId: 'server-app',
      document: document,
      url: `${req.baseUrl}${req.url}`,
      providers: [
        provideRouter(routes),
      ]
    });
    callback(null, html)
});
app.set('view engine', 'html');

app.get('/**/*', (req: Request, res: Response) => {
  res.render('../dist/index', {
    req,
    res,
  });
});

Thanks to the function renderApplication, it is possible to bootstrap an Angular component and render it on the server side while waiting for the full support of Standalone Component in Angular Universal with the provided function ngExpressEngine.