DEV Community: Prabhjeet Singh

Understanding Quarkus: Rethinking Java for Cloud-Native Applications

Prabhjeet Singh — Wed, 04 Mar 2026 10:55:56 +0000

Here is my naive attempt at explaining Quarkus and its ecosystem. In the previous post, we discussed what caused the need of a different approach to java web applications.

Before we begin, I want to clarify, that by no means, I mean to impose Quarkus' preference over Spring Boot. Infact, I get amazed by Spring internals, their design philosophy and seamless developer experience. Spring remains the primary choice for various usecases.

One such example is Monoliths and long-running services where initial startup time is less critical than sustained high throughput and stability over extended periods.

Also, Spring remains a developer's top choice, owning to convenience and large ecosystem while Quarkus ecosystem is small but growing.

Now let's comeback to the topic.

Here, you will be introduced to CDI.

CDI stands for Contexts and Dependency Injection. It is a standard Jakarta EE (formerly Java EE) specification that simplifies the development of complex applications and ensures object lifecycle management. Please refer here for more.

While both CDI and the Spring IoC container manage bean lifecycles and dependencies, they differ fundamentally in their underlying philosophy and technical implementation.

CDI is a specification which specifies a set of APIs that different vendors implement. Spring IoC on the other hand is a proprietary framework.

Quarkus uses a hybrid approach and implements its Dependency Injection framework on top of CDI. It is known as ArC. Refer this for more.

ArC is designed for build time analysis. This design choice is central to the Quarkus philosophy of moving as much processing as possible from runtime to build time to achieve extremely fast startup times and low memory usage.

Let's see what does that imply.

The entire dependency graph is analyzed and resolved during the build process and not at application startup.

Instead of using runtime reflection, ArC generates static proxies and direct bytecode invocations during the build, significantly reducing memory overhead and startup time.

This is enough if you want Quarkus to run in JVM mode, but, Quarkus has the option to go beyond build time analysis for optimizations and choose native mode if startup time is critical for an app.

Quarkus supports native mode. To accomplish this, it uses GraalVM.

When you compile to a native binary via GraalVM, all unused code is removed through ahead-of-time(AOT) compilation.

AOT compilation is a technique where your application's source code or bytecode is translated into native machine code before the program is run, typically during the build phase.

It is efficient in comparison to traditional Just in time(JIT) compilation where bytecode is translated to machine code at runtime.

Even though GraalVM's static world assumption is wonderful. At times, it may not be enough. Let's understand it with an example.

In JVM mode, reflection works normally.
In Native mode, reflection metadata must be known at build time.

Below is a CustomEvent class. when an event is received by the consumer, the json string message will need to be parsed to CustomEvent object using ObjectMapper, which requires reflection usage. GraalVM won't be able to use reflection at runtime.

public class CustomEvent {
    public String name;
    public String email;

    // No-args constructor is required for reflection
    public CustomEvent() {}  
}

To handle runtime failures due to reflection, we annotate the above class with @RegisterForReflection, which works fine with a substrate JVM and complete JVM is not needed.

We can safely say, that life comes full circle with GraalVM. Bytecode was introduced to replace native binaries as they were platform dependent and bytecode introduced platform independence. With GraalVM, we go back to native binaries as performance is crucial in cloud platforms.

Eclipse MicroProfile is a set of open-source specifications designed to extend Jakarta EE specifically for microservices. In Quarkus, these specifications are implemented primarily via the SmallRye Project.

Now, why are microprofile or smallrye needed?

Quarkus uses Smallrye implementations of microprofile specifications to make their features available to use on its platform.

The list of projects that Smallrye implements can be seen here. SmallRye implements the MicroProfile specifications (Config, Health, Fault Tolerance)

Below is example of Spring REST

@RestController
@RequestMapping("/hello")
public class GreetingController {
    @GetMapping("/{name}")
    public String greet(@PathVariable String name) {
        return "Hello " + name;
    }
}

Below is example of Jakarta REST(Formerly JAX-RS), which is Quarkus Equivalent of above. Refer here for documentation.
Please note, Jakarta REST is a specification which RestEasy Reactive implements which is used by Quarkus.

