Coding

Micro Frontends at ShareNow

As a product owner, I am happy about the heavy lifting my developers do in my team. Whenever I see great robustness of our product in this constantly changing environment I realize the genius minds that are working with me. In order to look behind the curtain, I wanted to experience what it's like to get deep into coding. Let me tell you about that.

Of course, not every feature suits a spontaneous detour of a passionate product owner to test the waters of being a developer. Therefore, I waited for the right moment and project to come. What would the criterias for such a feature be? First, the deadlines for current projects should not be too tight. This would give me the space I need to switch between the PO and developer roles. Second, the feature should not be too complex. After all, I wanted to test the waters, not start my career as a developer.

It took a surprisingly short amount of time for such a situation and feature to coincide: After we took over the responsibility of the credit granting mechanism from another team, we had to rewrite the internal webpage that shows the current configuration of our fuel and charging earning system..

The tool to show internal configurations was just born by our web chapter. It was not used by another team at that moment. That brought a novelty aspect to the topic, which meant additional complexity due to missing best practices but at the same time there was little to loose. Also, another major internal webpage was already backed by the same tech stack.

I started by asking my team if they like the idea of me implementing the web component. The support was overwhelming; My developers wanted to start working on the feature right away. I had to hold them back, properly prepared a story, took it to grooming and put it into the upcoming sprint. Meanwhile, the web chapter gave us an introduction to web components and the architecture behind the internal configuration webpage.

Once we the sprint started, everything happened really fast: In planning two, we added the subtasks to the story. I forked the boilerplate that was provided by the web chapter. After a short time, several questions reaching from coding best practices via failing git commits to unflushed queues stacked up that I could not figure out myself. That was the moment when I realized the power of a strong development department: I approached different people whom I heard or got told they would be the best to help me and usually within minutes, the answers were be found and implemented.

Finally, I ran the pipeline. The pipeline creates a bundle of my code and uploads it to be used by the micro frontend architecture. Unfortunately, that did not go as smooth as expected.

When you develop modern webpages, you get used to tools like hot reloading that make you see the results of your code within seconds. Also, through debugging mode, every step of the software can easily be tracked. Now, when I deployed my service it took more than 20 minutes - and failed. To fix the failure was simple, but revealed the next problem: The configurations would not show up!

What could be wrong? The possibilities seemed endless: Maybe the pipeline had an issue. Maybe the configurations could not be fetched from the backend. Did I mix something up in the test or production environment variables.

I started digging. I had come so far and was not thinking about giving up. So I systematically started to check: Are the values from backend available to me? Yes. Does the webpage show values from another source? Yes. Until I finally got to the solution: The tool where my micro frontend was embedded used different IDs for the query that I did!

After a quick discussion with the web chapter I created my first merge request on the main tool, checked my micro frontend