Plugin loading method inconsistency between frontend and backend for the techdocs

[David Festal]

Describe the bug

The backstage-techdocs frontend plugins/modules have not been switched to dynamic, though the corresponding backend plugin has been (and is even disabled by default).
It's an inconsistency that will have to be fixed, probably by switching the techdocs frontend plugin/module to dynamic as well.

Side note: The backstage-tech-radar also is also still statically included in the Showcase? Is it on purpose ?

[Tom Coufal]

Yes, both are on purpose. Desired support matrix state they should be static:

https://docs.google.com/spreadsheets/d/1dNUAGTeosEzreX9fxFTW1Vq3oGCbHroZ_DFEL8sjfjY/edit?usp=drive_open&ouid=117471959508522471287

[David Festal]

Yes, both are on purpose. Desired support matrix state they should be static:

https://docs.google.com/spreadsheets/d/1dNUAGTeosEzreX9fxFTW1Vq3oGCbHroZ_DFEL8sjfjY/edit?usp=drive_open&ouid=117471959508522471287

Ah, interesting. Thanks for pointing that @tumido out !

So after looking into it, it seems I had not seen the change (made on October, 16th by @gorkem according to the version history) to set them static when I finished preparing the switch of the backend plugins to dynamic (including techdocs backend) whose final PR was finally merged on October, 20th, after several weeks of preparation.

So the result of this timing issue is that we have an inconsistency. And my question is: how do we want to fix it ?
3 options here afaict :

1. keep the techdocs backend dynamic and disabled by default, and make the techdocs frontend dynamic and disabled by default as well ?
   2.keep the techdocs backend dynamic but make it enabled by default (with a viable config), and keep the techdocs frontend static ?
2. Make the techdocs backend static again, and keep the frontend static ?

• Option 3 doesn't seem to make sense to me: it would require more work, without bringing user value.
• As a short-term solution we can easily implement option 2, though we would have to ensure that we provide a default config which allows starting without any problem and can easily be completed.
• But option 1 might still be the simplest and most consistent solution, knowing that we have all the mechanism in place to switch to dynamic.

[Tom Coufal]

My advice would be:

Let's go with 2 and if we have time to fix this before release we can try to do 1. But we have many more pressing issues than this.

Techdocs frontend has a bit more complicated structure that we would need to account for. It's 3 packages that have a DOM dependency... So we would need to engineer a solution for mounting 1 dynamic plugin into another or modify this behavior in a wrapper... It would require non-trivial effort + at least a few hours to solve.

Option 1 is definitely not the simplest.

There's a similar issue with the techradar plugin, which uses a custom API client to fetch custom data:

• https://github.com/backstage/backstage/tree/master/plugins/tech-radar#how-do-i-load-in-my-own-data

• backstage-showcase/packages/app/src/apis.ts

  Lines 42 to 57 in 0f1f70d

   createApiFactory({ 
     api: customDataApiRef, 
     deps: { 
       discoveryApi: discoveryApiRef, 
       configApi: configApiRef, 
     }, 
     factory: ({ discoveryApi, configApi }) => 
       new CustomDataApiClient({ discoveryApi, configApi }), 
   }), 
   createApiFactory({ 
     api: techRadarApiRef, 
     deps: { 
       customDataApi: customDataApiRef, 
     }, 
     factory: ({ customDataApi }) => new CustomTechRadar({ customDataApi }), 
   }), 

• https://github.com/janus-idp/backstage-showcase/blob/main/packages/app/src/api/CustomDataApiClient.ts

This would again require non-trivial amount of work figuring out how to move that code into a wrapper and have properly propagated to the app...