Forem: Martin Danielson

Micro-frontends with AI - it solves everything

Martin Danielson — Sun, 26 Apr 2026 12:10:53 +0000

This article covers a few important tips to consider before choosing micro-frontends for your tech stack. I also cover what other tools fit well with it (AI) but most importantly what you need to always practice no matter if you choose micro-frontends or another tech to create modularization.

"Understanding the problem and finding a solution for that specific problem is vital"

First of all, let me explain the problem I was trying to solve. Understanding the problem and finding a solution for that specific problem is vital in order to not end up with a platform with bloated features and unnecessary complexity.
Reading up on micro-frontends can also be a little confusing since it can solve a number of problems and there are a lot of different - both in flavors and in numbers - actors in this space.
You have to be careful - as always, when adopting new technologies - trusting the blatant claim that “this tech is the best”; especially when picking a micro-frontend framework.

"We actually spent most of the time fixing bugs in our testing framework"

What we initially set out to do was to do legacy displacement of tech, meaning we had an existing platform that over the years had become a “house of cards” and accumulated so much technical debt that it created more problems than we could handle.
We actually spent most of the time fixing bugs in our testing framework for the application - yes, read that sentence again; it was that bad - than actually delivering new features or value to the customers.

"avoid a “big bang” and slowly transition to the new technical platform"

So, we wanted to replace and re-write parts of the application to avoid a “big bang” and slowly transition to the new technical platform. This is almost a must when trying to convince stakeholders of going down this path.

This did not necessarily require micro-frontends, it could be done way easier using normal routing and sane code structure. Just some good old hard work, simply fixing the existing code. However; since there were so many issues with the code-base and after talking with some colleagues who had tried out micro-frontends recently, we decided to give it a try.

"what micro-frontend tech to use"

Now we needed to decide what micro-frontend technology to use. And here is where it gets a bit confusing - or even messy at times - and you really need to pay attention how the framework is implemented and possible caveats with the solutions.
I will not attempt to summarize the whole landscape in this article - that is too huge of a topic to cover - I am trying to get another point out there. But I will still name a few things to consider for those of you who are currently considering implementing micro-frontends for your organization.

Micro-frontends is all about running smaller components inside a single container. Separating these components and making them runnable on their own is a lot what this technology is trying to provide. But trust me it is very complicated to solve this in the JavaScript eco system with how bundles are handles, dependencies are loaded and how code is shared and not isolated.
I rarely express that something in software engineering is complicated - but the orchestration of multiple (at least in our case) independent frontend frameworks, all co-existing in the same single page application, has so many areas where it can go wrong I would carefully consider the need before recommending this to anyone. As I said earlier, make sure you truly understand what problem you are trying to solve.
Comparing this to micro-services i.e. tt is way more complicated since everything needs to run in the same browser on a client - where-as micro-services all run independently and then just deliver the result to a client.
Client vs. server side capabilities. In recent times the popularity of meta frameworks that both render on client & server has grown a lot. Micro-frontends is somewhat of an old technology actually and many of the frameworks was built with client side only at mind. So, you need to consider this because orchestrating this alone is hard - adding hydration between client & server adds exponential complexity. Not to mention having to deal with all the CORS and security rules in modern browsers. If you can, opt for a framework that has server side rendering.
Isolation. It is pretty funny to me that still to this day true isolation can only be achieved with the (in)famous IFRAME. We would probably have considered using it to some extent if it was not for the issues related to privacy. As with cookies and shared domains many browsers have increased the security by disabling a lot of what can be done using these technologies; so unfortunately it was not an option for us.
So, micro-frontends does not come with true isolation. Since it is living in the same document there is noting that prevents one component from affecting another through either CSS "bleed-out" or the use of JavaScript to reach different parts of the document.
This can be controlled with careful implementation though, i.e. using prefixed CSS rules or even more modern things such as layers - but there is no guarantee and since we planned to gradually transition - and by this co-existing with an extremely badly written legacy application - it took a lot of efforts to just get basic boundaries set up.
Avoid mixing multiple JavaScript frameworks. We wanted to change from Angular to React but you can save a lot of head-ace if you do not need to support multiple (any) frameworks. There are simpler implementations that provides most of the micro-frontend capabilities if you can share frontend technology.
This is another thing I would advice against; if you are choosing micro-frontends as a means to be able to run any framework. This might sound like a good idea in order to give autonomy to teams and allow them to chose technologies freely - but this will create a lot of extra complexity since the frontend frameworks needs to be supported by the micro-frontend framework and there are no guarantees that a framework will be maintained and able to support any of the new features a frontend library decides to implement. We are actually planning to use our micro-frontend setup to move over to React only, as a transition, and then stick with React once all legacy has been replaced.
Configuration heavy and lack of maintenance. To keep it short; there is a lot of configuration involved solving all things related to micro-frontends, CORS, CSP, deployment, building, runtime etc. Be prepared to really dig deep in most likely multiple build tools in order to set everything up correctly.
Also, remember that the micro-frontend technology you choose will become a sort of single point of failure. And there is nothing to guarantee that it will be maintained.