@Path("/hello") // This makes it a REST controller
public class GreetingResource {
    @GET
    @Path("/{name}")
    public String greet(@PathParam("name") String name) {
        return "Hello " + name;
    }
}

Though, SmallRye implements Eclipse Microprofile for Health, Metrics and Fault tolerance. RestEasy is used to implement Jakarta REST. In order to glue them together, we use RestEasy Rest Client.

Below is an example of Its usage, this can be understood analogous to Feign Client's usage in Spring.

@RegisterRestClient(configKey = "user-api")
public interface UserService {

    @GET
    @Path("/users")
    @Retry(maxRetries = 3, delay = 200) // <--- MicroProfile Fault Tolerance!
    @Fallback(fallbackMethod = "getCachedUsers") // <--- Fallback if all retries fail
    List<User> getByRole(@QueryParam("role") String role);

    // Default response if the external service is down
    default List<User> getCachedUsers(String role) {
        return List.of(new User("Offline User"));
    }
}

Below is an example of Spring bean creation of a class present in the classpath, and not in project source code.

@Configuration //@Configuration is a stereotype behind the scenes.
public class MyConfig {
    @Bean
    public ExternalService externalService() {
        return new ExternalService();
    }
}

Now Here is an Quarkus equivalent of the above example.

@ApplicationScoped // Just a quarkus equivalent of a Spring stereotype 
public class MyProducers {
    @Produces
    @ApplicationScoped // The scope of the bean being created
    public ExternalService externalService() {
        return new ExternalService();
    }
}

Now Let's mention some trivia. Below are some analogies to make working with Quarkus a little familiar.

Spring Annotations	Quarkus Annotations
`@Autowired`	`@Inject` `@Context`
`@Component` `@Service` `@Repository`	`@ApplicationScoped@Singleton` `@RequestScoped`
`@Value("${...}")`	`@ConfigProperty(name="...")`
`@Bean`	`@Produces`

While I feel it is already too much to pack in, I would like to touch upon a few other points.

Vert.x is an open-source, event-driven, and non-blocking toolkit for building reactive applications on the JVM.
Vert.x is the underlying reactive engine for Qaurkus. Refer guides on Introduction for Quarkus Reactive and reactive architecture.

The single line above has too much to cover. Let's understand this with a few examples.

Kafka traditionally uses a Java client that performs long-polling, which is also a blocking operation.
The Client: Quarkus uses the Vert.x Kafka Client. This is a non-blocking wrapper of the Kafka protocol designed to run on the event loop.
The Bridge: SmallRye Reactive Messaging sits on top of this Vert.x client. It uses Vert.x to handle the actual TCP connections and heartbeats to the Kafka brokers.
The Engine's Job: Vert.x manages the continuous stream of bytes from Kafka topics. It dispatches these as "events" to your @Incoming methods. Because it's Vert.x, you can process thousands of Kafka records simultaneously without spawning thousands of threads.
Refer here for more details.
Standard Hibernate (ORM) uses JDBC, which is fundamentally blocking—one thread per database connection. In a reactive app, this would kill the event loop.
The Driver: Hibernate Reactive replaces JDBC with Vert.x Reactive SQL Clients (like vertx-pg-client for Postgres).
The Execution: When you call session.persist(entity), Hibernate translates your Java object into a SQL query and hands it to the Vert.x SQL client.
The Engine's Job: Vert.x sends the SQL over the network using non-blocking I/O. It doesn't wait for the DB to respond; it immediately releases the thread. When the data eventually comes back, Vert.x triggers the callback that Mutiny then turns back into your result.
Refer vert.x and quarkus docs for details on the topic.
Vert.x EventLoop basically runs a thread to execute requests Non blockingly, and any tasks that need to wait are passed on to worker threads. This improves concurrent performance. Mutiny is a wrapper framework to execute non blocking I/O.
Spring Equivalent for Vert.x EventLoop is Project Reactor, differs slightly in design philosophy with an additional layer and different concurrency strategy.

To conclude, what is Spring's answer to Quarkus?

Spring has introduced a project called Spring AOT to improve performance in cloud native environments.

While Quarkus was built cloud first, Spting's images are slightly heavier as it was a project retrofitted to support cloud environments, poles apart from their autoconfiguration magic.

Finally, I hope you find it useful. Happy learning!

Why Quarkus?

Prabhjeet Singh — Tue, 24 Feb 2026 10:15:00 +0000

Since the advent of Spring Boot, it has been the De-Facto Backend Framework for Java Web Developers, thanks to its Developer friendly ecosystem, Autoconfiguration Magic and ready to code setup (Spring starters).

But, This is the age of cloud. Several other frameworks have mushroomed up, such as Micronaut and Quarkus.

We will talk about Quarkus, how is it different from Spring Boot, how cloud has made companies to rethink their strategy of choosing the framework, and what is Spring's answer to Quarkus.

For me, Quarkus was difficult. Despite Quarkus having similar ready to code setup, similar style of writing code, there was far less developer support and exhaustive documentation when compared to that of Spring boot's detailed documentation and other online forums.

Spring uses reflection heavily for autoconfiguration. It provides amazing developer experience.

Stereotypes, Component Scan, Configuration Classes declaring beans for classes outside the container using @Bean, Spring Data JPA interfaces, You name it, All of these are autoconfigured using reflection. Spring creates proxies at runtime to setup the Spring Container. This results in high usage of RAM and slower application startup.

To relate to this, lets go through a small example.
You might have seen BeanCreationException during Spring application start up , refer here for official documentation. This exception can occur due to variety of reasons. The main crux of the issue remains that Spring tries to resolve all the dependencies and create Beans in their respective scopes at application startup.

This can help you understand that Spring Beans are created at runtime, when the Application Context initialization is attempted.

But, the objects are created at runtime, why is that a problem?

Imagine a jar file that is included in your project's classpath and is not part of Spring container. You use @Bean to create a Spring bean. Behind the scenes, a proxy class is created at runtime, whose object is created and used by the Spring Container.

Let's take another example, you create an interface extending JPARepository<T>, and it magically provides implementations of multiple methods without a single line of code. How does that work in reality?

Well, again a Proxy class is created at runtime which actually implements those methods.

What does it tell you about Spring?

It tells us that Spring has a high memory footprint and that it is slow as Spring's runtime is computation heavy. Lets understand, why is it a problem.

Organizations have been moving to Microservices architecture because of its Reliability and Scalability. Systems are moving to cloud environments, reducing costs compared to On Premises Infrastructure and plenty of out of the box options for various use cases that these systems may need.

A monolith is divided into multiple microservices based on domain driven design principles. Each microservice has multiple replica instances and each replica gets its own computing and memory resources.

Imagine a system where hundreds, if not thousands of microservices run on cloud, each pod consumes memory and computing resources, the cloud bill increases multifold.

Now imagine an Alternative that is approximately 10x faster on average and uses 1/10th of memory resources, saves a ton of money, the trade off is Developer experience. This is what Quarkus brings to the table.

Here we discussed briefly how Spring works internally, what challenges does it face when integrating with cloud.

In the next part, we will discuss as to how Quarkus solves the cloud challenge and what Spring's team is doing to mitigate the same.

Deploy Angular SSR Application on AWS

Prabhjeet Singh — Thu, 04 Nov 2021 21:00:15 +0000

This post illustrates deployment process of Server Side Rendered Angular application, as can be guessed from the title.

Though, AWS has a dedicated service for deploying SSR applications, called AWS Amplify, but, as of writing this post, Angular Universal is not supported by Amplify. There are multiple other options available to achieve the required result. One of the more popular ones were the usage of a third party API, called Serverless. But, It was particularly challenging for me to find a clean and vanilla solution as I was juggling between different options.

Below, I will demonstrate the usage of AWS Elastic Beanstalk to deploy Angular SSR.

Open AWS Management Console and go to Elastic Beanstalk homepage. Click on Create Application.

Next, Give your application a name and click on Create

The console will need an environment, on which the application will run. Click on Create one now and subsequently select Web server environment as demonstrated below.

Now, select Platform and Platform branch for the application and environment created above. Refer to below image for the same.

On the same page, proceed with uploading the zipped dist folder of your Angular app which gets generated upon building your app in the local system. Now, click on Configure more options button.

On the next screen, click on the Edit button on the software tile.

Provide the Node Command considering dist as root. The path used in Node Command generally is of the folder where file to be run is placed.

Save the Configuration and click on Create App subsequently. Environment setup will take a few minutes, after which it will provide the Health status, logs and Deployment URL, as, can be seen below.

Hope, This article is useful for the readers. Please share and provide reactions if you like the blog.

AWS Lambda Basics: Part 2

Prabhjeet Singh — Mon, 15 Mar 2021 21:47:22 +0000

In the previous post, We explored the usage of AWS Lambda console. Here, we will discuss the actual implementation of Lambda Function for our use case, that is, thumbnail Generation from videos stored in S3.
Project repository can be found here for reference .

You use a deployment package to deploy your function code to Lambda. Lambda supports two types of deployment packages: container images and .zip files or jar files.

Lambda provides the following libraries for Java functions:

com.amazonaws:aws-lambda-java-core (required) – Defines handler method interfaces and the context object that the runtime passes to the handler. If you define your own input types, this is the only library that you need.

com.amazonaws:aws-lambda-java-events – Input types for events from services that invoke Lambda functions.

com.amazonaws:aws-lambda-java-log4j2 – An appender library for Apache Log4j 2 that you can use to add the request ID for the current invocation to your function logs.

Below are the Maven dependencies for these libraries with latest versions as of writing this post. Add these to pom file of Maven project.

  <dependencies>
    <dependency>
      <groupId>com.amazonaws</groupId>
      <artifactId>aws-lambda-java-core</artifactId>
      <version>1.2.1</version>
    </dependency>
    <dependency>
      <groupId>com.amazonaws</groupId>
      <artifactId>aws-lambda-java-events</artifactId>
      <version>3.1.0</version>
    </dependency>
    <dependency>
      <groupId>com.amazonaws</groupId>
      <artifactId>aws-lambda-java-log4j2</artifactId>
      <version>1.2.0</version>
    </dependency>
  </dependencies>

Building a deployment package with Maven

To build a deployment package with Maven, use the Maven Shade plugin. The plugin creates a JAR file that contains the compiled function code and all of its dependencies . Maven dependency for the plugin is below.

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>3.2.2</version>
        <configuration>
          <createDependencyReducedPom>false</createDependencyReducedPom>
        </configuration>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

If you use the appender library (aws-lambda-java-log4j2), you must also configure a transformer for the Maven Shade plugin. The transformer library combines versions of a cache file that appear in both the appender library and in Log4j.

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>3.2.2</version>
        <configuration>
          <createDependencyReducedPom>false</createDependencyReducedPom>
        </configuration>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <transformers>
                <transformer implementation="com.github.edwgiz.maven_shade_plugin.log4j2_cache_transformer.PluginsCacheFileTransformer">
                </transformer>
              </transformers>
            </configuration>
          </execution>
        </executions>
        <dependencies>
          <dependency>
            <groupId>com.github.edwgiz</groupId>
            <artifactId>maven-shade-plugin.log4j2-cachefile-transformer</artifactId>
            <version>2.13.0</version>
          </dependency>
        </dependencies>
      </plugin>

To build the deployment package, use the mvn package command. It will generate JAR file in target directory.

The AWS Lambda function handler is the method in your function code that processes events. When your function is invoked, Lambda runs the handler method. When the handler exits or returns a response, it becomes available to handle another event.

Handler interfaces

The aws-lambda-java-core library defines two interfaces for handler methods. Use the provided interfaces to simplify handler configuration and validate the handler method signature at compile time.

com.amazonaws.services.lambda.runtime.RequestHandler
com.amazonaws.services.lambda.runtime.RequestStreamHandler

The RequestHandler interface is a generic type that takes two parameters: the input type and the output type. Both types must be objects. When you use this interface, the Java runtime deserializes the event into an object with the input type, and serializes the output into text. Use this interface when the built-in serialization works with your input and output types.

// Handler value: example.Handler
public class Handler implements RequestHandler<Map<String,String>, String>{
  @Override
  public String handleRequest(Map<String,String> event, Context context)

To use your own serialization, implement the RequestStreamHandler interface. With this interface, Lambda passes your handler an input stream and output stream. The handler reads bytes from the input stream, writes to the output stream, and returns void.

Conclusion

AWS SDK for Java should be explored as per your use case and requirements. Also, There are advanced topics besides these like layers for AWS Lambda for further exploration.

Thanks for your time. Please share and provide reactions if you like the blog.

AWS Lambda Basics: Part 1

Prabhjeet Singh — Mon, 15 Mar 2021 17:17:08 +0000

Usage of Cloud Computing services for Software development has been on the rise in the recent years, given its cost effectiveness due to economies of scale and the flexibility it provides in capacity utilization.

AWS provides services for various use cases and requirements. AWS Lambda is one such service. Here, we will discuss it with the help of an example.

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes. AWS Lambda can be categorized as Platform as a Service(PaaS) or more specifically as Function as a Service(FaaS) as it delivers a framework for developers that they can build upon and use to create customized applications.

Lambda runs your code on a high-availability compute infrastructure and performs all of the administration of the compute resources, It is highly scalable, and significantly reduces the development effort for your use case.

In simple words, Lambda is event driven service, and can be triggered in response to changes due to concerned event and do not require CPU resources to be manually managed to invoke it whenever such event occurs.

Lambda supports multiple runtimes, which can be found here.
We will use Java 8 as runtime for our purpose. In Our example, whenever a video is uploaded in a AWS S3 (Simple Storage Service) bucket, the Lambda function is invoked which generates a thumbnail image for it and stores it in another bucket. You can find the source code in the repository for reference.

Please note, AWS S3 is a service which provides cheap secondary storage on cloud.

On AWS Lambda Console, click on Create Function

On the next screen, give Function name, choose runtime of your choice and create execution role. Lambda creates an execution role by default, with permission to upload logs to Amazon CloudWatch Logs.

Please note, Amazon CloudWatch collects monitoring and operational data in the form of logs, metrics, and events, and visualizes it using automated dashboards.

For our example, We create a role beforehand via IAM Console, and Use an existing role option and choose the already created IAM role from dropdown.

To be able to select an existing role for above, create an IAM role through IAM Console beforehand.

Click on Roles link in IAM console as below.

Click on create Role

Next, choose Lambda as Use Case and click on Next:Permissions as highlighted below.

Complete the forms that follow. For our purpose, the role will comprise below policies. AWSS3FullAccess policy allows Lambda to observe when a read/write event occurs in S3.CloudWatchFullAccess policy enables to upload logs to CloudWatch whenever Lambda Function is invoked.

Click on +Add trigger from below and select S3 from drop down that follows. After the trigger is added, Upload the source code as jar file from Upload button under Code tab as highlighted below.

The Handler function as highlighted above, has the syntax

<package>.<class>::<HandlerFunction>

Under Test Tab, create a Mock event of S3-put Type from the drop down list. A JSON Body will come up, which is passed to Lambda Function as a mock input, Modify the input JSON body and update awsRegion, bucket's name, arn and object's key as below.

Click on Invoke button. The Test event is triggered and success/failure logs are generated in AWS CloudWatch.

This gives us basic understanding of working with AWS Lambda Console. Actual Implementation of the Lambda Function will be covered in a separate blog.

Click here for part 2 of the blog post.

Angular i18n and Server Side Rendering with Angular Universal: Part 2

Prabhjeet Singh — Fri, 04 Sep 2020 15:40:20 +0000

In the previous post, we discussed, Angular's localize package and how we can run separate locale configurations.

Here, we will discuss Angular Universal, a technology that renders Angular applications on the server and how it helps angular app to be accessible in different sub-directories, depending on the language.

First, we run the below CLI command

ng add @nguniversal/express-engine --clientProject=demoproject

Here, clientProject is our existing Angular application.This command generates server-side app module, app.server.module.ts and Express web server, server.ts . This web server is used to decide, as to which locale will be rendered for a particular request.

Next, We modify the Express web server to add the following code.

app.get('*', (req, res) => {
//this is for i18n
  const supportedLocales = ['en', 'pa',...];//supported Locales 
  const defaultLocale = 'en';
  const matches = req.url.match(/^\/([a-z]{2}(?:-[A-Z]{2})?)\//);

  //check if the requested url has a correct format '/locale' and matches any of the supportedLocales
  const locale = (matches && supportedLocales.indexOf(matches[1]) !== -1) ? matches[1] : defaultLocale;

  res.render(`${locale}/index`, { req });
});

// Start up the Node server
app.listen(PORT, () => {
  console.log(`Node Express server listening on http://localhost:${PORT}`);
});

Through this modification, web server identifies the locale of the request, and renders the response accordingly.

You will notice that, in angular.json, server Configurations is automatically added once you run ng add @nguniversal/express-engine command, which looks like below.

"server": {
          "builder": "@angular-devkit/build-angular:server",
          "options": {
            "outputPath": "dist/server",
            "main": "src/main.server.ts",
            "tsConfig": "src/tsconfig.server.json"
          },
          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ]
            },"pa-Guru": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ]
            },
            "en-US": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ]
            }
          }

In package.json, add/modify below scripts according to your project to build and render all locales of your app.

"compile:server": "webpack --config webpack.server.config.js --progress --colors",
    "serve:ssr": "node dist/server",
    "build:ssr": "npm run build:client-and-server-bundles && npm run compile:server",
    "build:client-and-server-bundles": "ng build --configuration=pa-Guru && ng build --configuration=en-US  && ng run demoproject:server:production  &&  ng run demoproject:server:en-US &&  ng run demoproject:server:pa-Guru"

Finally, you can run the following command on Angular CLI to render locales through express server and change locales on runtime, depending on the request Url's baseHref.

npm run build:ssr && npm run serve:ssr

Benefits of using Server Side Rendering

Search Engines and social media sites rely on web crawlers to index your application content and make that content searchable on the web. These web crawlers may be unable to navigate and index your highly interactive Angular application as a human user could do.

Angular Universal can generate a static version of your app that is easily searchable, linkable, and navigable without JavaScript. Universal also makes a site preview available since each URL returns a fully rendered page.

We serve a static version of the landing page to hold the user's attention. At the same time, we'll load the full Angular app behind it. The user perceives near-instant performance from the landing page and gets the full interactive experience after the full app loads.

Motivation for using Angular i18n over other available libraries

First, we look at some of the disadvantages.

Angular i18n only works with one language at a time, you have to completely reload the application to change the language.
Angular i18n only supports using i18n in your templates for now.

But, its Advantages overpower the drawbacks.

Angular i18n supports ICU expressions (plurals and select).
The translation process is well defined, it is easy to detect missing translations and you can integrate that in your plans before deploying your app (extract, send to translators, merge).
It scales well, you never look directly at the files since you use a software for that, you can translate in x languages, you just need to extract once and create the translation files for each locale (which your professional tool should do for you)
It's super efficient because the app is pre-translated when it bootstraps, there's no extra work to apply your translations and * It works well with pre-rendering because of that since you merge the translations at build time, it means that it can support directives, components and other html elements, you can move them around in the different languages, or even remove them if needed
You don't need to worry about lazy loading, your bundles are translated at build time, and that includes your lazy loaded modules.

Thanks for your time. Please share and provide reactions if you like the blog.

Angular i18n and Server Side Rendering with Angular Universal:Part 1

Prabhjeet Singh — Fri, 04 Sep 2020 14:30:33 +0000

Internationalization is the need of most modern apps today.If your application is developed in Angular, there are various libraries available, which you can use to present the app in multiple locales and reach out to your audience in various regions of the world.

Angular provides a module to accomplish the same. However, it is complex in comparison to some of the other libraries available for the purpose, which, you can integrate with your app.

Here, We will learn as to how we can use Angular i18n and then, we will reason as to why it should be preferred over other strategies.

Use Angular CLI to run below command

ng add @angular/localize

This will allow you to use Angular's Localization in your project.

Next, we mark static text in template files for translations.

