Why is the mfe image not pre-built

Well… this may be a stupid question, but why is the mfe image not pre-built? As of now, it’s required by every maple distribution and every tutor local quickstart, it would make sense to pre-built the image right?

I understand that mfe image is built on top of many apps, and users may choose to add their own app, but providing a pre-built image including default enabled mfe apps would be appreciated, isn’t it?

Great question. The problem is that the MFE image depends on every user’s specific configuration. For instance, the value of LMS_HOST is required to build the static assets. Thus, it is not possible to provide a single image that could be used by just anyone.

This is a very strong limitation of microfrontends that I did not understand when we first started talking about them a couple years ago. The general idea was that MFEs would be very easy to build and deploy, and in a sense they are. But building the MFE image is costly, and at the time I did not realize that.

Honestly, I feel like now is a good time to reflect on what works and what doesn’t with MFEs. We probably need to have a conversation with the community. Among the other issues that I would like to raise is the size of the MFE static assets: it’s not normal that we have to download 1-2Mb of static js files to access each and every MFE.


@regisb Until there’s a reasonable way to pre-build and host the tutor-mfe image, would it be possible to remove the remote-image hook from tutor-mfe? With the mfe plugin enabled, I hit an error when I try to pull all images:

$ tutor images pull all
Pulling image docker.io/overhangio/openedx:13.1.5-nightly
Pulling image docker.io/overhangio/openedx-mfe:13.0.2
docker pull docker.io/overhangio/openedx-mfe:13.0.2
Error response from daemon: manifest for overhangio/openedx-mfe:13.0.2 not found: manifest unknown: manifest unknown
Error: Command failed with status 1: docker pull docker.io/overhangio/openedx-mfe:13.0.2

I’m bummed about this one… The “remote-image” hook was added to the tutor-mfe plugin to allow users to push their image to a custom registry, in particular in the context of deploying a Kubernetes cluster: fix: missing remote-image hook by shimulch · Pull Request #33 · overhangio/tutor-mfe · GitHub
I honestly don’t know how to resolve this one. It’s definitely an issue, but we need to account for two different, contradictory scenarios:

  1. The image should not be pulled if it’s built locally.
  2. The image should be pulled if it exists in a remote Docker registry.

I think that this issue emphasises the deeper underlying problem that we have when dealing with MFEs, which is that we don’t know how to “properly” build them.

1 Like

@regis, in lieu of the MFE build story being generally improved, I think the flexibility of the V1 Plugin API might lead us to a temporary solution:

def _add_remote_image_iff_customized(
    remote_images: List[Tuple[str, str]], config: Config
) -> List[Tuple[str, str]]:
    Register MFE image for pushing & pulling if and only if it has
    been set to something other than the default.

    This is work-around to an upstream issue with MFE config. Briefly:
    User config is baked into MFE builds, so Tutor cannot host a generic
    pre-built MFE image. Howevever, individual Tutor users may want/need to
    build and host their own MFE image. So, as a compromise, we tell Tutor
    to push/pull the MFE image if the user has customized it to anything
    other than the default image URL.    
    default_registry = get_typed(config, "DOCKER_REGISTRY", str)
    default_image_prefix = f"{default_registry}overhangio/openedx-mfe:"
    configured_image = get_typed(config, "MFE_DOCKER_IMAGE", str)
    if configured_image.startswith(default_image_prefix):
        # Image is plugin-supplied default. Do nothing.
        return remote_images
        # Image has been customized. Add to list for pulling/pushing.
        return remote_images + [("mfe", configured_image)]

Then, using hooks.Filters.APP_TASK_IMAGES_BUILD, we would just add the MFE image for building in the normal manner.

1 Like

This is really cool! I love it.

Great! I captured it here: Rewrite the tutor-mfe plugin to use the V1 API · Issue #59 · overhangio/2u-tutor-adoption · GitHub

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.