DEV Community: Siri Shamendra

Evolution of Microfrontends 🚀

Siri Shamendra — Wed, 17 Apr 2024 23:03:18 +0000

Hello Son 👶🏻,

I know that you are a genius creator of things using Legos.

Imagine your traditional front-end application as a non-composable Viking City castle toy. There you get what the toy company built for you and you cannot modify or change later as you wish.

But what if you build your castle with 5 other friends at the same time as you wish using Legos? These legos might have been designed by another toy company to be compatible with the original Legos you have and one of your friends is using that to build part of your castle.

So consider your Lego work above as our micro frontend. This shares the same concepts as the micro-services. People understood that by using this they could achieve below.

So, the advantages of using micro-frontends are:

Faster Changes: You can make updates or add new features more quickly because you're only working on one small part at a time.

Independent Development: Different teams can work on different parts of the frontend without stepping on each other's toes. They can develop and deploy their parts independently.

Easier Maintenance: If something goes wrong in one part, it's easier to find and fix the problem without affecting the rest of the frontend.

Scalability: As your project grows, it's easier to scale because you can add new features or modules without having to rebuild the entire frontend from scratch.

Let's explain this to your Dad 🧔🏻‍♂️!

...

Evolution 🚀:

GW = Gateway / FE = Frontend / BE = Backend

Monolithic: In the early days of web development, applications were built as monoliths. This means that both the frontend (the user interface) and the backend (the server-side logic and database) were tightly coupled together in a single codebase. Making changes or adding features required modifying the entire application, which could be time-consuming and risky.

Frontend + Backend Separation: As web applications grew in complexity, developers began separating the frontend and backend components. This separation allowed for more specialized teams to work on each part of the application independently. The frontend communicated with the backend through APIs (Application Programming Interfaces), enabling better scalability and flexibility. However, the frontend itself often remained monolithic, making it challenging to scale or modify without impacting the entire frontend.

Microservices + Frontend: With the rise of microservices architecture, developers started decomposing the backend into smaller, independently deployable services, each responsible for a specific business function. This approach improved scalability, fault isolation, and development agility. However, the frontend remained relatively monolithic, presenting challenges in coordinating frontend updates with changes in the microservices architecture.

Microfrontend + Microservices: The evolution culminates in the adoption of microfrontend architecture alongside microservices. Microfrontend architecture extends the principles of microservices to the frontend layer, allowing frontend components to be developed, deployed, and scaled independently. Each micro-frontend represents a distinct part of the user interface and can be owned and maintained by separate teams. This approach enables greater flexibility, faster iteration times, and improved autonomy for frontend development teams.

Most importantly we need to remember the decision to make your frontend a micro-frontend is based on a lot of facts including your requirements and the evolution of the application in the future or now with the priority in mind.

If you feel that you want to dig more into concepts read the article at Martin Fowler's website here.

🏋️‍♂️

Enough talking! Let's make learn by doing. We are going to build a real-life micro-frontend with Next.js, Nuxt.js, and the latest Angular Framework in my next article. Dad's will love it! Stay tuned!

Next.js is a React framework / Nuxt.js is a Vue Framework

Tutorial Hell : 5 steps to get away

Siri Shamendra — Sat, 06 Apr 2024 22:30:43 +0000

About in5Steps series:
Designed for humans by keeping memorization in mind. Read more.

Have you ever found yourself feeling frustrated after scouring through numerous articles in search of a solution on Google? It's a common experience many of us encounter.

Once you formed a habit you become a slave of your own habit. I am pretty sure that most of us who started with Google, might click on at least 2 or 3 search results with the shift key to open up in different tabs and go through one by one. Then we see different approaches or expired documents that is totally irrelevant to what we need today. Because of that I do look at the Date of the article before I click on the search result.

For an example look at the example below. You will get the legacy documentation at the first and a one outdated result among first few results. If you start with knowing less, there is a high chance to explore all content and learn something outdated first.

Then you have to unlearn it first to learn the right thing. Its expensive.

Tutorial hell refers to the habit of constantly consuming tutorials without applying the knowledge gained or taking meaningful steps towards practical application or independent problem-solving. Escaping tutorial hell requires a shift in mindset and approach.

Follow these 5 smart ways to make it right.

1. Write down what you really want:

Clearly define your objectives and requirements for the authentication system you want to build.

Someone said once "If you write it down, you can make it happen". So writing it down helps you to teach yourself a discipline to focus on nonsense and avoid reading something else as a tutorial.

2. Talk to few experts:

Engage in discussions with knowledgeable individuals in the field of your learning scope.

Listen to the people who are doing it in real life for sometime are the best people to talk about that. So listen to real doers before you learn that is the best idea that you can do easily.

3. Read what is that community is suggesting:

Stay updated with community forums, blogs, and resources to understand the latest trends, tools, and best practices.

TIP: Usually official documentations include some great examples with tutorials. But some documentations are still like a book of references.

This is one of the most important things in this 5 steps. Even though you have to limit the resources for tutorials, you shouldn't limit your readings to grab the knowledge about what is happening in the industry at the moment. News and Learning something by following tutorials are two different things.

4. Pick the best after the above exercises:

Evaluate the suggestions and feedback received from experts and the community to make an informed decision on the most suitable approach and technologies. Then you are able to finally find the best tutorial and focus on it. Make your own short note. We have wrote many things in the books when we don't use computers few decades ago. Writing something down makes our memory more strong. So I suggest to write it down.

Limiting your source of learning to few resources make it a more straightforward and avoid the tutorial hell nicely with a discipline in our mind.

5. Repetition, Repetition and Repetition:

Focusing on iterative improvements and learning from experiences to avoid getting stuck in tutorial-based learning cycles.

BONUS OUTSIDE THE HELL:

Many of us used to follow video tutorials. But sometimes the tutorials with only interactive content works really well. I am following educative for sometime to learn different things and that works nicely with me. So choosing the right learning method is also very important.

Explain AWS Lambda to your EC2 guy in 5 steps

Siri Shamendra — Mon, 11 Dec 2023 21:36:32 +0000

About in5Steps series:
Designed for humans by keeping memorization in mind. Read more.

Step 1: EC2 Instances vs. AWS Lambda

EC2 instances are like owning dedicated office spaces, where developers manage the infrastructure, scale manually, while AWS Lambda operates as flexible co-working spaces, where infrastructure management is abstracted, scaling occurs automatically, and developers focus solely on executing specific tasks with code functions.

Step 2: Deployment and Scaling Differences

Deploying applications on EC2 involves configuring servers, managing load balancing, and manually scaling resources, whereas, with AWS Lambda, developers upload functions directly, allowing for automatic scaling and minimal configuration, adjusting resources based on incoming events or requests.

Step 3: Cost and Resource Management

EC2 instances bill based on allocated resources, requiring manual scaling adjustments and steady cost regardless of usage, whereas AWS Lambda follows a pay-per-use model, charging only for function execution time, optimizing resource allocation and cost-efficiency.

Step 4: Application Architecture

EC2-based architectures demand fixed structures with developers managing infrastructure, databases, and application logic, whereas AWS Lambda facilitates a modular, microservices-oriented approach, abstracting infrastructure concerns and enabling seamless integration with other AWS services.

Step 5: Flexibility and Development Focus

EC2 development often involves juggling server configurations, diverting attention from pure code development, while AWS Lambda allows developers to concentrate solely on writing efficient, task-specific functions, eliminating server management burdens and streamlining development efforts.