Plugin Architecture in C# - Principal Software Engineering Manager AMA

got a few different platforms we got to get started we'll see it's taken its time okay I can see it's started on LinkedIn that's a good start I think it looks like Instagram's going Tik tok's going we're live awesome so unfortunately last week I only got my one uh my one stream in on Monday night and then I didn't do my live coding stream so it's a little unfortunate but it was for a good reason and it's actually going to be the topic of discussion today so um yeah I think tomorrow as well uh so depending on when you're watching this tomorrow might not make sense but uh usually what I've been trying to do is Tuesday mornings I try to do uh like live coding for about two hours and then it's going on a couple of different platforms but I think it went a little choppy ah I hope it's going to resume this keeps happening I literally I literally have a router I have a nest uh Hots spot like right below my desk so I'm hoping that it doesn't keep doing this it's kind of embarrassing um it keeps going between like full bars of Wi-Fi and then one and when it goes to one I think it's more like zero so we'll see how long we can keep this going though so I am going to be watching the chat so if you have questions as we're going through this as usual I will be happy to answer anything about software engineering uh doesn't have to be exactly related to the topic uh which is going to be plug-in architecture so if you are in a spot where the chat is working you can go ahead and check out the link that I just put into the chat uh I don't think that comes through on LinkedIn so let me uh put that into the comments on LinkedIn you can get that that's going to be the newsletter that I put out um but specifically we're going to be talking through the Pres presentation and not just the newsletter so this conversation is going to be about plugin architecture for.net um by the way if you're joining the stream uh let me know if the stream quality is choppy or if it's going weird uh I would rather try and address it like super early if I need to um somehow I don't know how I do that but I'd rather figure it out than go too far so we're going to be talking about plugin architecture in.net the link that I put into the chat is the newsletter article but I do want to mention that I have uh the whole presentation available for download so I'll share that with you as well and um yeah I probably will jump right into things so I had the opportunity this past week so last week uh to go down to Dallas actually to speak about this which is a really cool experience for me um and I say cool experience for me because historically I have been uh telling myself I'm afraid to public speak I'm a bad public speaker and this is a really good sort of test for me to see like you know are you actually bad at it like do you actually hate it uh and I would say the good news is I think I've kind of overcome my fear of public speaking if I can call it that uh and I would attribute a lot of uh of youtubing and live streaming to being able to help with that so that's been kind of cool so um Danny Thompson from down in Dallas uh he's pretty big on a few different social media platforms depending on which developer communities you're in uh so like especially on LinkedIn and Twitter he's got a pretty big uh follower base but uh he was running uh the Dallas software developers uh Meetup and I got invited to go speak there which is really cool so the the yeah well let me let me jump over to the presentation because it kind of comes up in the presentation itself I'm going to give you the same talk that I gave down in Dallas and we'll see how that goes so again if you have any questions at any point just put them into the chat I'm happy to answer and we'll take it from there I'm going to refresh the chat on my side because I can see that there are more people watching this on LinkedIn than there are in the shared chat which makes me think that the shared chat messages are not working as expected but we will put it to the test so if you're if you join in let me know um put it in the chat we'll see okay let me flip over to the presentation so this is the newsletter and like I said I do have it up on a product page it's totally free to go download so um I'm going to put this link into the chat as well so it's literally the presentation the the PowerPoint that I'm going to be uh sharing so I'll put that into the chat as well and on LinkedIn I'm going to say PowerPoint and you can get that that's kind of weird it if on LinkedIn it sent the link and then it wants me to send the the thumbnail separately it's very bizarre so I I can't even press enter on that anyway so there you go sent that on LinkedIn I guess it came through on the the shared chat as well that's pretty weird so uh sorry if you're watching this on Instagram it's going to be cut off a little bit but that's the product page again free download um I sent this out with the newsletter but again it's the exact presentation that I'm going to be sharing in just a second here so I'm not going to put it in presentation mode just because I don't want to mess around with that and uh the way my screen setup is in quadrants and I just don't want to deal with that so I apologize I'm being lazy but let's get into it so this is building plugin architectures in.net the majority of the beginning of this is going to be just general plug-in architecture kind of things and then as we get a little bit deeper into the conversation we'll be seeing more net specific technology come into play so we will get things going here so this is the agenda uh I guess first thing on the agenda should have been how do we get this in dark mode but sorry about that um so we'll talk about who I am again this is exactly what I gave down in Dallas so who I am you might know who I am if you're watching this different scenarios for plugin architectures talk about why plugin architectures are valuable and hopefully after seeing some of the scenarios um you can see how the the why kind of correlates with that we'll talk about some tools patterns and best practices that I've employed using plug-in architectures over many years we'll talk about some trade-offs and gotas um it was pretty light in the presentation so uh I don't mean to skim over that I was just trying to shorten up some of the time so if you're watching this or uh like live or you have questions and you're watching the recorded version if you want to sort of try and pick up part plug-in architecture a little bit more I'm happy to have conversations about more tradeoffs because I never mean to suggest that some things are just like the best right like there is no best uh Universal anything so when I present about plugin architectures you're probably hearing more of my positive bias and I just want to sort of acknowledge it up front that it's not perfect right I will try to cover some of the tradeoffs but like feel free to engage and ask questions in sort of like challenge it that's totally cool okay so hi I'm Nick centino I am a principal software engineering manager at Microsoft I put a picture of my my wife uh and myself at our wedding last year so it's our anniversary in a week approximately so August 5th um I made I made the note in the presentation so I could remind myself and I'm again reminding myself now so don't forget that um I have a picture of two of our dogs these are my two dogs Ila and Loki uh not shown in the picture is Arya who is the 130 lb Alaskan Malamute she is a big derp she's absolutely awesome but uh I just got the picture of my two dogs um we live in Seattle so kind of moved our little family out uh from around the Toronto area in Canada so that's where we live uh before Microsoft I'll talk about Microsoft in just a second I spent eight years at a company called magnet forensics so I was building digital forensic software there uh kind of started at that company when it was roughly eight people or so so pretty small we were in a an incubator so that sounds kind of weird to say like a startup incubator and so it was called the accelerator Center and uh you know fastest I don't know if it's changed since then but we were the fastest company to sort of graduate from that accelerator program we had an office that opened up Uptown in Kitchener waterl which is really cool and then we moved to a uh people might not remember maybe some people do blackberry right Rim so we moved into one of their old buildings which is our big level up and then uh they ended up moving again um but I was kind of i' had already left like raid at that point it was literally raid as they were moving offices so uh for me uh sort of my journey was that I started there in a few months into my career at Magnet forensics uh kind of got I don't want to say forced like it was a voluntary kind of ask thing but became an engineering manager like pretty early on we called it team lead at the time but like I had comp View and managed people having 101s and stuff so literally have been doing management since I left University almost so for almost a full eight years that I was there I was a software engineering manager and software engineer so I spent a lot of my time building a lot of the prototypes that the company had for products that would come to be and uh kind of my team Focus was around that so I'll talk about a couple of different things that we built out uh not in detail obviously but just in terms of how plug-in architectures fit in and at Microsoft now I don't code at work anymore so I am a principal software engineering manager there I started at Microsoft in the substrate organization uh for deployment so uh managed uh two of the feature Crews within the bigger deployment team and then at the beginning of this year I moved over to our routing plane in substrate which is super cool so they get to be uh you know part of managing the firewall policies uh some of the caching technology and some of the Dos protection uh that we're building out so um really cool space uh when we talk about scale of things like it's kind of uh it almost like seems like it doesn't make sense because the scale is so large right we're talking like trillions of requests per day it's kind of hard to like what does a trillion even look like uh so it's uh definitely a cool space and then like finally obviously if you're watching this you probably know that I make videos and stuff on YouTube for helping Sofer engineers and uh a lot of my technical stuff uses C andn Net as the as the backing for a lot of my examples but I do try to make sure that there's general concepts so this is going to be less applicable but it's kind of in the slide deck so I'll mention it but um when Danny had invited me down to speak at this event um he he said like hey just a head up like we don't you know we don't have uh we're not paying the speakers to come in it's a small event like it's kind of just like if people are able to speak that'd be really really nice and um and you know I wasn't expecting anything but uh I remember my wife said like you know you like why wouldn't you do this right like I um I you know I pay a YouTube editor for my videos and stuff every month like I I lose money on YouTube um but I like doing it because I want to be able to create that content and I I do sell fores on the side so that that pays for it and she said like you know you have you have the means to do this like why wouldn't you so I wanted to drop a little joke into the slide deck and I I put a little screenshot of my uh this is my YouTube income so the joke I made was like Hey like thanks Danny but like don't worry like making it pretty big on YouTube now uh making uh roughly two whole dollars per day you can see it actually was as high as $2.50 before I started making WPF content on YouTube that uh that actually brought it down a little bit but um yeah basically uh I'm not quitting my day job for YouTube uh that's for sure because $2 a day isn't going very far but that was the joke I thought it landed pretty well um I can't tell if it's Landing well right now but it's funny okay so talking about plugin architectures now what do we start with here so we're going to talk about scenarios and uh I wanted to talk about these scenarios I just wanted to say hey on Instagram I think you already left the chat but um these scenarios the reason I wanted to bring them up is because you might have already seen some things like this before which I think is really cool that if we start talking about it you'll go hey like yeah that kind of sounds familiar so um something I wrote as a super quick example at the beginning was let's think about a command line application and this command line app is going to be responsible for converting pictures so you know bit maps to pgs so you build something that can do it and then you're happy with that and you go okay well what about these other image formats I want to be able to convert to jpeg uh webp uh maybe uh I don't know like Tiff files anything there's lots of image formats Tiff's kind of a weird one but you know if you wanted to go do that you could use a plugin architecture for doing something like that and expanding out the capabilities of a simple converter app like that could apply the same thing to video file and stuff like that so uh FFM Peg if that comes to mind right A lot of people that probably use that that would be really well suited for plugins to be able to extend it uh this next one I wrote was you know this is specifically for net you could think about doing a web API so the example I wanted to walk through was like okay let's imagine you are on a software engineering team and your product owner has said hey like we want to go build out these end points for this web API so you go build out um the example I put here was like you know have a user's endpoint you might have products you'd have a checkout so you have this like functioning uh web API that you built and then they come along and say wait like no one more thing like we want to be able to add in a review system so you could consider building your web API in asp.net core to be plug-in based and that way you can go extend it with a plugin and not go touch the rest of the application moving along a couple more scenarios here um this is especially because WPF has been on the mind lately with some of my YouTube videos but I said okay let's take something like um you could take Visual Studio probably a lot of people watching this are familiar with Visual Studio VSS code uh Photoshop or Adobe Premiere think about these applications where they offer some core functionality right and then the applications themselves also generally have like these tools that are built into them that feel like they're like Standalone little modules and if you're familiar with vs code and visual studio think about extensions right like these are plugins so what's interesting about this one is not only do you have like parts of the application that are probably plug-in based and uh sort of owned or controlled by the core development team but you also have this opportunity where there's thirdparty plugins that can be introduced into the system so that was something that I wanted people to be able to think about as we go through because there are some implications that come along with that and then finally this one I think probably resonates for uh especially a lot of younger developers I know for me uh you know I wanted to start out programming and trying to make video games and stuff like that so uh I think it's pretty common where people will say like hey like I want to go make a like a World of Warcraft clone I want to go um I don't know like I want to go make the next big MMO RPG kind of thing so so it's a it's a lot more difficult than people expect basically everyone fails at it but it's a cool example of a system you could build where you want to go build some uh some core functionality and then as you're adding systems into the game or content even into the game you want to be able to extend it and that way you can start adding plugins for more capabilities so that is something to think about okay now we're going to get into to some of the more detailed uh ideas around plugin architectures and hopefully we can see I guess my head is cutting off some of these uh slides sorry there's nothing too interesting behind my my head there but we'll talk about how some of these apply to even the the points we just talked about from the previous slides going through those scenarios and then I left a little joke at the bottom because one of the tradeoffs is that yes plug-in architectures can introduce a lot of complexity in levels of abstraction so if you are trying to use plug-in architectures for everything even where they're not well suited you could run into some uh some fun times with just like over engineering things a little Diet Pepsi there we go okay so four major points that I want to get across for why building with plugin architectures we're going to talk about modularity and isolation extensibility flexibility reusability and Tes ability these are all different characteristics I'll go into more detail so uh we talk about low coupling High cohesion these are properties of systems that we want to be able to build right when things are tightly coupled they are generally difficult to work with when we think about plugins we have something that is generally highly cohesive because you're putting things that belong together into the same set of functionality in a plugin right you're not building a plugin that's like you know a 100 different ideas or like domains and things like that and then saying okay I'm going to add it in generally plugins are pretty purpose-built pretty specific so you get this High cohesion going on um the low coupling part is going to come from here so uh I use the phrase like physical boundaries obviously we're talking about um software so it's not really physical but in C andet we're talking about like sort of project or uh assembly like dll boundaries so uh what can be really interesting is that if you consider a plugin being like its own project right you get this boundary that you put in place which can be pretty powerful in terms of just keeping things very isolated and separated so um kind of have this forcing function when you start to build with plugins and use these boundaries uh I I wrote a little note here um if you know how I like to explain things I I don't like saying that you like must always do something uh or you know you should never do things but I say like ideally plugins shouldn't be reaching into other plugins and what I mean by that is uh let's take the example of the converter the media converter example we walk through um if you had code so say you have a plugin to do uh you know conversion to bitmap conversion to PNG conversion to jpeg right so three plugins there ideally you don't have one of the plugins sort of depending on the other one like for the same set of features so if you needed code uh it existed in one you'd probably want to find a way to factor that out and not have a plugin go like the PNG plugin shouldn't depend on the bitmat plugin that's generally like not how I would advise uh structuring these types of things because we do want to have these physical boundaries and then I left a little note in here uh because I think vertical slice um this phrase is coming up a lot uh especially a lot more than the last year or so it's not necessarily a new thing but um when I talk about vertical slices I think like you'll hear people talk about vertical slice architecture a lot which sure you can make a vertical slice architecture but um when I talk about vertical slices I just like talking about like how you develop software because these are different things you could have any type of architecture you want any at all and still attempt to deliver features and vertical slices doesn't mean that it's going to be easy right it doesn't mean it's going to be easy but you can do it so when we talk about vertical slices at least for this conversation I'm specifically talking about um building a feature end to end so it's not hey we need a we need uh the review uh API that I talked about so okay well I'm just going to go land the database changes or I'm just going to make uh the route that we can call like to me that's not a vertical slice a vertical slice would be saying like how do we get this working through the stack so how do you add and maybe if there was a UI on top of this you would say how do I add the piece to the UI how do I add the route in how do I call that route how does that route uh do its business logic how does that business logic access the database so how do you go like top to bottom and kind of give that data back um you know to the client back to the user interface so that would be a vertical slice and so there's like architectural designs that allow you to do that but I talk about it from like a a development process kind of philosophy so um I say for plugins I I think that they are very well suited for um for vertical slice development and the reason why I think that that is because especially when you have some framework in place right if we think back to the the media conversion one if I say I want you to make a feature that's basically supporting PNG conversion you could go make the plugin that allows you to convert you know uh input images to PNG end to end right that plugin gives you that sort of vertical slice of functionality so just a thing to think about um but I like developing stuff with a vertical slice approach and I leverage a lot of plug-in architectures for doing so so um something that I don't show a lot of um for maybe obvious reasons right in this moment is pictures um that's because I'm absolutely terrible at making pictures so uh I just wanted to put a little visual of what this could look like when we're talking about uh specifically like an asp on it core app and having uh your core application I realized now having core and core and two spots is may be confusing but this is the the main part of your application and then you could have plugins for your different routes that you want to be able to call so you might build out functionality for authentication and put that in its own dedicated plugin and then you know you could have a whole plugin for shopping cart capabilities this like an e-commerce app right and then a whole plugin for products and then the one that I was talking about was hey your product owners are now asking for reviews you could go add a new whole plugin for reviews so something to think through there uh I'm just double checking usually I have a couple people that are putting stuff into chat on Twitter especially by now and I don't see any messages so um if you are on Twitter and watching this do you want to send me a message um that would be kind of cool let me know what's actually working cuz getting a little nervous here that if you're asking questions or or blasting me about something I can't actually see it which is not a good feeling the whole point of being alive is that I can answer your stuff um okay keep me posted though um now if we move along here so that's a visual of how you might see this kind of thing but let's talk about extensibility and flexibility one of the things oh okay there's twitch chat is working so that's a good sign uh infected FPS so this looks a bit close to how a modular monolith would be set up uh exactly so another thing that I should call out is like when I talk about architectures for software hello on TW uh on Twitter as well um when I talk about software architectures I generally don't think that your entire code base has to be like one architecture necessarily I think that there's opportunities for different blends of things and these things can evolve over time too kind of like when we have design patterns PS I think design patterns give us a good starting point but I think like anything if you follow it completely rigidly and just say like it must be this all the time 100% of the time you're probably going to be fighting against it at some point so um with the modular monolith approach like 100% like I build modular monoliths and this came up at uh this was the one of the only questions that came up after my talk in a few different ways so it does look like a modular monolith and the idea is if you think about the plugins these are just the modules in your modular monolith how we load them up is what makes them plugins so uh there's a little bit of nuance here but we'll walk through this but I think that's a great question about is this the same uh it's not the same but you can sort of use a plugin architecture to accomplish a modular monolith so we're going to talk more about this in detail but this concept of assembly scanning so um when we're talking about plug-in architectures one of the big things that is sort of different than just building an application is that we're not leveraging in uh the plug-in information at compile time so the implementation of the plugins is not defined at compile time from the perspective of the core application okay so to give you an example of this that media converter program we talked about okay so it would have a core application let's call it a console application you would have that to begin with and then the plugins like the core application doesn't know about the PNG converter implementation it doesn't know about the bitmap converter implementation it knows the apis and the interfaces to work with but it doesn't know the implementation and that means that even at so compile time absolutely doesn't at runtime it's just going to be able to load the assemblies in some way and a lot of the time I think most plug-in architectures they're loading things at startup you can load things later like after startup but you're loading the stuff generally right at startup so it kind of feels like you have it the whole time but you don't have the impementation at compile time so we'll talk more about assembly scanning um a question on YouTube is there a video course for plugins I will say I'll I'll put it this way there is not a video course for plugins right now and I will leave it at that I think it's a great question though um the same application can be configured with different plugins so we'll see in a couple um couple slides from now I have a picture of this so I want you to keep this one in mind basically we can take the plugins and we can reuse them in different ways that's the next slide is about reusability so you don't have to change the core application is the point that I wanted to call out on this slide so you can add and remove plugins and not change the core application and then back to the example scenarios I talked about something like building Visual Studio right so as we go through this and I think it's on one of my last slides I want you to think about if you and your engineering team we building plugins for your application or your service or whatever versus how does this change if you're like we're offering this to our customers right thirdparty plugins how like what kind of assumptions have to change what kind of complexity comes up so it's cool because when we're talking about extending things you can absolutely start creating plugins or a plugin system that can have third party plugins get dropped in but what are the implications of that for reusability I'm probably just going to skip this slide and go right to the picture um which is also a hideous picture um so I apologize in advance but I think it will explain what I'm talking about and awesome thanks uh Rotana Ron Buy on YouTube uh yeah D train course thank you so um I have right now there's three courses on dome train I am almost done a fourth one I have started in parallel to that fourth one a fifth one and once the fourth one is done and I have some time I can start the sixth one so again I will I will leave it at that there I'm not giving you spoilers on what I'm making but if you're good at reading between lines you might make your own assumptions okay the the three major pictures I have here I just kind of colorcoded four different plugins at the top but um I want to walk through the first example we could take the same core application I think a good example of this is let's take visual studio right um you could have something for basic users like so not a lot of functionality and you could just drop in a couple plugins to enable a little bit of functionality for really basic users but you could take that same core application and slam way more plugins into it and now all of a sudden it's very featur you've turned on all of these other capabilities so you can do this kind of thing with a plug-in architecture to take the same core app and extend it for power users um on on Twitter high neck is a scanning assembly expensive in runtime it can be depending on on how many assemblies you're scanning and how many types there are and like your your approach for doing it um I would say that in practice I have I have never in never in my professional experience or my hobby projects had an issue with doing plug-in loading um especially because it's most of the time for me it's done at startup now there are other things you can do depending on what your core application has to do to get started so even let's take a user interface example you could put up a splash screen right you might want to show an image for a couple seconds and you could probably load hundreds thousands of plugins in a couple of seconds it depends on the complexity of your application and how you want to scan if you don't want to pay the penalty at run or at startup for doing it all you could say hey when we get into this part of the application we need to now go load these other plugins so you can delay loading some of the plugins if it helps so lots of options for that um and if you are more targeted with your assembly scanning you can do better things um sometimes in most of my hobby projects that I build I do like a very naive approach to assembly scanning so if you watch a lot of my reflection YouTube videos You'll see it's basically like go through the running directory look for anything with the dll extension try to load it like it's not it's not very uh good it's not safe um it's not effective but it works so if you're doing this kind of thing in production you can make it more targeted for sure um and then Steve on YouTube I my application always with the ability to extend it through a scripting engine nice yeah in the early days I used JavaScript for that now I use C they are technically plugins absolutely so a cool idea here um going back to one of the earlier examples I was talking about games um early on when I was building stuff with unity I realized that and actually this is before Unity even um I think it was the time of I don't know if people remember XNA uh someone told me what this stands for and I can't remember anyway it was before unity and it was really fun and I remember figuring out that you could basically take C code and compile it like in your program and then I went wait I can make a like a scripting engine and the the motivation for that this would have been when I was playing uh if people know the Elder Scrolls uh they have a a game in their series called morrowwind and I remember modding morrowwind and writing scripts and stuff um XNA not acronym if I recall correctly yeah uh what I'm going to look it up I need to know um what is it stand for oh yeah yeah okay I understand your your comment now one second let me just pull up the Wikipedia Microsoft xnaa a recursive acronym for XNA is not an acronymed amazing um okay I did I had I didn't know that's what it was very cool but yeah this is kind of what you could use to try building games and c and stuff they would work on Xbox so it's kind of before Unity um at least for me was before Unity so anyway um we're going to go to Reddit after so back to the the slides here um but yeah so I was trying to basically use like you know little scripts that I could add into my game and yes they are very much like a plugin the if you think about running a script you might have a type of script that's like just a onetime fire and forget but if you think about that what does the API to that script look like it might just have a run method on it right that's the API to your plugin you could load in those scripts just a bunch of you know in C they could be a bunch of classes that have a run method there you go um oh and okay the LinkedIn chat is coming through usually build small internal Nate packages with different functionalities to be use in our main app yep is this a similar approach absolutely the uh for feder Rico's uh comment the I think the differentiator is how you load these so if you're using Nate packages and then at when you are compiling your code if you need to know the implementation of those Nate packages like you're just loading up you know an assembly at compile time to be able to reference the types and use them like that's not really a plugin it's close right and you might be building modular software so it's very close but one of the differentiating things here is that we don't need to know the implementations at compile time so you could use a nougat package and not have a like a compile time reference to it you could take the contents of the nougat drop it into your plug-in directory again no compile time dependency and then at runtime you scan for it so we'll look at assembly scanning a little bit but you read through the the dlls and the right folders and you load up the types that you want for your plugin so uh for Federico's comment yes you could absolutely build plugins this way but if you depending on the nougat packages or assemblies at compile time it's kind of from my point of view kind of breaking the plugin approach but you could argue that you're building plugins and skipping the assembly scanning part depending on how you're doing it so we'll keep moving along though the next example I wanted to share was with um this I think the right phrase is called White labeling I believe so you might have seen this depending on your exposure to like supplement companies and things like that vitamins where there will be a manufacturer and they will create a product and then they will say hey look like if you have a brand and you want to slap your your labels and stuff on here your stickers your brand like we'll manufacture it and you pay some cost and then you can resell it so it's their product with you know your your branding on it so what I wanted to show here was not just like a restyling necessarily but you might take the same core application and write plugins where you can just swap the plugins out and now you can provide a different experience to different customers so you could you could think about making a mobile application or even a website right and saying okay I'm going to build this for uh a customer and then you sell it to them right you give them this website or this app and then another customer comes and says I would really love an app or a website that does you know basically the same thing and you go great like I can offer you that and you go basically build a plugin to allow swapping that functionality out the the most simple version of this would just be swapping The Styling but you could change the functionality as well um Steve on YouTube big problem is always haot reload plugins yeah and the keyword that he said is unloading assemblies the unloading part is sometimes hard but if you load them and let them run it's quite easy exactly so um if you need to start unloading assemblies not not a lot of fun but uh basically every application I build it's like just load them on Startup and you have the functionality you need they exist for the lifetime so not a big deal in my case most of the time this final one that I just want to walk through quickly is uh it's an interesting scenario I've had a few times where say uh I've done this the I don't know people might not be aware I was trying to build a nutrition platform it's been about a bit over a year now that I I kind of I don't when I say gave up on it I mean like I think we evaluated that we didn't have a we didn't have the right launch and we didn't have like we weren't onboarding customers effectively so like we failed but that's okay like lots to learn but when I was building that it was a plugin system for our web API and I remember being in this situation where I was like there's a bunch of stuff that I could go you know I could go run SQL commands and change things when I'm debugging but I was like you know what would be really helpful if I could just like call the stuff in code directly and yeah I had a web API I could call but I was like it's to debug it I almost have to go make dedicated like web apis and I'm like this is way too cumbersome so all that I did was I took all of the plugins and I put a console app on top of it instead of a web API so I could load all the plugins up and now I had a terminal with all of my plug-in functionality so the difference is instead of swapping the plugins I just swapped the core application and I had basically a headless version of my um of my whole nutrition platform which was really cool um another this is a weird example but when I was building uh a lot of like the video game stuff from before I'm terrible with Graphics but I really love building the systems for video games so what I would do is I would build a head this is sounds so ridic ridiculous to say out loud but I would build headless video games so the the head to the video game was just a console and then I could you know check all my logic out I could I loved writing this is again sound weird but I love writing tests against it because I was just building the systems to me once I had to start getting into Graphics I'm like I'm not very good at this and it feels like I'm wasting time instead of just like building the fun Parts but that's another example where again you know be swapping out Unity and putting a console app at the top so kind of fun different ways to think about things but those are some plugin examples for how you might organize stuff um testability so this is another little joke I brought up at the at the Dallas uh presentation where I was giving this originally um so some people might have seen it if you're on LinkedIn or uh you know if you follow me on LinkedIn but when I was asked to speak at this uh at this Meetup I did a little social experiment and I said there's two topics that I could present on and I knew what the answer was I knew exactly what people were going to say but I did a little LinkedIn poll and I said would you like me to present on Plug-In architectures or testing now I know software developers because I've been a software developer for 21 years no one wants to hear more about testing I love talking about I think it's critical but no one wants to hear about it I know people want to hear about something that sounds sexier than testing so um I still found a way to try and include some testing because I think it's important but I just wanted to share that I knew that was a social experiment I knew what you were all going to say so um what's really cool about plug-in architectures and testing is that if you have high confidence on a plugin and when I say high confidence I don't just mean like good code coverage cuz I I like saying confidence because that gives you an opportunity to Define what that means in your situation maybe that is a lot of code coverage but I don't know right up to you to decide but if you have high confidence on a plugin and you go develop another plugin because of that isolation that you have those boundaries with the different assemblies and the fact that your plugins aren't reaching into each other you should have very good confidence that you're not going to break another plugin right because of the modularity and the separation when you're building new plugins you should feel pretty good that you're not breaking other plugins in your system so it can really help when you're thinking about how you're going to test things and the part that I wanted to call out this is a bit of a con and then I'm going to explain a situation from from work so you can test the things more in isolation because they are modular and isolated but the consideration that you want to have is like you're moving the complexity okay so more confidence at one point but now your complexity moves because you have to think okay there are plugins that get dropped into this thing to be loaded at runtime how are you shipping and deploying this stuff how does the build system work right because you might say hey look it works on my machine because you have the five plugins there but if your build system isn't dropping that new plugin in that you just added or it is and it's not getting you know uh deployed or it's not getting bundled up after the you know the the first part of the build like you're going to have all sorts of problems so you need to have different you know perspectives on what you need to test when you're building with plug-in architectures so it's more of a configuration type of thing that you have to worry about so I like doing uh I think uh Milan javanovich likes to talk about like architecture tests um I I call them configuration tests sometimes but uh that's because when I'm doing architecture tests for plugins I'm I am generally testing different configurations of them to make sure that they uh adhere to the rules I want to have so where did this come up for me well one example I wanted to share was from the fenic company so uh at the digital forensics company I was at one point leading a very small team for mobile Acquisitions so what that meant is that we could take something like your phone and we were writing software that could extract the data from Android devices and iPhones and so for us we had a bunch of different ways that we could go acquire the data from your phones and again I not don't want to scare anyone this is for like for law enforcement trying to help catch mad people so a lot of the time was used um uh it's actually been used in many types of cases like it could be murders and things like that but a lot of the time as kind of dark as it sounds for like helping catch U pedophiles and things like that so uh it's used it's used for good so when we were building that out uh at the time we had a test strategist working on our team so a lot of the other teams this company had uh testers and developers it's kind of how we were grouped up you have testers and developers on teams and a lot of the testing at the time was very manual I don't know what it's like today I I don't work there so I can't say there's a lot of manual testing being done and the pro oh the problem with manual testing from my perspective is that you do it once right so when you have coded tests you're building up a progression Suite I'm not saying that you don't or you cannot validate things manually like I think that's totally fair to say but if if you're only manually testing through things you lose regression coverage you don't have it so on our small team we're trying to move very fast now we wrote a ton of unit tests and we worked with the test strategist and we talked with him and said hey look we were we felt really good about that last feature right you got to validate it like you walk through it tried it out you feel good about it um we wrote tests on it so we walked through what those tests look like and you felt good about you know high confidence in the tests and so at this point in time everyone feels good about that feature right good okay this next feature we're going to build is going to go into this plugin over here we are not touching a single line of code from any of that stuff that you just tested do you feel confident that we are not going to break it and in the very beginning it was kind of like uh and then very shortly after it was like well yeah you're not touching that code like you cannot break it so as long as we were doing some configuration checks we were in the clear so what was really nice is that it really allowed us to focus on like do the next part like do the next vertical slice do the next acquisition method and we can be very confident we're not going to go break the other things so that was something that was really nice about plug-in architectures for us with respect to testing so I just drew a picture of it another terrible picture but this was just to basically say hey look if you have high confidence on all these other areas including the core app when you want to go add a new plugin in like look like is it going to break everything it realistically shouldn't because it's so isolated that you can test it in isolation right and you have the if you have other tests written on these things you should be able to run the progression tests on them and prove like literally you can't break this other stuff so I'm generalizing here there's anyone who's watching this whether it's live or recorded you could be saying Nick there's absolutely ways you could go brick stuff and you're right you can um so you can design things to to prevent that or to minimize it but there's always exceptions right one of them that we're going to see in a little bit is when we're talking about how we share and provide a um dependencies across plugins because if you can allow plugins to provide a dependency that other plugins go to use you can absolutely break them let's move on okay tools patterns and practices so um this is something I asked the room when I was presenting but it was like there's two really big things I see come up in uh in plug-in architectures and you don't have to have them mastered but I think being very familiar with them helps and the first one is dependency injection so I think it's really good to have a a solid understanding of that again if you don't it's okay but I would invest time into Skilling up and understanding dependency injection and the next one is reflection and I would weigh dependency injection higher than reflection but a lot of the time for loading plugins because we don't have the information at compile time we need to use some type of reflection somewhere to be able to pull that information in that might just be in your dependency injection framework so might be hidden from you but these two things I think are really important um I called out a couple of uh dependency injection Frameworks that I like to use but there are so many others um I like using autofac so I have a lot of videos on YouTube for using autofac literally if you go to my channel type in autofac you'll see a lot so one of my favorites but this all stemm from the fact that years ago when I started using dependency injection the built-in stuff was kind of crappy and I think and that's with I service collection I think they've made tremendous progress uh with I service collection and I service provider so the built-in stuff is very good now um and now if you take something I I hate saying this word because I don't know how to say it and it sounds weird but screw door um if that's how you say it if you take something like that and you couple it with uh the built-in dependency injection stuff you basically get close to autofac functionality and I'm even though I love using autofac I'm starting to find more and more that um using autofac is holding me back when I'm trying to use other thirdparty nougat packages so it's it's getting to the point where I'm trying to say okay autofac I love you but it might be time to start leveraging some other things so that I'm not fighting it as much so I'm kind of doing a bit of a transition to other things like screw door and checking some other things out but these are the top ones that I've used for years uh sorry I should say screw door I've not used for years but uh the built-in and autofac for years on Twitter what should be the preferred way to write test for plugins like test first or test later approach um this is a question that I would highly recommend uh you and your team decide so it's the same reason like and sorry I'm not when I answer this I don't want to sound like I'm I'm picking on you for asking this because I think it's a very good question but I don't like prescribing things like this and there's guaranteed there's guaranteed to be someone watching this who does tdd and that's cool like awesome I'm very glad that tdd works for you and I think that it can work for a lot of people but if that's just not how your brain likes to navigate solving problems and building software then I would never force that upon people I just wouldn't do it and then someone's going to say well that's not what tdd means and make like I'm not here I'm not here to say do tdd or not I'm just saying like there's going to be different scenarios for things like sometimes I write tests first for things and other times I don't the fact that I have the flexib ability and I can make decisions about that I think is a good spot to be in so um generally for me if I want to kind of dig into this question a little bit more um I will write tests first for things that I have very controlled inputs and outputs for and if there's an algorithm involved that I don't have a lot of confidence in so this is a pattern that comes up a lot but when I have to map things between different uh I'm going to call them like coordinate spaces um or across different ranges of things so to give you an example I think a really simple one to Think Through is if you think about streams inside of C okay so you can take a stream of data so just byes and a bite array and like backing it let's say but you can have a stream that wraps a stream or you might say okay I have this algorithm that needs to look at this section of an array and walk through it like those types of things don't work well in my head I don't know why but they're really difficult for me to rationalize I have to draw pictures I've been programming for 21 years and I like I know myself at this point if someone gives me a problem like that or it comes up in code I need paper and I need a pencil or a pen and I have to start drawing it it just it doesn't register in my brain so things like that I will write test for first has nothing to do with plugins in this case um other scenario I I won't and why don't I well at this point in my programming career I write very testable code that's like a goal in how I program is to write testable code so is it always perfectly testable no and just because it's testable does that mean I write tests on it no but I prioritize testability in how I write so that I have the luxury to go back and add tests because a lot of the time if you recall some of my career experience I did a lot of prototyping tons of it guess how much code I shipped versus how much code I tossed away so I know how to write testable code I know how to test but I will often prioritize and figure out is this code worth testing right now because if not you know it might get tossed we'll come back to it so as Steve says tests are a tool to solve a specific developer problem I agree I think that problem is uh lack of confidence or if you want to phrase it a different way to build confidence so um when it comes to plugins though because I want to give some something that's a little bit more practical for uh or actionable for plugins I would say if you need to write whatever uh unit tests on it integration tests end to end tests on the plugin like you're testing that set of functionality do that right get that coverage something else to think about though if we zoom out from the plugin I mentioned configuration style tests so I want you to be able to think about the end thing that needs to package this stuff up what does that look like do you have the right plugins that you expect like is there a manifest of we expect 10 plugins do you have all 10 uh you should be able to test sort of like an end to end sanity check like do the plugins load up right because you're you're starting to miss the compil time check when things are dynamically loaded so I've had situations where things built right and then I drop them in I press F5 in Visual Studio to go run it and it crashes as soon as it starts up because you're moving some things to be more Dynamic so you want to check scenarios like that and I had another one I wanted to mention oh um this concept of like you can set up harnesses for things and the way that I want you to think about this cuz I might be using a different word than some people are familiar with or use it a different way is if you think about like xunit or parameterized tests you can write a fact in xunit which is one scenario you can write a theory in xunit which is parameterized but you can have different types of tests that basically say for each plugin that I have go run this scenario on it and make sure like you can do some sanity checking and call through paths on your plugins so you may have a testing harness or a test in setup that knows to go load you know plugins from a manifest and can go execute and exercise a bunch of them so I think there's a lot of really cool different testing approaches you can take but whether they come first or after I think that's for you to decide and that might change even from Project to project so I hope that helps um let's move on in the slide deck I'm losing my voice okay assembly scanning great we're we made it um there's code on the next slide I promise there's code assembly scanning so the concept here I mentioned it a little bit earlier it's really about how we are loading plugins in because they are going to be dynamic when we're talking about assembly scanning so listed a couple of examples like for me one of the common ones I do is I just scan the running directory look for dlls you got to have a plugin folder if you have multiple plug-in systems in your application you might have them grouped by different folders so you know plugins of type A will go scan the plugins a folder like that kind of thing um Ste Steve saying that CH a plugin can contain its own test yeah like I wouldn't put the test in the shipped code uh for the plugin but you could have a test assembly for your plugin yes um another example I haven't done this yet but I I kind of listed it here because I thought it would be a really cool thing to think through um to be fair at the forensic company we talked about doing this in a couple of scenarios but at the time that I was there we never did it um but this idea of like you start up your application and then something fetches plugins over the wire and what I mean by that is like you go make an API request and download assemblies so you pull assemblies from a server or some source and now you've dynamically configured your application I thought thought that concept would be so cool to do um so I have not yet written something like that but I think that would be a really fun one so assembly scanning is how you're going to identify the following so which plugins that you have to work with and then how you're going to load them in that's really what we're talking about in general so this code snippit is going to look a little weird on this next slide I can explain it because it's hideous um but it involves me explaining how screw Tor and how Auto autac register things so autofac has this idea of a module so a module is just a class that allows you to explain how to register things onto the dependency container if you were building a plug-in architecture and using autofac and having autofac in your plugins what you could do is have the plugins provide modules those modules tell the core application like this is how this plugin intends to register its assem or register its dependencies so you are the from the core application you are giving the capability to all the plugins to say you register things how you want just show me a module and I will call that module and you register however you want so it's a really high trust type of activity because you're put pushing that responsibility out to the plugins now you can flip it around and when we talk about screw door screw door does things sort of the opposite way when it's scanning so both can go scan over folders and look for dlls but what screw door does is that it basically says given all of these assemblies we're talking about like how do you want me to go look for the types that you want to register and how do you want to register them so if you look closely on the screen um this is going to be autofac so if you're not familiar like container Builder is an autofac concept but you can see like it says as implemented interfaces as self and single instance so these are Concepts that by slightly different names exist with the I service collection and therefore with screw door and what this is saying sorry what you can do with screw door say go load up all these types register them as their interfaces and or as their own class and or as like a single instance like force it to be a Singleton so it's a very similar thing that I have on these uh these few lines here but this is done through autofac now what's unique about this autofac code compared to what I normally would do is I'm kind of blending like a screw door approach which is I'm going to reach into all of the assembly and register the types all in a consistent way this is a big ugly for each loop with some link and it registers all the types as interfaces as thems and as a single instance below that I'm doing container Builder register all of the assembly modules so it's doing both Concepts so this is something I uh explored in a sample application where I started with screw and it was loading things in a really weird way that I did not have control over at least not that I could see but I was like what's scor actually doing well it's looping over all of these assemblies and by the way if you're maybe a little bit more new to this and you're like well how do you get an array of assemblies there's a bit of code that comes before this method that just points at a directory or directories and goes and loads dlls assemblies so you can do assembly do load from and then give it the path good morning ex coding good to see you um so that was that's what comes before this but this code that we see on the screen what it's going to do is basically register all the types that it can register these are things that can be constructed so you can't you know you can't make an instance of an interface or an abstract class blah blah blah um but I'm also filtering out modules and I'm filtering them out because I'm going to do the modules dedicated down below um oh and this is going to be a good question I see on YouTube I'm working on trying to figure out a way to create a Blazer hybrid app that pulls plugins from an API hoping to use assembly load context so I can switch between live and pilot from the shell yeah that could be really cool um I was expecting to see something about the render modes and having like the client side versus server side because uh as someone who builds plugin architectures my first Blazer app that I tried to make I didn't and I still am very new to Blazer but I didn't understand the render modes and all of the dependency injection was just a nightmare because it's it's literally two applications at the same time so anyway um yeah I think there's a lot of cool stuff we can do with blazer I think there's some challenges too with um I'm forgetting the ronm um someone can blast me in the chat for not knowing it it's fine the um the way that you can compile down like web assemblies to like to to be really reduced in size I can't remember what it's called but basically can break a lot of reflection so I think some interesting challenges coming back to this code though this was me navigating away from screw door still trying to get some screw door capability so the whole block at the top is screw door like then I'm doing the autoa stuff with the modules and then at the end I'm wrapping the whole thing in this autofac service provider so the rest of my application still thinks it's using the built-in stuff the I service provider so um infected FPS it's not yeah aot there we go it's not I was going to say it's not called minifi but Steve said it's aot um so and then I simp humor it also allows shipping updates without going through the store yeah this um I I don't I I can't talk about the forensic app cuz I don't know if they ever started doing something like this but the idea was that basically we could configure things um like on the Fly Right like this as a general concept so I think that's a super exciting thing to explore okay so that this is some assembly scanning minus the part where I was going over directories uh something I touched on briefly in my presentation in Dallas was um all the stuff is loading loaded dynamically it's at runtime it's not a compile time thing where you understand the implementations of the plugins so calling that out but are you going to load all of the plugins right at startup which I think is the more common approach basically everything I've ever done is like that um you know even as as we're seeing in the chat the chat where our simple humor is talking about this Blazer hybrid app that might be this other variation where you've already started up the app and you're while you're running so after startup you go hey we want to take some action to load plugins now I don't know about the implementation that they would like to go follow but um another example of sort of delay loading them is so visual studio doesn't do this um does vs code do this I don't use vs code enough to remember but Visual Studio when you want to add an extension it makes you restart it because it's going to load it on Startup but if you imagine you're using visual studio you download an extension and you get the extension right away like that would be an example of like sort of like delay loading these things um I think a good use case for that is if your your application or service takes a long time to start up I think maybe probably more common in like third party plug-in support especially with user interfaces it feels very disruptive if someone's like I have to go close down all of this stuff to get that functionality like ah that sucks like I was kind of already wanting to do this workflow why do I have to go restart so you could dynamically load things up at that point I think that's a cool opportunity but these are design decisions you can make and uh you might want to weigh the user's expectations and the the technological like constraints that you have okay moving on um this one was kind of brutal to explain to an audience because I really should have drawn pictures here um oh cool thanks infected FPS vs code used to have to restart the electron app in the editor now I believe it's own service or something in the Eder that just restarts the plugins yeah so they might have done something that makes it look like uh you know they might be restarting part of it but it looks like a very cohesive experience so yeah you can do clever things like that that's cool okay I'm going to talk about this slide I'm going to try my best here to explain it um again sorry if you're on Instagram watching this because it's it's vertical and this is a very nonvertical uh presentation so um I want to talk about who gets to provide dependencies onto the container and who gets to consume them now as I say this I just want to call it out because depending on who's watching this when they're watching it it's important I'm not saying there's only two ways to do this because I have two scenarios I'm just saying I want to walk through two scenarios and then we can see what's going on so in the first scenario I'm talking about the core application having a dependency container that registers like core functionality or is responsible for core functionality so the core app in this case would be responsible for plug-in loading makes sense but it might also configure the logger configure Telemetry um maybe it's responsible for setting up the single database connection and that means that these things are now services that are available for all the plugins so when the plugins are loaded up they could ask that that same dependency container hey I need a logger and it's provided through the container from the core app right so it's kind of flowing from the core app to the plug-in and that plugin can ask for the logger or the Telemetry uh service or how to connect to the database then the plugin itself could say like okay and here is my plug-in implementation whatever interface it needs to meet and give that back to the dependency container so you have some core Services flowing to the plugin and then the plug-in API back to the core app so the other way that you could look at this is like well what if the plugins themselves could Define that core functionality so you'll notice the three things that I had up here I'm you could imagine there's even more plugins but I'm now pulling that functionality out and the core app is literally just like this super lightweight shell I say shell I don't mean just like a console app I mean like it's a it's a skeleton of an application it's very thin it loads plugins that's all it does essentially and then the plugins themselves can Define the implementations of these core services so um well okay I'll give you a spoiler alert on my next screen here um this is something from uh a product I'm building called brand ghost so brand ghost is the thing that I'm using on my social media platform so uh a lot of people will say hey Nick like how do you like people commenting that Dave Ken was pretty funny on Twitter the other day he's like I don't think that you you sleep or like you have more than 24 hours in a day because he sees that I'm always posting content now I use something that I've built with like low code uh to to do a lot of it but it's had a ton of limitations so I started building out brand ghost to be able to do all this for me so brand ghost is very much a plug-in based system and the way that brand ghost works is that it helps me I take the content that I create and I write so whether that's blog articles or social media posts and I I have a system where I've kind of curated that content into it and brand ghost is the thing that does the publishing for me so if you're ever aside from comments if you are ever like 99% of the time if you're reading a post of mine on social media I did not write the post on that social media platform I wrote it and then I put it into my brand ghost system and brand ghost publishes that content for me so brand ghost is great for plugins because there's a lot of social media platforms and this is one of the the concepts I wanted to kind of relay here because I think it it sort of makes it obvious of situations for using plugins so you can find cases and applications where you have say like a different implementation of a general type of functionality it's a kind of a weird way to say it but to give you an example if I want to make a social media post the concept is that I probably have some text Andor a piece of media and or a link right like these are some common things that you would see coming up on social media posts and then I want to go put that onto some social media platform so if we think about say like Facebook and Linkedin having a plugin for Facebook and a plugin for LinkedIn allows me to basically have a way that I can go talk to these things in a common way which we'll see in just a moment and we can say I want to go make a post and I have a different plugin for how to go do that so so I can keep extending brand ghost for all of the platforms so I post to between 10 to 15 social media platforms every day and I don't do that by logging into each one of them and posting I use brand ghost so I can build out the plugins for that but the other interesting thing from the slide that we saw before and it might be kind of hard to see in call out so I just want to point it out to you is that not only am I offering the social media plug ins but like if we have a close look I have a logging plugin so logging is not a social media platform it's actually functionality that gets shared so all of my plugins or everything in the app uses the ey logger interface just Microsoft's ey logger but the logging plugin is the one that provides the implementation of that so if we jump back to this one right it's very much this situation right here where I'm able to have a plugin to find some of that core functionality and give it back to the dependency container and then in a lot of the other cases like the social media platforms those things are heavily consuming core services and then they're providing like their one small plugin back to the dependency container so I just wanted to give you that uh example to kind of think through because this is a a screenshot of my solution Explorer at one point in time time and I think that it sort of articulates those things pretty clearly let me know if you have questions on that of course I'm just checking the chat uh script engine is a good usage for that um my customer can edit a script and the changes will be immediately compiled reloaded and reflected yeah so a perfect example of not having to restart the entire thing just to get a change that's great Dynamic loading assemblies and Blazers Blazers hard yet you work in a WM runtime so web assembly uh so you have to reload the what was something contacts to reflector changes yeah it's uh I feel like I haven't spent a lot of time in Blazer but I feel like my work is going to be cut out for me doing plugin stuff and trying to use Blazer uh effectively so uh that'll be some exciting times okay I have a little bit more code coming up here uh I wanted to talk about say like a a simple implementation and the other thing that if you see about stuff I post is you might know that I am like a obsessed with using facade design patterns I love using them and this is an example of a situation where we can use facades so I want to explain this but this is an interface uh so I was talking about posting to social media with brand ghost so we have an interface that allows us to Define sort of like plug-in functionality so it has a method on it for whether or not the plugin itself can handle a a particular social media platform um the ignore the third method for now doesn't really matter but it also has this Tri post so you can try to post some content uh I'm using a custom result type thing that I've built so if you're like Nick what the heck is that don't you worry it's not really relevant right here the part that is relevant is the right hand side of this whole slide so to call it out the different plugins like Facebook in stagram LinkedIn they would implement this ipost content Handler from the left and then we could have something like this facade and what this facade is able to do is take in the collection of plugins that meet this interface um this would come off of the dependency container so we would ask the dependency container for the Post content facade usually give it a different name and um when you resolve that it's going to feed it in these plugins now the the goal of the facade is that you're hiding complexity so by calling it a facade in the class name it makes it kind of funny because it's like you're telling people it's probably more complex than it looks so I generally don't slap the name facade onto my facades um the X suffix is uh for exception because I also have a tried result that's just booleans as well and a tried X null for nullable uh results coming back to you so that's my I don't use one of but it's it's my version of one of I like to build my own thing sometimes so so in this facade if we look at what it's doing it's basically saying I have some content to post so this is the API in my code that I want to use everywhere and it checks do I have a plugin that can handle this if not it would have a better exception message than this or return a result type right you can see it's returning a new exception it's not throwing an exception so I'm using implicit conversion implicit casting to be able to go into this tried X result type I have YouTube videos and stuff on that and blog articles if you want to see how that's done that's why I can return an exception not throw it which is kind of fun and then you'll notice if I have a Handler that will go posted so the idea here is that using a class like this I can compl completely hide in my core application that I have plugins in the first place which is pretty cool because if every spot had to go okay based on the scenario for each plugin let's go find the plugin to load like no one wants to see that everywhere just slap it behind the facade make it look pretty move on right you write the API you want and put the messy code behind the facade this one's not so bad but you can imagine they get pretty gnarly okay we're almost all the way through it folks so gotchas right so I love plugins probably might have figured this out by now but pros and cons to absolutely everything um one of my favorite people for talking about this kind of stuff in general is Derek Co Martin from code opinion um if you're watching my content I can almost guarantee that you have seen his content because he is a big YouTuber he's extremely awesome at explaining things and my favorite thing about D is that uh he must have opinions about things because he's a human but at the same time he's so good at um kind of like taking these really unbiased approaches to things and you'll hear him say context is King all of the time and that's because there isn't just one universally right or wrong answer to things and he really does a good job of uh of explaining that so highly recommend Derek Co Martin of code opinion because he does this kind of thing really well so I mentioned earlier one of the gotchas is complexity into configuration so yes if you're going to go do a bunch of stuff at runtime you are losing compile time checks of do I have the right plugins now you have to go check this somewhere else you can write tests on this kind of thing um so there's ways you can work around this but the point is that you've moved the configuration complexity sorry the complexity to the configuration so that's one thing um this one is kind of funny because I glossed over earlier in the talk if you have other like third parties making plugins for you you now have this really really challenging version problem so if you own all of your own plugins right so your development team is the one making the plugins you if you have a lot of plugins you can have a versioning challenge if you're like hey we need to change the API now we have to go change 300 plugins like that sucks um there's probably some uh some rosin tools and stuff that you can use to refactor that faster but it's it's manageable now if you have a thirdparty ecosystem and you're like hey we want to add one more extra mandatory parameter like do you do you really want to do that and go break every single plugin and how can like can you force people to update so you have to be very careful about versioning for plugins um you know if people are experienced writing you know versioning apis and stuff and having different versions of clients connect in very similar type of thing um so you can you know you can solve these problems but it's it's definitely complexity so something to think about um I have some questions on Instagram but I cannot read the language plugin architecture significant complexity oh I think they're they might trans they're translating it I will send a happy face thank you for the chat I can't read the language though uh hello Nathan from twitch good to see you um the other thing I wanted to mention is like it's not really a necessarily like a plug-in problem but especially in the plug-in architectures I build we end up if you're using facades a lot like me then you run into this sort of uh fan out challenge when you're debugging and what I mean by that is like you hit a facade in your code and you step into it and you go oh this is a facade not so bad on the surface but then you realize the facade is hiding all of the gross code to go pick a plugin now you have to go step through a plugin and if you have layers of plugins and layers of facades it gets messy quick so the point here is that you might might start and think that you're you know kind of scratching the surface just to find out that you have to dig a little bit deeper and go into plugin implementation so you might not be ready for that kind of stuff so it can just create more complex debugging scenarios okay and the last little bit here is just talking about some of my uh professional experience using plugins so I mentioned the digital forensic stuff um one thing I didn't call out was that in digital forensics it's really important that you need to be able to take the data that you recovered and it needs to be used in court right you need to have this information that's been collected to investigators and examiners can use and how do you go share it how do you go you know give it to attorneys how do you make it so they can present it in court you need to be able to export that data so exporting again that's the common General functionality but we have different implementations of the export so you have different plugins to facilitate that uh I talked about the mobile device acquisition uh the third one I wanted to talk about uh just in a high level is like the digital forensic tool was essentially a a complex search engine for recovering data and organizing data so in for digital forensics the the word for the types of data you recover are artifacts so recovering artifacts from these digital devices so we would have plugins effectively plugins for the different artifacts that we would support for recovery so there would be hundreds of artifacts that were supported as part of the search engine uh meal coach this is the nutrition platform I mentioned earlier in the presentation that's the nutrition platform that I stopped building because it wasn't a great uh weren't great at the the sales part uh that was all built a lot of vertical slices so uh done every feature was done in like a vertical slice approach but they was all plug-in based as well so kind of blending those two things together brand ghost same type of idea I showed you my my layout in the solution and I talked about the social platforms and then for myself yes I love building role playing games I have not dedicated time to it in a couple years now um probably 3 years now it's I when I moved down to Seattle and started working for micro soft I I started building the role playing game again because I wanted to dive into some stuff and and build so uh that is heavily plug-in based um you know all of the different content that can be passed in is plug-in based all of the different systems in the role playing game are plug-in based so um yeah it's just something that I've been building for a long time so I use plugins everywhere and I will admit I use them a little bit to a fault like everything to me looks like you can use plugins for it so I joke about this because in my own personal development I'm going to use what I like to use what I'm comfortable with so be it if I'm building stuff on a team or we need to prioritize shipping things to customers and people have different opinions I'm not going to say hey it has to be a plugin architecture I will say it has to be C though no I'm kidding but the you know I'm going to work with the team and come up with whatever makes sense so uh I like plugin architecture but they're not a silver bullet so that is the presentation the last little part was just me trying to pitch things to the audience a little bit um but courses so just to quickly share yes folks I do have courses if you want to learn c um I have the getting started in Deep dive ones these together are 11 hours so especially if you're just picking up C it's a great package you can get there's a bundle for it which is 20% off uh so again if you're like hey I'm just getting into programming or I want to switch I know a little bit of JavaScript and I want to try out C these are great um I never promise people because I think it's false advertising you will not be a pro C developer after these two courses but you should understand the fundamentals and you should be able to build basic applications so um I always encourage people to code along side to be building things and then leverage things like courses or tutorials to supplement courses can be valuable if you are motivated by accountability I'm not the one to say that that's the best way to do it or the worst way to do it but uh when I was doing bodybuilding I've been doing been bodybuilding for as long as I've been programming and I still hired a coach because I wanted the accountability so something to think about I do have this refactoring course available as well that's my first dome train course and then I mentioned earlier in the Stream I have one more on the way plus another one I'm doing in parallel and then once that first one's done I have another one that I will launch um shortly after that or start building shortly after that so um bunch of courses coming but that should be an exciting time so uh folks that is that's plugin architecture for net so I hope you found that helpful I'm going to share again um Sor I'm jumping around here if you go to products. deev leer.com or whatever but just a few more notes so if you like this um obviously this video is recorded so you can watch it on YouTube and wherever else but if you're like hey I just want to be able to click through the slides at my own pace you can download them totally free so feel free to do that um and then I think when I do more public speaking I'll try to put my slides and stuff up on here and if I do this talk again I if I'm updating the slides I will try to update this product page so you can have the the new versions as I as I iterate on it so all right folks um that was actually a way longer talk than I thought it was going to be for this stream so um I might I might call it there for the Stream So as I'm wrapp this up if there's any um sort of last minute questions and stuff I'm happy to answer um but I I'm on call for work so I have to start to be up and ready for work by 6 o'clock in the morning which means there's no sleeping in or anything which means um I got to go to bed pretty soon so um yeah if there's any last minute questions whether it's about plugin architecture C software engineering in general I'm very happy to answer if I can just uh feel free to ask away uh start reading the chat so project in my first job we used a plug-in setup kind of like this not as well implemented basically a contract management system cool okay it got a bit unwieldy by the end though yep use them for operations after specific events complex external validations yeah definitely wish I had access that old code would love to try and refactor yeah that's and you know uh I don't know your background and um kind of the stuff that you're building but it's a good call out actually um not just for plugin architectures but if you're ever like hey I wish I wish I could try this different architecture I wish I could do this like if you need opportunities to build stuff like literally going and refactoring some code uh and just trying to see you don't have to finish the whole thing necessarily but if you're like how would this work with plugins like it would be a good exercise it' be really fun depending on how if you're nerdy like me um be really fun to to go look at that code and say okay well what are the common like what are the things that are common that we're doing and then like how do I pull the implementations out how do I make the right interface to be able to talk to these common things like it it becomes a really interesting set of constraints to try and play with so yeah I think that would be fun for sure um do a last check there's a bit of a delay obviously because it's streaming but um if folks have questions I'm waiting a couple more seconds to see if anything's rolling in in the chat uh I will remind folks too that because I am on call for work I'm not going to be streaming in the morning but going forward next week yeah next week should be fine um I go I go on vacation shortly after that so um I think that's on Wednesday though so yeah I should be good so next week Monday uh at this time I will be streaming in Tuesday morning so the very next morning at 7: a.m. be up bright and early I'll be writing code I have no idea what I'll be coding um I have more quartz.net videos coming out this week I did have um someone reach out to me and ask about some link stuff and they have all of these link extensions and and I might make a bunch of videos on these link extensions so um that might be what I dive into next Tuesday your inputs on GC versus Arc I actually don't know what these two acronyms are uh rshh so um maybe I can search them but if you want to take a moment to elaborate um oh garbage collection I don't know what Arc is though sorry I'm reading the reddits because I've never heard Ark before Oh automatic resour reference counting that's called Arc I didn't know that um so okay I have a little bit of an opinion here but this is It's not like grounded in like data unfortunately so I don't have um I'm not going to give you like a good like engineering analysis kind of answer um if I understand correctly if I do and I might have this wrong so I apologize if I have this wrong but I believe when I was coding in an internship we had to use Objective C and I believe Objective C had automatic reference counting I think so I might have this wrong um but I can remember that feeling like a total pain in the butt um so I think the way that I would look at this is like we have we have tools like the programming languages we have our tools right and they're going to have different characteristics whether that's garbage collection or or reference counting the I think for me garbage collection is just very nice because as long as I do the things where I'm not holding on to references and I find in like typically when I'm programming it's kind of hard to mess that up but it happens um because you still can get memory leaks in C for sure so I find for me works really well and then ultimately it comes down to like okay how do I allocate fewer times the one could argue well if you're using like automatic reference counting like you're in controll that you have to be thinking about it but my point is like I don't want to be thinking about it I just don't I'd rather be and this is my my personal opinion like I said it's not like engineering uh data analysis backed um but for me it's really just like I don't want to have to think about that kind of stuff I just want to build the system and then when I'm doing performance analysis I will go oh am I am I abusing this a way that I shouldn't be like can I go refine this so I think that's my stance is like I do prefer garbage collection um but yeah that's probably not a not a solid answer so I apologize but I think I think objective CU use automatic reference counting and I was just like not a fan of not a fan of it so um what have you been using for Native aot I have not been using native aot these you guys have good questions today um I and I have terrible answers so I apologize yeah um I have not uh like I use a lot of my time building stuff right so um whether that's content or my own project so I I find myself often in this scenario especially creating content I go oh I need to go make content about this topic but if I haven't used it yet like I can't talk about it because I don't want to do that where it's like I don't know I just like pull up someone's blog and like read the read what it's doing or something so I want to be able to tell you from you know my own exper experi using it but I have not used Native aot so I do apologize I don't have a good answer there um yeah I have I have a couple things on the go right now that don't afford me some of the time I'd like to go explore some things like that but um I think after getting through some courses for Dome train and uh getting brand ghost a little further along um I'll see if I have more time for uh for jumping into some Blazer stuff more some native aot stuff more but yeah sorry no no good answer on that okay folks I don't see any more questions that came in uh thanks for the questions in the chat I hope that um I hope that was okay for answers and sorry it wasn't amazing hello on Instagram I think you might have just left um good timing because I'm about to hang up on you um but yeah thanks folks um I liked and subscribed to genuine response awesome thank you I appreciate that so much uh and I did want to say thanks to everyone for tuning in again Mondays 9:00 p.m. PST this type of conversation this is actually a little bit more uh net and C based than usual usually it's just a general software engineering Tuesday mornings not tomorrow um at 700 a.m. I will be live streaming code and building stuff so if you enjoyed this kind thing uh definitely check out the coding stream because that's uh the audience is usually like double the size and um it's humbling because been programming for a while and I still mess stuff up and it's really cool to have a you know a whole chat behind you going no no no like here's the answer it's like PA programming like with 200 people so pretty cool okay folks thanks again I appreciate it I hope you found this valuable