Wow, this did become a lot more information on the implementation than I intended but these are all important learnings so I think it is good to include nonetheless.

Part 2 - super-charge your AI capabilities

But, back to my original trail of thoughts. So, now we had decided on micro-frontends and we also had our pick of the framework (single-spa). This is the point where we started to see an emerging problem replacing only parts of the old application with new micro-frontends. Let me try to visualize this more clearly.

Imagine a mail client, with a top menu, side bar and then a reading pane. In the micro-frontend container (the “host” or “root” if you will) I can say that the top menu should be served from micro-frontend A, the side bar from micro-frontend B and the reading pane from micro-frontend C. Easy. But, what if we wanted to replace only the attach file component inside the reading pane, while keeping the rest from micro-frontend C?

Do you see the problem?

This is exactly what we wanted, we wanted - to replace the smallest parts of our legacy application but still use everything else from it; and we needed a way to do that. Luckily single-spa has something for just this case. It is called Parcels and basically what it does is it creates a placeholder in the legacy application that it will then inject the micro-frontend in. Looking at the solution it was not really rocket science or anything but it was something we did not really think of initially and we were happy (lucky) to see it was part of the technology we had chosen.

"Now we had a framework where we could surgically replace any parts of an old application"

So now we got to work. And with the aid of AI we started to really quickly replace parts of the legacy platform. With the power of AI we dared more and was able to be extremely productive and fast transitioning to the new platform.
Not only did we replace components we also gave them a touch up in both functionality and visuals. And this is what I wanted to emphasize on in this article - finally - that actually what made this endeavors so successful and powerful is actually three (3) things - that all are equally important. We have micro-frontends on one end, then AI on the other - can you guess what is the third?

"The problem with AI is that doing large scale re-factoring very error-prone and takes A LOT of time"

It is the size of the changes. Being able to replace smaller parts of the legacy application made AI actually usable. One could have argued earlier that one approach to solve the problem we had was to tell AI (without micro-frontends) to re-write the entire application in a new technology.
The problem with AI is that doing large scale re-factoring very error-prone and takes A LOT of time.
We have had experiences where we have tried just to update certain parts to TypeScript strict or just upgrade from one version of .NET to another and it took us weeks to complete (to be honest some parts is still on-going).

But, when the things we are replacing are small, then AI can focus a lot more and we can make sure we have feature parity with less effort. And since we are free to pick and choose any framework for each micro-frontend we can guide AI to give us a solution that is well written and a lot easier to maintain and change in the future.

I did not actually know how important the word "micro" was in micro-frontends but now I see the whole picture and I hope I could inspire others to take the leap, go through the initial hassle and time to set this kind of architecture up. Because it did take some time to get everything working just right - but now I have no regrets at all going down this line.

If you have any question regarding the actual implementation or want me to dive deeper into a topic - please let me know. I would gladly like to share.

Will AI take over my job as a software engineer

Martin Danielson — Sun, 26 Apr 2026 07:10:29 +0000

This article expresses some of my thoughts as a senior software engineer working as a consultant in an era of AI where agents is doing “all the work” and the job market is fluctuating, the world is in crisis and there is a lot of uncertainty and fear about what the future holds.

"I cannot not judge anything unless I know what it actually is"

I am a curious person. I have most my life spent the better part of it exploring new things - both things that intrigue me but also things I fear. My reasoning is that I cannot not judge anything unless I know what it actually is. This kind of curiosity can be a little dangerous too - but thankfully I am also pretty strong-willed so I have managed to get out from exploring things that might not be so good for me (addiction i.e.).

"there is a lot of fear going around now that AI will replace many tasks that currently humans do"

