Updating MFE URLs to be shorter and more human-readable

Development
1

Hello! I am sharing the proposal for updating MFE URLs so that they are shorter and more human-readable. Please share any comments or concerns about these changes.

Link to ADR

3 Likes
2

Link to the PR for comments.

3

The biggest problem I have with urls in MFEs is that too many of them must resolve to /index.html. When there is no static file that matches the URL, the Web proxy must default to the root. As a consequence, MFEs never respond with 404 or 400, even when urls are improperly formatted. This situation makes it very inconvenient to debug MFE configuration mistakes. Also, it makes it harder for end users to understand what is going on when they fumble with the browser url. Thus, I think it would be better if MFEs resorted to query parameters instead of REST-like API parameters. The latter works great when there is a backend framework in place to parse url components, and eventually respond with 4xx errors, but it’s breaking down when we move to frontend-only code.

2 Likes
4

Could that be partly accomplished by having a dedicated 404 HTML file that the MFE redirects to when it detects an invalid URL?

5

Could that be partly accomplished by having a dedicated 404 HTML file that the MFE redirects to when it detects an invalid URL?

I think this would be misleading, because a 404 error would be displayed even though the server did not respond with the corresponding status code.

Since MFEs bypass the usual HTTP exception management, they need to provide an alternative. I would suggest a prominent info box visible to all users, similar to a Django error message.

1 Like