Challenge Overview
Challenge Overview
We are exploring micro-frontend architectures for Topcoder apps. Your task in this challenge is to propose the most suitable architecture for our requirements and a POC application to demonstrate the sample use cases.
Background
Micro-frontends are “techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently” and we’re considering using this approach for developing various Topcoder apps.
There are many different solutions for starting a micro-frontend app (iframes, virtual DOM, etc) and none of them are the industry standard yet, so we are looking for your help in evaluating the available frameworks and libraries.
Benefits that we expect from the micro-frontends approach are:
-
Stop redeveloping things like menus and headers and footers and other frame components with each app
-
Improve code reuse
-
Improve or at least maintain the ability to develop several apps in parallel
-
Improve standardization
Task Detail
You need to pick a micro-frontend framework/library and implement:
-
Parent ‘frame’ app - that handles the overall layout
-
Two micro apps that are rendered in the parent frame app
The two apps should be independent of the main ‘frame’ app so that they can be deployed independently and developers don’t need to update any code/config when deploying the app to the main ‘frame’ app. You should also demonstrate how to add/remove an app from the main frame.
Micro apps should not be limited to one framework/technology - it should be possible to include apps developed with React, Vue, Angular, etc, and you should make a good use of the framework features to demonstrate how these micro applications can be integrated. For example, if there is an API / methods to call in the framework to add to / update the menus in the frame, use those - we need to see that in action. Take advantage of the best features of the microframework you are using.
Both micro apps should use Topcoder APIs (for example Member and Challenge API) and should be very simple - it is meant just for proving out the general frame concept and how an app would be built to use it.
Final requirement for the two apps is that they need to pass data between them using framework features - this can be something as simple as populating a field or a label in one of the apps.
Don’t try to implement complex UIs - main point here is to showcasing the framework features and how it works together.
We have provided a design reference that we will implement in the future challenges. This doesn't need to be strictly followed (as there may be limitations based on the microapp-frame that you choose), but use as a general guide and match where you can.
While picking the framework/library, pay attention to these common issues that need to be solved when using micro frontend solution:
-
Shared app features like authentication, jwt tokens, 3rd party redirects. For example if a framework is using iframes to render different child apps, a redirect to a 3rd party site coming from the child app would change only that one box, won’t do a complete redirect
-
Modal windows / popups / snackbars and how they integrate into the app
-
Handling overflow elements like date pickers, dropdowns that would likely span the entire page in a monolith app, but might not look good with micro frontends
Getting started with micro frontends
Here are some useful resources to get you started on micro frontends:
Submission Contents
Your submission should contain the following:
-
POC app implementation (including readme for the frame app and each “child” app) and links to deployed Heroku app
-
A write-up of the experience:
-
How hard or easy was it to set up the framework?
-
How was the experience of writing an application for it?
-
Was it hard? Was it Easy?
-
What was great about it? What was terrible?
-
Would you recommend it?
-
-
What do you like about the framework you used? What did you dislike about it?
-
Solution for handling redirects (if any)
-
Solution for handling element overflows (if any)
-
List of potential technical challenges that might become relevant in the future and aren’t specifically handled by the chosen framework (ex css conflicts, js global namespace pollution, different versions of dependencies, etc) and would require custom development effort?
Judging Criteria
Review will be done by two community reviewers, but you can also take part - in the first 24hrs of the review phase you will have access to all the submissions and you will be able to make comments about other submissions. These comments won’t directly influence the scores, but will be aggregated and provided to the reviewers before they start reviewing submissions.