This is not one of those things though - but there are many fears involved with AI. For one, I grew up watching all the Terminator movies so I know that eventually they will come to life and kill me. Maybe not, but there is a lot of fear going around now that AI will replace many tasks that currently humans do. Another fear tied to AI, from one practicing it daily in my work, is that I will stop learning and become even less attractive to the job market since I am no longer acquiring knowledge - in a way they are both grounded in the same fear I guess.

This is my take on it, and please understand I am just starting out in my venture with AI and this is just me thinking out loud. I am actually not using AI to write this. Nor am I trying to earn clicks or subscriptions to any channel. I am however interested in hearing what other people in a similar situation is thinking about this.

"I am now not writing any code at all , I have become what the media calls a “prompt engineer”"

As I started saying I have a need to understand everything, especially if I am to express negative views on a subject. So, I have for the past 4 weeks dove deep into using AI in my professional life. I have been dabbling on and off with it over the past year and a half though - but not like this. I am now not writing any code at all , I have become what the media calls a “prompt engineer” - or if you want to put a negative spin on it a “vibe coder”.

"what is my worth now when I am using a tool to cover all the skills I have so proudly been bosting in my CV for the past 30 years"

With this I keep thinking along the lines of “what is my worth now when I am using a tool to cover all the skills I have so proudly been bosting in my CV for the past 30 years”. If I am letting a tool do all the work I used to do - writing good code, organizing it neatly, reading up on new tech, trying to learn how things work in order to teach others, planning infrastructure and thinking about performance and scalability - then why would someone pick me over someone else with the same tool? I mean, I feel that all my time I have spent studying and learning to become a great software engineer is sort of thrown out the window. Anyone can do it - no seriously, I truly believe anyone could literally do it.

"I am sort of an architect"

To this I don’t really have any comforting answer. AI today is not all there, it does mistakes, it lacks context and sometimes critical thinking and it needs a lot of guidance. This somewhat puts me at ease for the short term since this is where all my knowledge still come into play. I can steer the AI to make better choices where it is lacking. I can immediately spot overcomplicated code, I can imagine how this would be maintained and make sure that AI produces something that is easy to evolve and take over. I could tell it to write tests and not forget to lint the code. I am sort of an architect in a sense - telling it what I want out of it from a technical and maintainability point of view.

"I am allowing AI to take over, write all the code"

So, I still get to use some of the knowledge I have. But I think there is only a matter of time before AI understands these aspects too and truly will be able to produce code equally - if not better - than someone with 30 years of professional experience within software engineering. As a result of this, I am trying to evolve my thinking on this subject. I am letting go of what I have held so dear - my knowledge and experience. I am allowing AI to take over, write all the code and trying to figure out something that it could not replace. This is a bit scary indeed, and there is a lot of imposter syndrome floating around.

"I am actually enjoying this very much"

But I want to highlight something here. This is fun also. First of all I am still learning new things. And I get to be super creative to a level I have not been able to before. I mean, I have been able to write new features, both requested but also things that I just come up with in the moment, super fast and with a lot of freedom to explore. I can think of an idea, make AI implement it and then throw it away and do something else without feeling I am throwing away 2 days of CSS tinkering and coding. I can try out a new framework on a whim and see it in action instead of spending hours on researching it and sifting through flame war articles about which tech is better than the other’s. I am actually enjoying this very much and it makes it a lot easier to handle the imposter syndrome and still find value.

Actually, this is something I have long lacked in my professional career. To feel truly productive, daring and exploring possibilities. Not just being told what to do, maybe AI is enabling this for me, maybe this is a really a blessing and not a curse.

What do you think? Is AI just a passing thing, is our fears unfounded? Do you have any other interesting thoughts on the subject? Let me know please and have a wonderful day.

Generate HTML as PDF using Next.js & Puppeteer running on Serverless (Vercel/AWS Lambda) Martin Danielson

Martin Danielson — Fri, 24 Jan 2025 22:10:35 +0000

I wanted to share my experience of generating PDF’s from web pages using Puppeteer, deployed on Vercel (or AWS Lambda). While there are many resources available on similar topics, I found that none of them provided a complete solution. Since this is a common use case — whether for invoicing, scraping, or testing — I hope my insights can help others facing similar challenges.

Background: One of my businesses rents out a space in a venue, and while we only generate about 30 invoices per year, it can become tedious work and prone to errors. So, I decided to build an app to automate invoice generation based on HTML (which is easier for me to work with since I am familiar with front-end development). I also needed the system to send invoices by email, manage different billing periods, and be easy to extend with new customers.

Rather than focusing on all the logic behind calculating when and how to send invoices, I will focus here on how I set up the PDF generation and hosted the entire solution on Vercel. Mind you that all of this is from memory, so I could not provide exact error codes and might have missed some details.

Setting Up PDF Generation with Puppeteer

I created a simple Next.js page to render my invoices. The next step was converting the HTML of a page into a PDF. I have used Puppeteer before, and after some research, I found it was still one of the best options for this use case.

Here’s the basic code to generate the PDF from a URL:

import puppeteer from "puppeteer";
...
const browser = await puppeteer.launch();
const page = await browser.newPage();

await page.goto("http://localhost:3000/invoice");
await page.pdf({ path: "a.pdf" });

await browser.close();

Issue with Puppeteer and Serverless limits

The code above worked perfectly locally, but when I deployed it, the endpoint returned a 500 error.

Puppeteer relies on Chrome to render pages, and the Chrome binary included in the Puppeteer package is too large for serverless functions due to size constraints.

After some digging, I opted to use puppeteer-core — which lets you specify your own browser — together with a version of Chromium called @sparticuz/chromium-min, which is tailored for serverless environments. However, even this was too large to upload directly to my project (over 50MB).

Solution: Using external storage for Chromium

The solution was to host the smaller Chromium binary in an external Blob storage (same I used to save the PDF’s in) and reference it during runtime. Here’s how I configured Puppeteer to use this custom Chromium version:

const browser = await puppeteer.launch({
  args: chromium.args,
  defaultViewport: chromium.defaultViewport,
  executablePath: await chromium.executablePath("URL_to_chromium-min_tar"),
  headless: chromium.headless,
});

Additionally, to ensure that Puppeteer runs in development with the standard Chromium version (useful for debugging), I used this code:

import { executablePath } from "puppeteer";
import puppeteer from "puppeteer-core";

const browser = await puppeteer.launch(
  process.env.NODE_ENV === "production"
    ? {
        args: chromium.args,
        defaultViewport: chromium.defaultViewport,
        executablePath: await chromium.executablePath("URL_to_chromium-min_tar"),
        headless: chromium.headless,
      }
    : { executablePath: executablePath() }
);

Handling timeouts and optimizing the process

When running in a serverless environment, Puppeteer can be slow due to the overhead of downloading, unpacking and loading Chromium.
Just loading the browser took about 15 seconds, which led to timeouts, not counting to load a page and generate the PDF’s.

Vercel’s default serverless timeout is 10 seconds. This can easilly be extended to 60 seconds on their free tier.

export const maxDuration = 60;

However; this was not enough to generate a number of PDF’s so I also made two optimizations:

1. Singleton pattern: Reused the browser instance across multiple PDF generations to reduce overhead.
2. Optimized waitUntil parameter: I switched from networkidle2 (which waits for all network activity to finish) to the default load event, which is more efficient for my use case.

Additionally, instead of writing the PDF to disk and reading it back, you can use the buffer that is returned and pass it to Vercel’s Blob storage:

const buffer = await page.pdf();

Bonus Tips

Set Extra HTTP Headers for Vercel: When running on Vercel, your resources are protected on some domains (i.e. your priview environments). This led to me generating a lot of PDF’s of the Vercel login page.

page.setExtraHTTPHeaders({
  "x-vercel-protection-bypass": process.env.VERCEL_AUTOMATION_BYPASS_SECRET,
});

CSS for PDF Layout: To ensure the PDF renders in a print-friendly format and without margins:

const buffer = await page.pdf({ preferCSSPageSize: true });

@media print {
   @page {
     size: A4 portrait;
     margin: 0;
   }
}

Securing Your Endpoint: I tried securing the API endpoint using the Authorization header, but Vercel has an issue with forwarding headers when using rules. The authorization header is passed under x-vercel-sc-headers, but it’s not guaranteed to work reliably. I decided to leave it for now.

Final thoughts

If you’ve made it this far, thank you! I hope this guide helps anyone trying to generate PDF’s from HTML using Puppeteer in serverless environments like Vercel.

I welcome suggestions and tips. Also if you feel that I did not credit some resource or author please contact me and I will accredit accordingly.

Credits to resources I used to figure all this out: