Transforming Frontend Architecture: A Journey from Monolith to Micro Frontends at Udemy — Part 2 of 3
By: Chris Nienhuis, Hamza Erbay, Matthew Bise, Nathan Chapman, Seth Hodgson, Trey Briggs
Introduction
In the previous section, we discussed the challenges in our current monolith architecture and the reasons why we are keen on transitioning to a micro frontend architecture. Now, we are going to delve into the hackathon event at Udemy where we explored the idea of decoupling our frontend structure, the preparations we made, and the options we considered for this transformation.
If you missed Part 1 of this series, it is located here:
Udemy Hackathon
During the Hackathon event at Udemy, which we organize every six months, I had the opportunity to meet some amazing people in 2021. We collaborated on ideas for decoupling the frontend structure, which was a great experience.
Our team comprised Chris Nienhuis, Hamza Erbay, Matthew Bise, Nathan Chapman, and Trey Briggs. We would like to thank Seth Hodgson for bringing us together.
Preparation
Our React components are currently tightly linked to the monolith runtime environment, making it impossible to use them across our various sites or in different rendering environments — client-side, server-side, or offline via static site generation tools (B2C/B2B, support center, blogs, microsites, etc.).
Decoupling the frontend would improve our daily workflow and make it easier to make significant style changes across the apps. After researching modern frontend technologies, we chose Next.js for its strong community support and performance. Then, we worked on the high-level structure for the hackathon.
Analyze the inventory
The hackathon posed challenges related to our infrastructure and GraphQL integration that needed to be addressed. Our goal was to produce a substantial output with minimal effort, setting the following criteria for our project:
- Base Component Dependencies: Opt for the fewest possible, ensuring simplicity and ease of manipulation.
- JavaScript Library Dependencies: Limit these to minimize bloat and potential conflicts.
- Layout Complexity: Favor a straightforward layout to reduce developmental overhead.
- Traffic Considerations: The page receiving less traffic provides a safety net if we implement the new structure in a live environment.
After analyzing the options, we concluded that the Featured topics page is the best candidate. It has fewer cross-dependencies, is lightweight, and allows us to focus more on the architecture.
Elevating Development and User Experience
Our strategy for enhancing developer workflow and user experience hinges on the capabilities of Next.js, particularly its static site generation feature. At build time, Next.js will enable us to create static pages that can be distributed to our Content Delivery Networks (CDNs) as soon as code changes are committed.
This setup allows the dynamic elements of the internet to cache our content at the CDN layer, providing quick access to users. If there is any non-cached, dynamic content, the system can switch back to our Next.js applications hosted in the US.
Hackathon Architecture: Laying the Foundation
Throughout the Hackathon, we focused on maintaining simplicity in our infrastructure to demonstrate our proof of concept successfully. The components of our hackathon architecture included:
- Next.js with TypeScript: Leveraging the robust framework of Next.js paired with the strong typing of TypeScript for enhanced reliability and developer experience.
- GraphQL: Utilizing GraphQL for efficient, declarative data fetching, augmented with GraphQL Codegen for generating type-safe code.
- Argo CD: Employing Argo CD for a declarative and automated deployment process to our Kubernetes environment.
- Cloudflare: Implementing Cloudflare’s edge networking solutions for improved performance and security.
The Impact of Our Hackathon Endeavor
The Hackathon illuminated how our server geography adversely affected user experience due to latency. Moreover, our data retrieval methods were excessive and particularly burdensome for mobile users abroad with high data costs.
Our new tech stack, featuring SSG and SSR, coupled with GraphQL, promises to deliver content more efficiently, closer to our customers, and with just the necessary data.
The event showcased the potential for significant performance improvements. Despite the hackathon’s time constraints, we’re confident that with continued efforts, we’ll enhance our accessibility and SEO to top-notch levels.
Summary
In this part, we walked you through the exciting Udemy Hackathon event, where the groundwork of our transition began. We shared our preparations, the criteria set for the project, and why we elected the Featured topics page for initial implementation.
We also discussed our strategy for elevating developer workflow and user experience using our proposed new architecture. While we have emphasized maintaining simplicity in our infrastructure for our proof of concept, this also offered us a unique glimpse into the potential gains in performance our new method promises.
In the upcoming section, we will delve into how this vision presented during the Hackathon has been put into action at Udemy. We’ll walk you through the process of migration from our monolithic application, challenges, performance wins, and much more.
Thank you for reading Part 2 of our series. To ensure you have the complete picture and don’t miss out on further valuable insights, you can continue reading:
