Lazy Load Dependency Injected Services POC

[Jayson-Furr]

@sbwalker @ADefWebserver I have come up with a way to lazy load DI services in Blazor WASM using an interface, lazy implementation, and real implementation. As with any lazy loading, the code would need to be large to benefit from it but here is a small POC.

The *.Real.dll is lazy loaded. When visiting counter page, the assembly is loaded prior to being used dynamically in the the *.Lazy.dll implementation.

https://github.com/Jayson-Furr/LazyLoadPOC

[ADefWebserver]

For some reason the link goes to:
https://github.com/oqtane/oqtane.framework/discussions/url

It should be:
https://github.com/Jayson-Furr/LazyLoadPOC

[Jayson-Furr]

Thanks @ADefWebserver not sure why it did that.

[sbwalker]

@Jayson-Furr .NET 5 introduced assembly lazy loading for WebAssembly:

https://docs.microsoft.com/en-us/aspnet/core/blazor/webassembly-lazy-load-assemblies?view=aspnetcore-5.0

The problem of course is that the solution only caters to static applications - not dynamic applications like Oqtane which load dependencies at runtime. That being said, there was some previous effort invested in exploring lazy loading - in fact, earlier versions of Oqtane actually used the custom router to load assemblies but we later relocated this logic to Startup because we ran into the following problem... dependency injection.

In the Oqtane framework, external modules usually have a client project which usually contains service classes for interaction with the back-end APIs… and we encourage developers to use the standard .NET Core dependency injection approach. So we need for these services to be registered in the service container. Currently we are doing this registration dynamically during startup however this requires that the assemblies are already loaded in the app domain. In a lazy load scenario the loading of assemblies is deferred... and .NET currently provides no way to register any services outside of startup - so any services that exist within an assembly cannot be registered. The only solution in this case is to abandon dependency injection altogether for these services and instantiate the services classes manually ( ie. service = new Service() ) – which is far from optimal. I raised this topic to Microsoft and they acknowledged that there is no solution currently. So basically lazy loading works great for Hello World apps - but falls down when building real apps.

So given what I just described above, it would be helpful if you could describe if/how your POC addresses these issues.

[Jayson-Furr]

@sbwalker @ADefWebserver From what I have had time to look at in Oqtane, Oqtane has an interface, IServerStartup, that registers services at startup from modules. So this POC would register the lazy implementation in the startup class that implements this interface. The lazy implementation does not require the real concrete implementation to be registered as a service because of the dynamic type. Therefore, prior to calling any functions on it, you would use the web assembly's lazy load feature to load the real implementation prior to loading a page. The only true way this would be beneficial, as with any lazy loading, would be if the real implementation was large, or larger than the lazy implementation. Just like the standard demo in the lazy load docs, the assembly must be added to the CSPROJ file as a lazy loaded assembly as in the POC. So in the end, initial load will pull down the interfaces DLL and the lazy DLL. Prior to using/injecting the service from the lazy implementation, the framework would handle some callback or function to lazy load the real DLL. The names lazy, and real are only for example and clarity, of course. If I need to implement this is an octane project, I can do it one weekend, just let me know.

[sbwalker]

@Jayson-Furr I believe that the area where this concept would have the most impact in Oqtane is when it comes to loading custom modules and themes. And it would not only have value in a WebAssembly scenario - but also in a Blazor Server scenario. Currently during startup the framework identifies DLLs in the /bin based on a naming convention, and it eagerly loads them into the app domain ( when running on WebAssembly it also needs to do some extra work to download the assemblies to the client using HttpClient ). After the assemblies are loaded into the app domain it executes logic to register any services that they contain. This is done in a couple of ways - services can either decorate themselves using an IService interface for simple registration, or they can be explicitly registered by implementing IServerStartup ( which is generally only necessary for more complicated registration requirements ). Note that all of this happens during Startup - so the more custom modules or themes you have, the more processing that needs to occur during startup. So in theory if it was possible to defer the loading until the moment when the service is used, it would save some startup processing time. That being said, I can still imagine a lot of complications. For example, a custom module has a client and server project - and the client project usually contains both razor components as well as services for retrieving data. Currently when Oqtane dynamically renders the UI it expects that the razor components are already loaded in the app domain... so there would also need to be a way for the framework to load razor components in a lazy manner ( and these are not explicitly registered in the service container ). In addition, module and themes can have their own third party dependencies on other libraries which also need to be manually loaded. The current framework handles these scenarios in a predictable manner bu using eager loading. So I think the bigger question is what the impact analysis might look like in order to support lazy loading - ie. could it be done in a way that does not add complexity to the framework or to developers who are building custom modules?

[Jayson-Furr]

@sbwalker i think it could be designed to not add complexity for developers who want to build standard loaded modules and themes. As for developers who want to take advantage of lazy load, there will be some sort of difference in design. I think a good design would be to have properties in the ModuleInfo or ThemeInfo that specifies if they are lazy loaded or not and information on their lazy libraries as well as dependency modules and themes. Then, in the application prior to loading a module or theme, Oqtane can track what it has lazy loaded and resolve and load necessary dependencies. This would likely work in Blazor wasm and server. I think you are asking about server side code / services as well? If so, this should be possible as well, but the assemblies would need to be loaded into the app domain on demand which is fine but a location in code for this to happen would need to be determined. As for the dynamic side of it, the modules directory could have a subdirectory for lazy loaded, and these libraries would be the ones that are loaded on demand. Or, a convention of naming them .lazy.dll could be used.

[Jayson-Furr]

@sbwalker Also, the app does not need to track what it has loaded, a second call to load an assembly continues gracefully if it was already loaded.

[Jayson-Furr]

@sbwalker After some more examination of the code, the LoadClientAssemblies task handles loading in a suitable fashion to implement this scenario. The api could return a list of the interface, lazy, and real libraries. It could then load the standard libraries as it does, then the interface libraries, then the lazy libraries. It could use a service to store the real implementations and load them as required when resolving prior to any Activator.CreateInstance. The way the dynamic fields are in the POC are will allow them to be referenced without fully loaded as long as they are loaded before activation.