<p i18n >Welcome to Angular Internationalization!</p>

Mark element attributes for translations by using i18n-attribute with any attribute of any element. You also can assign a meaning, description, and custom ID with the i18n-attribute="meaning|description@@id" syntax.

Below is an example for the same.

<input  type="password" i18n-placeholder ="passwordPlaceholder|Placeholder for Password@@001"  placeholder="password" name="password" />

Please note that meaning, description and Id are optional, and Angular will auto generate an Id for you, if you don't mention one.

Angular provides Data transformation pipes that use the LOCALE_ID token to format data according to the locale.

DatePipe: Formats a date value.
CurrencyPipe: Transforms a number to a currency string.
DecimalPipe: Transforms a number into a decimal number string.
PercentPipe: Transforms a number to a percentage string.

To override the value of LOCALE_ID, add the locale parameter, for Example,{{amount | currency : 'en-US'}}
For a list of available Locales please refer to this.

Now, that we have prepared templates for translation, we can proceed to process them.

Extract Source Language File

Run the below command in Angular CLI.

ng xi18n

This creates a source language file named messages.xlf in your project's root directory.
The xi18n command can read and write files in three translation formats:

XLIFF 1.2 (default)
XLIFF 2
XML Message Bundle (XMB)

You can specify the translation format explicitly with the --format command option.

The messages.xlf looks like below.Notice that, it has translation units,with an Id generated for it. It also captures other metadata, like file location and line number.

<trans-unit id="7d1069de6c435fab320e5305cbaf139af1b0189f" datatype="html">
        <source>Welcome!</source>
        <context-group purpose="location">
        <context context-type="sourcefile">app/login/login.component.html</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>

Duplicate the messages.xlf file for each locale of your interest, and rename it.For example, you can rename it to messages.pa.xlf for Punjabi Language.

Please note that below code snippet has an additional target tag for translation of the source Language text.

<trans-unit id="7d1069de6c435fab320e5305cbaf139af1b0189f" datatype="html">
        <source>Welcome!</source>
        <target> ਜੀ ਆਇਆਂ ਨੂੰ !</target>
        <context-group purpose="location">
        <context context-type="sourcefile">app/login/login.component.html</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>

Similarly, add target tags to all translation units, in all the messages.lang.xlf files, corresponding to the number of languages your app may be supporting.

Define Locales in the Configuration

In angular.json , Under build's Configurations, define a configuration for each locale.Notice that, en-US is Locale_ID for English, You can refer here for other Languages.

"en-US": {
              "outputPath": "dist/browser/en",
              "baseHref": "/en/",
              "i18nLocale": "en-US",
              "i18nFormat": "xlf",
              "i18nFile": "src/messages.xlf",
              "i18nMissingTranslation": "error",
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "2mb",
                  "maximumError": "5mb"
                }
              ]
            }
          }
        },

outputPath signifies path in the root directory of the Project,
where this build will be generated, once run.Angular i18n supports aot by default. baseHref indicates the ref on the website, which loads the locale.

Similarly, Under angular.json's , serve Configurations, define serve configs for each locale. Here production indicates the default, and en-US indicates application served in English. You should include all the locales your app is supporting. demoproject is the name of the project here.

"production": {
              "browserTarget": "demoproject:build:production"
            },
            "en-US": {
              "browserTarget": "demoproject:build:en-US"
            },

Please note, that build and serve configurations are defined in angular.json for each locale, which indicates that, a separate build and deployment will be created and run for each locale.

Now, you can build and run the application in your desired locale, by the following command on CLI. Below is an example for Punjabi Language.

ng build --configuration=pa-Guru && ng serve --configuration=pa-Guru

In case, you want multiple locales to be running in parallel, add the --port switch with serve command, to serve the app on a different port for a different locale.

This gives us a basic implementation of Angular i18n, with separate build and deployment for each locale. But,Our goal is to be able to switch the locales from the Url itself. Also, it is important to understand the motivation to pick angular i18n mechanism instead of other simpler available libraries.

This will be covered in a separate blog post. That is where Server Side Rendering comes into play.

click here for Part 2 of the blog post.