feat!: invert dependencies so that backends now depend on frontends

lms now depends on frontend-app-learning; previously, the
converse was true. Running `make dev.up.lms` will start the
frontend-app-learning container.
This change has been made for all Devstack frontends/backends.

This is breaking in that `make dev.up.frontend-app-*` is no longer
the best way to start a frontend from a clean state, since it will
not start related backend service(s).
Instead, the backend service should be started, which will cause all
related frontend apps to be started as dependencies.

See included ADR (#3) for more context.

docker-compose.yml

@@ -201,6 +201,7 @@ services:
     hostname: discovery.devstack.edx
     depends_on:
       - elasticsearch7
+      - frontend-app-publisher
       - memcached
       - mysql57
     # Allows attachment to the discovery service using 'docker attach <containerID>'.
@@ -229,6 +230,7 @@ services:
     hostname: ecommerce.devstack.edx
     depends_on:
       - discovery
+      - frontend-app-payment
       - lms
       - memcached
       - mysql57
@@ -303,6 +305,8 @@ services:
       - elasticsearch7
       - firefox
       - forum
+      - frontend-app-gradebook
+      - frontend-app-learning
       - memcached
       - mongo
       - mysql57
@@ -336,6 +340,7 @@ services:
     hostname: registrar.devstack.edx
     depends_on:
       - discovery
+      - frontend-app-program-console
       - lms
       - mysql57
       - memcached
@@ -412,6 +417,9 @@ services:
       - devpi
       - elasticsearch7
       - firefox
+      - frontend-app-course-authoring
+      - frontend-app-library-authoring
+      - frontend-app-publisher
       - lms
       - memcached
       - mongo
@@ -488,8 +496,6 @@ services:
           - edx.devstack.frontend-app-course-authoring
     ports:
       - "2001:2001"
-    depends_on:
-      - studio
 
   frontend-app-gradebook:
     extends:
@@ -503,8 +509,6 @@ services:
           - edx.devstack.frontend-app-gradebook
     ports:
       - "1994:1994"
-    depends_on:
-      - lms
 
   frontend-app-learning:
     extends:
@@ -518,8 +522,6 @@ services:
           - edx.devstack.frontend-app-learning
     ports:
       - "2000:2000"
-    depends_on:
-      - lms
 
   frontend-app-library-authoring:
     extends:
@@ -533,9 +535,6 @@ services:
           - edx.devstack.frontend-app-library-authoring
     ports:
       - "3001:3001"
-    depends_on:
-      - lms
-      - studio
 
   frontend-app-payment:
     extends:
@@ -549,8 +548,6 @@ services:
           - edx.devstack.frontend-app-payment
     ports:
       - "1998:1998"
-    depends_on:
-      - ecommerce
 
   frontend-app-program-console:
     extends:
@@ -564,9 +561,6 @@ services:
           - edx.devstack.frontend-app-program-console
     ports:
       - "1976:1976"
-    depends_on:
-      - lms
-      - registrar
 
   frontend-app-publisher:
     extends:
@@ -580,8 +574,6 @@ services:
           - edx.devstack.frontend-app-publisher
     ports:
       - "18400:18400"
-    depends_on:
-      - lms
 
 volumes:
   discovery_assets:

docs/decisions/0003-backends-depend-on-frontends.rst

@@ -0,0 +1,60 @@
+3. Backend services now depend on frontends apps
+------------------------------------------------
+
+Status
+======
+
+Approved
+
+
+Context
+=======
+
+Micro-frontends as default experiences
+**************************************
+
+As of mid June 2021 (between the Lilac and Maple releases), an Open edX instance with default configuration will now direct users to the Learning MFE (Micro-Frontend) for courseware, with a temporary opt-out flag existing to revert to legacy LMS-rendered frontend. Thus, to test a typical learner experience, Devstack users now require the frontend-app-learning container to be started alongside the LMS. This is in contrast to the previous state of affairs, in which MFE experiences were only available via an opt-IN flag, allowing reasonable Devstack usage without having to start any MFE containers.
+
+We anticipate that other learner, author, and administrator experiences will soon begin to use MFE features by default, requiring that more and more MFEs be started in order to simulate user experiences in Devstack. Thus, we anticipate an imminent developer experience issue, in which developers will need to type in convoluated commands like::
+
+  make dev.up.frontend-app-authn+frontend-app-discussions+frontend-app-gradebook+frontend-app-learning
+
+
+in order to enable the feature set that was previously available using simply::
+
+  make dev.up.lms
+
+
+Docker-compose service dependencies
+***********************************
+
+Devstack uses docker-compose to orchestrate containers by defining services in ``docker-compose.yml``. Note that "services" here encompasses backends, frontends, and generic resources like MySQL.
+
+Each service definition may indicate a list of depentent services using the ``depends_on`` key. Dependencies are transitive, and may not be cyclical. When a developer runs ``make dev.up.<service>``, docker-compose is invoked in order to start both the service as well as its dependencies. For example, LMS depends on Mongo and Discovery, among other services. So, running ``make dev.up.lms`` will start not just LMS, but also Mongo, Discovery, all of Discovery's dependencies, and so on.
+
+Currently, micro-frontend services (those prefixed with ``frontend-app-``) are defined to depend on backends, but not vice versa. So, starting frontend-app-learning will automatically start LMS, but start LMS will not automatically start frontend-app-learning. This makes sense under logic that "frontends depend on the APIs of backends in order to function".
+
+However, it can be argued that the opposite dependency relationship also makes sense. That is, one may assert that backends depend on frontends in order to expose their APIs in a usable way. One could further assert that frontends shouldn't have hard dependencies on backend APIs, and should instead gracefully degrade when some or all of its APIs are unavailble.
+
+
+Decision
+========
+
+Whichever dependency direction (frontends depend on backends, or vice versa) is more logically sound, we conclude that, for the puposes of Devstack, *asserting that backends depend on frontends is more useful to developers*. Specifically, it is beneficial to current and future developer workflows if ``make dev.up.lms`` automatically starts and learning-related frontends, ``make dev.up.studio`` automatically starts all authoring-related frontends, ``make dev.up.ecommerce`` starts all purchasing-related frontends, and so on.
+
+A necessary corollary to this decision is that *all micro-frontends should be available in Devstack*, which is not currently the case. Core frontends such as frontend-app-account and frontend-app-authn missing as of this ADR.
+
+Consequences
+============
+
+* ``docker-compose.yml`` will be updated to reflect that backends services depend on frontend-app services, not the other way around.
+* An email and Slack message will be sent out to explain this change and how we anticipate that it will impact developer workflows.
+* A Community Engineering ticket will be sumitted to address an issue ``webpack.config.js`` handling in Devstack, which is currently causing developers to run MFEs outside of Devstack.
+* Arch-BOM will circulate a recommendation that squads add new and existing MFEs to Devstack, following the pattern established by the MFEs already in Devstack.
+
+
+Rejected Alternatives
+=====================
+
+* Keep the old dependency relationships, but add convenience targets (such as ``dev.up.domain.learning``) to start groups of related micro-frontends. We determine that this would increase the already-large congnitive overhead of the Devstack interface.
+* Invert dependency relationships as described in this ADR, and also add targets such as ``make dev.up.lms-backend`` in order to start LMS without associated frontends. We determine that this would create a cascade of new inconsistencies in the Devstack interface: since only one of ``lms`` or ``lms-backend`` could exist as a docker-compose service, rules for the other would have to be hard-coded into the Makefile as special cases.