"Our end users don’t care whether your app is a monolith or micro-frontends—they just want an app that loads expeditious and solves their quandaries. " ✌ Knowledgefactory.net[Sibin]
Today we are going to discuss Micro-frontend architecture, Maybe most of the latest digital products are adopted microservice architecture on their back, companies are blissful and developers are relishing their works, from all the angles technical experts are verbally expressing microservice architecture is fine.
But, the Front end part is still monolithic. It's the right time to think about Micro Frontend architecture
What is Micro-frontend architecture?
Micro-frontend architecture is a design approach in which a front-end app is decomposed into individual, micro-apps working loosely together. The micro-frontend concept is vaguely inspired by, and designated after, microservices.
A simple micro-front end architecture
Some of the benefits of the micro-frontend pattern:
Independent development teams can collaborate on a front-end app more easily.
Micro frontend codebases can be smaller, more manageable
Micro frontends promote reusability across process and case management
Micro frontends help you rapidly develop different views of your processes relevant to each person’s role
Micro frontends are sections of our UI, often consisting of 'n' number of components, that use frameworks like React, Vue, and Angular to render their components. Each micro frontend can be managed by a different team and may be implemented utilizing its own framework. It is practical and suggested to utilize just one framework for all your micro frontend, albeit you may integrate additional frameworks when migrating or when experimenting.
Each micro frontend has its own code repository, its own package.json file, and its own build implement configuration. As a result, each micro frontend has an independent build process and an independent deploy / CI. This generally betokens that each repo has expeditious build times.
Are micro-frontends the right cull for you?
There’s an abundance of substantial reasons to adopt a micro-frontends architecture, but they do integrate an abundance of involution to your front-end ecosystem. Afore you go ahead and modify your app to utilize micro-frontends, ascertain that you take a moment to evaluate if the involution is worth the payoffs that micro-frontends give you. Here are two reasons why you might adopt a micro-frontends architecture.
You have a huge app with a ton of complexity
You have multiple teams contributing to our app, and each has its own deployment cycles.
Our end users don’t care whether your app is a monolith or micro-frontends—they just want an app that loads expeditious and solves their quandaries. Granted, something like micro-frontends might avail us meet that goal in a more scalable way, but at the end of the day, the utilizer should feel like they are utilizing a single application.
The Bit is a scalable and collaborative way to build and reuse components. It's everything you need from local development to cross-project integrations.
If you take a look at the bit.dev homepage you will notice that it is composed of independent components that are built by different teams, in different codebases, and are all integrated together to create a cohesive product.
single-spa is a framework for bringing together multiple JavaScript micro frontends in a frontend application. Architecting your frontend using single-spa enables many benefits, such as: Use multiple frameworks on the same page without page refreshing (React, AngularJS, Angular, Ember, or whatever you're using)
SystemJS is a module loader that can import modules at run time in any of the popular formats used today (CommonJS, UMD, AMD, ES6). It is built on top of the ES6 module loader polyfill and is smart enough to detect the format being used and handle it appropriately.
We should use Webpack to generate a bundle for production or development, let's say Webpack helps you to generate a folder called dist and a file main.js within this folder. This is the result of all of your JavaScript code that you normally have in a folder called src
The more we add code into our src folder the heavier is this main.js file that Webpack generates. Remember that this is the file you take to our production environment and clients download in their browsers, if this file is heavy that means it will take longer for the users to load your page.
That means we care about the size of our bundle but we also want to keep adding new features to our projects
With Module Federation we can import remote Webpack builds to our application. Currently, we should import these chunks but they would have to come from your same project. Now, we have these chunks (Webpack builds) from a different origin, which means, a different project!
Here's a simple explanation: User Interaction : The User interacts with Postman to send requests (e.g., test API endpoints of the Spring Boot application). Postman : Postman sends requests to the Spring Boot Application . Spring Boot Application : Postman calls the Controller in the Spring Boot application. The Controller handles the incoming requests and delegates the logic to the Service layer. The Service interacts with the OpenAiClient to perform the actual communication with OpenAI. External System : The OpenAiClient sends the request to the OpenAI API to get a response. The response flows back through the layers ( OpenAiClient → Service → Controller ) and is returned to the user via Postman . To integrate ChatGPT into a Spring Boot application, you can use the OpenAI API to send requests to ChatGPT and get responses. Below is an example of how you can create a simple Spring Boot service that integrates with OpenAI's API to use ChatGPT. 1: Set up your Spring Boo...
The image illustrates an orchestration-based saga pattern for handling distributed transactions across two microservices: Order Service and Customer Service . This approach uses a central orchestrator (the saga) to coordinate the interactions between services and ensure consistency. Here’s an end-to-end explanation of the flow: 1. Order Creation Request A client sends an HTTP POST /orders request to the Order Controller in the Order Service . The Order Controller is responsible for receiving the request and delegating it to the Order Service . 2. Order Creation in the Saga The Order Service invokes the create() method in the Create Order Saga . The Create Order Saga is the orchestrator responsible for coordinating the steps involved in completing the transaction. 3. Order Aggregate Creation The Create Order Saga initiates the creation of the Order aggregate in the Order Service . The Order aggregate represents the state and business logic of the order. 4. Reserve Credit Com...
In this section we will develop a full-stack application that is a basic Student management application using Spring Boot 3, Angular 15, Material and PostgreSQL. You could download the source code from our GitHub repository, the download link is provided at the end of this article. After completing this tutorial what we will build? We will build a full-stack web application that is a basic Student Management Application with CRUD features: Create Student List Student Update Student Delete Student Technologies used: Spring Boot 3+ Spring Data JPA PostgreSQL Java 17 Angular 15 Angular Material UI 1. Backend Development Creating a Spring boot web application First, open the Spring initializr: https://start.spring.io/ Then, Provide the Group and Artifact name. We have provided Group name com.knf.dev.demo and Artifact spring-boot3-postgresql-crud-app . Here I selected the Maven project - language Java 17 , Spring Boot 3.1.4 (latest) and add Sp...
Comments
Post a Comment