126 lines
7.7 KiB
Markdown
126 lines
7.7 KiB
Markdown
+++
|
|
title = "#1 Plugin-Based Web App in Dotnet - The Idea"
|
|
date = "2024-01-20T00:00:00+00:00"
|
|
author = "the1mason"
|
|
authorTwitter = "the0mason" #do not include @
|
|
cover = "posts/modular-app/title.svg"
|
|
tags = ["dotnet", "web", "prototype"]
|
|
keywords = ["prototype", "dotnet", "guide", "plugins", "plugin-based", "web application", "ASP.NET", "C#", ".NET 8", "Programming", "Software Architecture"]
|
|
description = "Have you ever thought about making a web application, that could be easily extended by third-party developers? I've been thinking about making this app for a while, so here's my experience..."
|
|
showFullContent = false
|
|
readingTime = true
|
|
hideComments = false
|
|
draft = true
|
|
+++
|
|
|
|
<script src="/js/repo-card.js"></script>
|
|
<div class="repo-card" data-repo="the1mason/Prototype.ModularMVC" data-theme="dark-theme"></div>
|
|
|
|
# Chapters
|
|
|
|
Writing those takes time. Expect to see one published per one-two weeks.
|
|
|
|
1. Idea, Stack
|
|
|
|
2. [Loading plugins](/posts/modular-app-2)
|
|
|
|
3. ~~PluginBase, IPlugin~~
|
|
|
|
4. ~~Creating plugin, DependencyInjection~~
|
|
|
|
5. ~~Controllers, Views~~
|
|
|
|
6. ~~Hooks and Triggers - better event system~~
|
|
|
|
7. ~~Advanced: Unit tests, unloading plugins~~
|
|
|
|
# Introduction
|
|
|
|
Have you ever heard of plugins? These are loadable libraries, that extend your application.
|
|
This series of articles is an overview of my plugin-based web application prototype and the mechanisms behind its features, as well as my thought process and decision-making during development. These articles are a step-by-step guide to making your own plugin-based web app prototype.
|
|
|
|
*I assume some readers have some knowledge of C# and design patterns*
|
|
|
|
# Problem
|
|
|
|
Self-hosted web applications can solve different problems and be of use to a variety of different people with slightly different needs. For this to work, I think that such an application should provide an option to extend its functionality. This would allow other people to build an ecosystem of different extensions around it. For example, a shopping website might have plugins for different payment systems or a comment section under the product page. For me, this also means, that instead of making one feature-rich website, that would be so specific to my needs, that it wouldn't be of any use to anyone but me, I can write a bunch of smaller modules, that could be used by someone, without having to configure other modules.
|
|
|
|
# Choosing my stack
|
|
|
|
|
|
|
|
---
|
|
|
|
**C#**
|
|
|
|
I'm a dotnet developer and I write C# code for living. This project is as much of an exercise for me as it is an interesting design prototype for C#, that hasn't been described in detail as much online.
|
|
|
|
I haven't seen such plugin-based sites written in C#. There are some projects, using plugin-based architecture... Well, there's even a [Microsoft Learn Article](https://learn.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support) about building such an app!
|
|
|
|
> **Q:** Why would I even bother to write all these posts and make prototypes? Even more: Why would someone be interested in such a post?
|
|
|
|
> **A:** You see... there's a problem: Neither `learn.microsoft.com` nor any other website covers dynamically updating web interface with plugins! If you want to learn about it, it's the right place. Also just loading libraries isn't enough because the app also has to provide some ways for plugins to interact with it, which is also covered here!
|
|
|
|
---
|
|
|
|
**MVC with HTMX**
|
|
|
|
ASP.NET MVC is a web framework, that incorporates the MVC design pattern and uses SSR (Server Side Rendering) to serve content. It is a perfect fit for the HTMX library. This is a compact JavaScript library that extends basic HTML by adding some custom attributes just enough to build your app around it. You can distribute events, make AJAX requests, and build truly dynamic apps by using as little JS as possible.
|
|
|
|
<div style="display: flex; justify-content: center">
|
|
<img src="/posts/modular-app/createdwith.jpeg" style="height: 100px;"/>
|
|
</div>
|
|
<br>
|
|
|
|
HTMX uses [Hypermedia as the Engine of Application State (HATEOAS)](https://htmx.org/essays/hateoas/) - it's a principle that leaves all state handling to the server, providing the client only with a set of actions that it can take.
|
|
Your regular SPA will get raw data from the server (like bank balance) and based on it, it will show or hide certain actions (like we won't show the withdrawal option if the balance is 0 or less). With HATEOAS, the server just won't give the link to withdraw money, making this action impossible in the first place.
|
|
|
|
HTMX would allow this app to be extended more easily as well. Most of the modern JS frameworks require transpiling, bundling, and other sorts of stuff. This means that when a plugin is installed the client is most likely will have to be rebuilt. This is slow and needs additional dependencies.
|
|
|
|
> Have you heard about Blazor WASM? You can just write client code in C#!
|
|
|
|
Blazor WASM does not support dynamic loading for plugins. Because of that, plugins won't be able to extend the client. Also, its initial load time is stupidly slow.
|
|
|
|
---
|
|
|
|
# Conclusion
|
|
|
|
In the end, this will be an ASP.NET MVC web application with HTMX library for the client.
|
|
|
|
---
|
|
|
|
The next article will cover the following topics: Loading plugins in runtime, creating plugin instances, and app-plugin communication. I'll have the link here when I'm done writing it!
|
|
|
|
<!--
|
|
---
|
|
|
|
# Loading plugins
|
|
|
|
C#, being a compiled language, can't be extended as easily as interpreted languages like Pytnon or PHP. To load plugins, we will need to load precompiled libraries dynamically after the app is compiled. To do this, [Microsoft Learn Article, mentioned before](https://learn.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support) suggests using custom AssemblyLoadContext with AssemblyDependencyResolver.
|
|
|
|
> Wait, wait, wait! Using... what? I'm pretty sure you could just `Assembly.Load()` stuff, right?
|
|
|
|
Not so easy! If you want to build a really working plugin system, you need a way to determine: whether this assembly has dependencies or not, and what are they.
|
|
|
|
Let's imagine, that our plugin uses `Newtonsoft.Json` library - one of the all-time most popular C# libraries. Should we load it together with the plugin and how do we find it?
|
|
C# has a built-in mechanism to resolve dependencies. When you compile your project, aside from `Project.Name.dll` you would have `Project.Name.deps.json` file, that will include paths to all it's dependencies! That's where `AssemblyDependencyResolver` comes in. It'll find all of plugin's `.dll` dependencies and load those as well.
|
|
|
|
> And also! What it two plugins will have the same library, but conflicting versions? Would we be able to load to of the same assemblies?
|
|
|
|
No! And yes.
|
|
`AssemblyLoadContext` is used exactly for this. Along with `AssemblyDependencyResolver`, it will create an isolated context with current assembly and all it's dependencies. This will allow multiple plugins to have same dependencies with different versions.
|
|
|
|
There's an example of such custom AssemblyLoadContext [Click Me](https://github.com/the1mason/Prototype.ModularMVC/blob/main/Prototype.ModularMVC.App/Prototype.ModularMVC.PluginBase/PluginLoadContext.cs) and also an example of this context being used [Click Me](https://github.com/the1mason/Prototype.ModularMVC/blob/main/Prototype.ModularMVC.App/Prototype.ModularMVC.PluginBase/Impl/PluginLoaders/ManifestBasedPluginLoader.cs#L89).
|
|
|
|
---
|
|
|
|
|
|
# Plugin - App interaction
|
|
|
|
So now we figured out how we load stuff. Now: how do we interact with the app from out plugins?
|
|
|
|
First, we make all plugins to referense the `Prototype.PluginBase` project. This project will provide types that both plugin and our server can understand. We'll build communication using those.
|
|
|
|
**Dependency Injection**
|
|
|
|
Before the app is built and ran, --> |