What I like the MOST about Nick's videos is that he goes over things that I have taken for granted and inspires me to dig deeper. Config files are a prime example. So easy to get them to work and just leave it be, but so much I have missed by that behavior.
Azure has had App Configuration for as long as I can remember Or one can use the IOptionsMonitor to retrieve/change stuff in their configuration without re-compiling their app 😉
Nick, you got my back into doing my private projects after work again. I feel like I'm getting my energy back to try improve my coding abilities. I will explore your channel further for sure!!
Great Video, thanks. Also with IOptionsSnapshot and IOptionsMonitor I always tend to implement the IValidateOptions interface to save guard against invalid parameters.
Great stuff Nick, once again I learned something new from you! Question for you. So why not just use IOptionsMonitor or IOptionsSnapshot instead of IOptions for everything? The only reason to use IOptions is if you explicitly don't want the values to change at runtime. I'm assuming there are performance hits using the monitor or snapshot which is why its common to use IOptions?
I Also hope Nick can add into that part as well. Ever since the first time I've learned about the existence of IOptionsSnapshot, I've wondered the same thing as to why do we see IOptions everywhere instead of the other types. I personally had planned on using the IOptionsSnapshot in future projects even if I'm not sure whether I want the "hot reload" feature of it or not; just to be somewhat future proof. The only somewhat concern I know of is to keep in mind how each IOptions type is injected (singleton vs transient vs scoped) and how that may lead to the captive dependency issue depending on the use case
You're right, probably a case of if the logic in IOptionsMonitor or IOptionsSnapshot is needed. For example you would use IOptions when you are not expecting your config values to change. If you are not expecting them to change then you wouldn't want to use IOptionsSnapshot. Similarly, with IOptionsMonitor, it just exposes more functionality such as OnChanges. Just depends on your use case
Great video - would be nice to see the same thing for Azure App Configuration (and working with Azure Vault) :) When you write "like a pro" in title, I would expect you to talk more about proper handling of "secrets" and maybe even quickly show how you set up authentication (you mention auth briefly, but don't show it at all - it's pretty important - else viewers might end up hardcoding "secrets" into codebase and submit to repo). Since I know how much you are into performance/benchmarking, you could have touch on that aspect of reloading Options with different strategies.
I already have a video on how to do this with secrets using Azure KeyVault and certificate authentication. The video focuses on simple configuration rather than secrets. Secrets can be managed using this same service (with the KMS integration and is mentioned in the video) but it was never the focal point of the video. Auth in AWS is way simpler than Azure. A service either has access to another service, through security policies, or it doesn't. When working in AWS you almost never have connections strings and secrets to access other services. You have VPCs, security groups and IAM roles.
@@nickchapsas thanks for your reply! ☺️ I assumed you would link and refer to related videos - should have checked your library I guess 😅 Azure does have identity based security (between services/resources) to avoid use of credentials as well. I think the official name is "Azure Managed Identity", but I might be wrong.. also not sure how AWS and Azure are different, but looks like it's working more or less the same way to me - I mainly focus on Azure myself though 😅 So I might be missing some of the great features of AWS ☺️
@@nickniebling It does but it also has connection strings which AWS doesn't. I have worked with both AWS and Azure at really high scale and there are things that I like in both areas. I think AWS has better services and a more clear security path but Azure has, in general, better SDK and documentation for .NET developers. Ultimately each provider gets inspired by each other. Choosing a cloud provider is 99.99% of the time a business decision and not a technical one.
If your using AWS ECS, there's another way of using AWS Parameter Store, without having to use that nuget package. You can add environment variable in the task definition and specify to get the value from Parameter Store. However you won't be able to refresh it's value at runtime
@@nickchapsas What I'm trying to say is that you can setup environment variables in the task definition for your container and their values can reference a secure string(encrypted using AWS KMS) from Parameter Store. As for splitting configuration in multiple places, I don't see it like that, you can use this approach if you have your environments in different AWS Accounts and you might have different configuration values per env, like connection strings. If I don't need to change configuration at runtime my personal choice will be to have the configuration in appsetting files and overwrite them from task definitions.
@@rogermurariu2448 Hello mate, is there any way I can contact you, I am trying to get my configuration in the way you just mentioned, I just need a way to store configuration inside appseting files, I set up everything else inside the task definition and parameter store.
Options pattern in ASP.NET Core Docs for anyone more interested: docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-6.0
These options interfaces are really handy and I was not familiar with then. However, when using this approach together with SSM I think you run a risk of exhausting your SSM get parameter quota as you will check for updates to SSM on each request and the default quota for this API call is quite low. It's assumed by aws that developers only read from SSM on application start up. I'd be strongly inclined to create some kind of internal cache that checks for updates when a timer elapses if there's a need to update these settings without an application restart or redeploy. However, I manage SSM parameters from the cicd pipeline of the application so these restarts are automatically done if the parameters are changed from the pipeline.
On demand changes are fine but realistically, if you need to do this then restarting the app might not be an option. Let's say you noticed some weird behavior and you wanna get more into on the running app. You might change the minimum log level to debug. This can't be done in the way you described because you just lost that bad state. Realistically that TimeSpan would more more around the 5 minutes mark than a short one.
I'm actually running lambda so the state is gone anyway, but I allow for log level changes per event (and pass this change along the rest of the request chain) to achieve a similar goal. My point was if you naively put the combination shown here into a production environment with high load and a high number of instances you will hit the quota of the parameter store. However, it seems AWS now allows this to be raised so it less of an issue than it once was.
@@thomaskmfdm Well actually the state might not be gone in lambda. Static members in lambdas are reused because lambdas aren't disposed after each execution. They stay in memory, warm, until some minutes of inactivity, so in this scenario, unless you are loading the whole lambda configuration per execution (which would be a performance problem) the config stays the same.
This might be your only video, where you have explained things very intricately without worrying about the length of the video... Please have the same approach for all your videos
Great video, thanks! Awesome speed of explanation and all other needless stuff just got skipped, making every second of the video worthy! Just wonder how grabbing settings from the cloud service hits performance. I guess if the app is running in the same cloud it shouldn't be a concern. But if the app is running on-premise? But sounds like a price to pay for the ability to change the config in a runtime.
What is the "official" way of writing back to appsettings.json from the code? I've seen people mentioning the need to implement custom JsonConfigurationProvider that would override .Set() method but no clear examples
Can we use Options pattern to inject non-config values too? like say a Customer class being injected with Options of Customer name, age etc... thnx... in general how can this be achieved with DI? Factory? What if a dependency needs a GUID each time it is instantiated?
The centralization of config is why I've made my own service for running this on-prem. You can check it out on Github: poteb/ConfigurationService But it's not just simple configuration, it uses json refs to compose a configuration from smaller parts that can be shared across multiple configs. I still need to make a nuget package to load the config from the API and add to the application config.
Great summary, thanks! How do you feel about taking IOptions as a dependancy for business logic/domain level objects? Should it be abstracted at presentation/infrastructure level or passed down?
If you only even wanna deal with a singleton object of options, then you can just register the item straight in DI. If you need it to be updated in runtime then snapshot or montor are better alternatives and in that case I would also use IOptions
What tool are you using to annotate the screen Nick? For example at 1:40 drawing the rectangles. I know there are many tools for doing this but there is always a better one around the corner :-) Thx & keep up the good work
A configuration change at runtime is a code change. This should require all unit and integration test to rerun. In my opinion configuration should never be changed at runtime and should require a redeploy. Very interesting video thanks for sharing :)
I completely disagree. If someone is so fundamentally different that makes you need to run your whole testing suite then that value shouldn't be configurable in the first place.. For example, if you notice an abnormal behavior in your app when running and you wanna capture more data you might update the minimum LogLevel to Debug to capture as much info as you need. That's not a code change and doesn't need to go through any pipeline. Same goes for how many consumer threads you might wanna have in a long running consumer and I can go on forever. I'm completely against that statement and I would be seriously worried about what's in those config files that would make someone think like that.
@@nickchapsas Agree that log level changes are safe. When changing connection strings or anything that changes how the code operates - that's where I would want to have some sort of validation run on the new value. Typos and the like could cause big problems. But you are right, some of the config I have had to deal with in the past is a bit bloated :)
@@nickchapsas Agreed! That's why I try to get all of my fellow engineers to watch your videos! You're always putting out great content that is simple to do but can make your APIs so much better! Keep up the great work and thanks for all of the great content!
You mentioned that using IConfiguration is something that should be used regularly. With that in mind, how would you access configuration parameters during service registration/within ConfigureServices? It is my understand that you can't access the IOptions interfaces at that point, and only should be used after the app is buid. Is this correct?
Nick, what do you advise for an on-premise param store, i was thinking hashicorp vault considering its dotnet library was solid, but this was way more seamless
I’ve actually never used an on prem parameter store. I’ve only ever used AWS Param Store, AWS Secrets Manager, Asure app configuration and Azure key vault. I’ve only ever worked with cloud so on prem was something I’ve never done
Cool. Didn’t know they had this and we home rolled a similar method. If you were deploying this, I’m assuming you need to set up that config options class to feed it AWS credentials… or is the lib smart enough (and permitted to) to somehow use the region and credentials for where your app is deployed?
Well explained. Big plus for explaining how IOptionsMonitor and IOptionsSnapshot works because not much people knows how to use them. Do you have way to update on the fly options that are used in Startup.cs eg. CORS settings?
Please notice that you can also edit the appsettings.json file itself at runtime and by default (reloadOnChange: true) you can propagate the changes with the same interfaces described here. See: docs.microsoft.com/en-us/aspnet/core/fundamentals/change-tokens#monitor-for-configuration-changes
Why don't you use your own configuration DB, such as SQLite DB, and sync configuration in DB with default configuration from appsettings.json? In that sense, the default configuration will always keep unchanged for any particular stage of the application in production.
Always excellent content here! I have been using IOptionsMonitor for a little bit, but I like this concept from AWS too. Offers a central hub for managing multiple api's or console apps.
@nickchapsas Hi Nick. You mention in your AWS videos that you've authenticated your machine against AWS. Would you consider doing a video on how you do that, or could you point me in the right direction as I've not had much luck in my searches about it? Thanks.
So with IOptionsMontor and IOptionsSnapshot, would these update at runtime if the appsettings file is updated? Or if the ASPNETCORE_ENVIRONMENT system parameter is changed?
@@nickchapsas this also depends on how the provider is added to the pipeline, since they all (I think all?) have a property for reload on change, which can be enabled or disabled. Then the question is if the provider actually honors them.
So does AWS AppConfig. I specifically wanted to showacse Parameter Store to focus both on the service but also on the IOptions stuff and the Configuration Provider.
I wonder how this works in a multi tenant scenario (so hundreds of isolated databases, same schema but different contents , and only one web application). Then based on the login the system will have to provide a connection string and all other needed options from a provider e.g. a EF configuration provider or in your case an AWS configuration provider. So probably ... this will then become part of the claims in the token for such a user. (havent tried it but just thinking about this while viewing the video). Can't judge if this then each time passes the builder (which then has a dependency on the request, so auth must already have happnened while builder "adds" that later). (assuming all distributed caching includes the tentantid in the cache key) (and assuming EF has no unknown specific stuff). Ms Refers to Orchard but dont know if that is generalizable useable.
Its not that nice at all. When you create PR you will not see config changes needed for your code. Now you need to come up with process to manage it. What will prevent you from deploying code without adding settings first?
In lack of a better word, you made a mistake in the video. You show the Value/CurrentValue from the snapshot/monitor being stored as a field. It is recommended storing the IOptions "variant". Reason being that you can accidentally store settings in a e.g. singleton that then does not get updated when a setting change. You probably know this. But a new developer might copy your implementation in places where it would cause a bug.
I am not expecting anyone to store the value as a field since the only reason to have the options object registered is to inject it as a whole. Storing each value would defeat the purpose. I have to assume a lot when I make these videos, so here I assume that people understand how Dependency Injection works. If they don't, then they'll figure it out one way or another.
@@nickchapsas I understand. But perhaps you could mention when doing the opposite of the general recommendation, for the sake of making an example. Oh, and congratulations on the sponsorship. I know nothing about aws, so I'm excited to see your videos that show aws feature :-)
Ask the Azure marketing department 😂I've been working with AWS at very high scale for the past 3 years. I think i can offer more value with AWS advice and the AWS marketing team was kind enough to sponsor some content so two birds with one stone.
@@dhineshkumar.m Because it gives you access to everything about the app's configuraiton. You should narrow it down to only the things that conern the Controller
@@dhineshkumar.m You want to keep your controllers clean and free of any logic. You would have services for that, even though, lately and with the large adoption of the Mediator pattern, The only service you would inject into a controller would be the Mediator, Nothing else. Google for "Thin controllers" to learn more.
What I like the MOST about Nick's videos is that he goes over things that I have taken for granted and inspires me to dig deeper. Config files are a prime example. So easy to get them to work and just leave it be, but so much I have missed by that behavior.
I am really excited to see that you're sponsored with AWS now! Your content is always fantastic, definitely deserving of sponsors.
I was thinking the same!
Azure has had App Configuration for as long as I can remember Or one can use the IOptionsMonitor to retrieve/change stuff in their configuration without re-compiling their app 😉
Yeap, Azure App Configuration would be the Azure alternative for this
Nick, you got my back into doing my private projects after work again. I feel like I'm getting my energy back to try improve my coding abilities. I will explore your channel further for sure!!
Great Video, thanks. Also with IOptionsSnapshot and IOptionsMonitor I always tend to implement the IValidateOptions interface to save guard against invalid parameters.
Nick, I can see the amount of time you spent reading the horrible documentation docs :D thank you.
Could have done with this video 2 years ago when I had to work it all out using AWS documentation!
Great stuff Nick, once again I learned something new from you! Question for you. So why not just use IOptionsMonitor or IOptionsSnapshot instead of IOptions for everything? The only reason to use IOptions is if you explicitly don't want the values to change at runtime. I'm assuming there are performance hits using the monitor or snapshot which is why its common to use IOptions?
I Also hope Nick can add into that part as well.
Ever since the first time I've learned about the existence of IOptionsSnapshot, I've wondered the same thing as to why do we see IOptions everywhere instead of the other types.
I personally had planned on using the IOptionsSnapshot in future projects even if I'm not sure whether I want the "hot reload" feature of it or not; just to be somewhat future proof.
The only somewhat concern I know of is to keep in mind how each IOptions type is injected (singleton vs transient vs scoped) and how that may lead to the captive dependency issue depending on the use case
You're right, probably a case of if the logic in IOptionsMonitor or IOptionsSnapshot is needed. For example you would use IOptions when you are not expecting your config values to change. If you are not expecting them to change then you wouldn't want to use IOptionsSnapshot. Similarly, with IOptionsMonitor, it just exposes more functionality such as OnChanges. Just depends on your use case
you pay to retrieve values from AWS. Cost/Benefit
Great video - would be nice to see the same thing for Azure App Configuration (and working with Azure Vault) :)
When you write "like a pro" in title, I would expect you to talk more about proper handling of "secrets" and maybe even quickly show how you set up authentication (you mention auth briefly, but don't show it at all - it's pretty important - else viewers might end up hardcoding "secrets" into codebase and submit to repo).
Since I know how much you are into performance/benchmarking, you could have touch on that aspect of reloading Options with different strategies.
I already have a video on how to do this with secrets using Azure KeyVault and certificate authentication. The video focuses on simple configuration rather than secrets. Secrets can be managed using this same service (with the KMS integration and is mentioned in the video) but it was never the focal point of the video. Auth in AWS is way simpler than Azure. A service either has access to another service, through security policies, or it doesn't. When working in AWS you almost never have connections strings and secrets to access other services. You have VPCs, security groups and IAM roles.
@@nickchapsas thanks for your reply! ☺️ I assumed you would link and refer to related videos - should have checked your library I guess 😅
Azure does have identity based security (between services/resources) to avoid use of credentials as well. I think the official name is "Azure Managed Identity", but I might be wrong.. also not sure how AWS and Azure are different, but looks like it's working more or less the same way to me - I mainly focus on Azure myself though 😅 So I might be missing some of the great features of AWS ☺️
@@nickniebling It does but it also has connection strings which AWS doesn't. I have worked with both AWS and Azure at really high scale and there are things that I like in both areas. I think AWS has better services and a more clear security path but Azure has, in general, better SDK and documentation for .NET developers. Ultimately each provider gets inspired by each other. Choosing a cloud provider is 99.99% of the time a business decision and not a technical one.
If your using AWS ECS, there's another way of using AWS Parameter Store, without having to use that nuget package. You can add environment variable in the task definition and specify to get the value from Parameter Store. However you won't be able to refresh it's value at runtime
You can but I don’t recommend it. There is no encryption for secrets and you’d be splitting your configuration in two places
@@nickchapsas What I'm trying to say is that you can setup environment variables in the task definition for your container and their values can reference a secure string(encrypted using AWS KMS) from Parameter Store. As for splitting configuration in multiple places, I don't see it like that, you can use this approach if you have your environments in different AWS Accounts and you might have different configuration values per env, like connection strings. If I don't need to change configuration at runtime my personal choice will be to have the configuration in appsetting files and overwrite them from task definitions.
@@rogermurariu2448 Hello mate, is there any way I can contact you, I am trying to get my configuration in the way you just mentioned, I just need a way to store configuration inside appseting files, I set up everything else inside the task definition and parameter store.
Options pattern in ASP.NET Core Docs for anyone more interested:
docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-6.0
These options interfaces are really handy and I was not familiar with then. However, when using this approach together with SSM I think you run a risk of exhausting your SSM get parameter quota as you will check for updates to SSM on each request and the default quota for this API call is quite low. It's assumed by aws that developers only read from SSM on application start up. I'd be strongly inclined to create some kind of internal cache that checks for updates when a timer elapses if there's a need to update these settings without an application restart or redeploy. However, I manage SSM parameters from the cicd pipeline of the application so these restarts are automatically done if the parameters are changed from the pipeline.
On demand changes are fine but realistically, if you need to do this then restarting the app might not be an option. Let's say you noticed some weird behavior and you wanna get more into on the running app. You might change the minimum log level to debug. This can't be done in the way you described because you just lost that bad state. Realistically that TimeSpan would more more around the 5 minutes mark than a short one.
I'm actually running lambda so the state is gone anyway, but I allow for log level changes per event (and pass this change along the rest of the request chain) to achieve a similar goal.
My point was if you naively put the combination shown here into a production environment with high load and a high number of instances you will hit the quota of the parameter store. However, it seems AWS now allows this to be raised so it less of an issue than it once was.
@@thomaskmfdm Well actually the state might not be gone in lambda. Static members in lambdas are reused because lambdas aren't disposed after each execution. They stay in memory, warm, until some minutes of inactivity, so in this scenario, unless you are loading the whole lambda configuration per execution (which would be a performance problem) the config stays the same.
I literally implemented this last week - it's great :D
Great that you showed this will look into it some time I currently use an Consul KV to store my config s
Hi Nick,
Please release .net microservices course with Azure
This might be your only video, where you have explained things very intricately without worrying about the length of the video... Please have the same approach for all your videos
There is better approach using Steeltoe library and spring cloud config server. You can instantly change anything on demand using IOptionsSnapshot
Hi, Nick! I am from Greece as well. My greetings.
Great video, thanks! Awesome speed of explanation and all other needless stuff just got skipped, making every second of the video worthy!
Just wonder how grabbing settings from the cloud service hits performance. I guess if the app is running in the same cloud it shouldn't be a concern. But if the app is running on-premise? But sounds like a price to pay for the ability to change the config in a runtime.
What is the "official" way of writing back to appsettings.json from the code? I've seen people mentioning the need to implement custom JsonConfigurationProvider that would override .Set() method but no clear examples
Can we use Options pattern to inject non-config values too? like say a Customer class being injected with Options of Customer name, age etc... thnx... in general how can this be achieved with DI? Factory? What if a dependency needs a GUID each time it is instantiated?
We use AWS and hand-rolled Kubernetes in a private cloud, is there a System Manager UI in K8s?
Thank you Nick! Perfect as always 🍻
Thanks for the information, I was just wondering how will I change all those variables I stored in the app setting
I got a lot of parameters on my appsettings file, so I wanna ask you if is possible to use AppConfig, do you have any video about that? Thank you
Thank you for this video bro it is so helpful I'm searching for this these days
Is there a use case to prefer IOptions over IOptionsSnapshot ?
The centralization of config is why I've made my own service for running this on-prem. You can check it out on Github: poteb/ConfigurationService
But it's not just simple configuration, it uses json refs to compose a configuration from smaller parts that can be shared across multiple configs.
I still need to make a nuget package to load the config from the API and add to the application config.
I want to do the same but with the AppConfig? I was wondering have you done or you have any blogpost for it
Sounds nice for web app things. But on console apps (my domain) i used ini-files for configuration for the last 8 years and it worked flawless :)
Add your AWS CLI keys and you can use parameter store no problem for any type of app
Great summary, thanks!
How do you feel about taking IOptions as a dependancy for business logic/domain level objects? Should it be abstracted at presentation/infrastructure level or passed down?
If you only even wanna deal with a singleton object of options, then you can just register the item straight in DI. If you need it to be updated in runtime then snapshot or montor are better alternatives and in that case I would also use IOptions
Are the parameters fetched at startup or only when the IOptions or other variation is retrieved from the container?
On startup and then, if configured, every N seconds/minutes
Each time I want to make Likes for your videos I found myself already done it =)
What tool are you using to annotate the screen Nick? For example at 1:40 drawing the rectangles. I know there are many tools for doing this but there is always a better one around the corner :-) Thx & keep up the good work
It's called ZoomIt
A configuration change at runtime is a code change. This should require all unit and integration test to rerun. In my opinion configuration should never be changed at runtime and should require a redeploy. Very interesting video thanks for sharing :)
I completely disagree. If someone is so fundamentally different that makes you need to run your whole testing suite then that value shouldn't be configurable in the first place.. For example, if you notice an abnormal behavior in your app when running and you wanna capture more data you might update the minimum LogLevel to Debug to capture as much info as you need. That's not a code change and doesn't need to go through any pipeline. Same goes for how many consumer threads you might wanna have in a long running consumer and I can go on forever. I'm completely against that statement and I would be seriously worried about what's in those config files that would make someone think like that.
@@nickchapsas Fair enough.
@@nickchapsas Agree that log level changes are safe. When changing connection strings or anything that changes how the code operates - that's where I would want to have some sort of validation run on the new value. Typos and the like could cause big problems. But you are right, some of the config I have had to deal with in the past is a bit bloated :)
Good stuff bro, keep it up
Hi, cool solution. Do you know a on premise solution for local hosting?
Wow, great stuff. I've learned so much from you already.
in .net 8 is not taking me IConfiguraton by default? do you know how can i do to register it in entire applicacion?
Great stuff! We have been using IOptionsMonitor with Config server in PCF for a while now... same concept.
Yeah it can be used in so many ways. I was so surpised by how many people only know the IOptions one and don't know about monitor and snapshot
@@nickchapsas Agreed! That's why I try to get all of my fellow engineers to watch your videos! You're always putting out great content that is simple to do but can make your APIs so much better! Keep up the great work and thanks for all of the great content!
You mentioned that using IConfiguration is something that should be used regularly. With that in mind, how would you access configuration parameters during service registration/within ConfigureServices? It is my understand that you can't access the IOptions interfaces at that point, and only should be used after the app is buid. Is this correct?
You shouldn’t* use regularly. You should be using the Option interfaces shown instead
Nick, what do you advise for an on-premise param store, i was thinking hashicorp vault considering its dotnet library was solid, but this was way more seamless
I’ve actually never used an on prem parameter store. I’ve only ever used AWS Param Store, AWS Secrets Manager, Asure app configuration and Azure key vault. I’ve only ever worked with cloud so on prem was something I’ve never done
Cool. Didn’t know they had this and we home rolled a similar method.
If you were deploying this, I’m assuming you need to set up that config options class to feed it AWS credentials… or is the lib smart enough (and permitted to) to somehow use the region and credentials for where your app is deployed?
It can assuming you have the right IAM Role in place, but I would go with an explicit region based on where I deployed the app
@@nickchapsas yup agreed. Cool regardless. Love the infra vids 💫
I made something like this for myself but the settings could only be changed programmatically.
I will expand it to support from external sources.
Are these covered in dept in you courses?
Very useful stuff! Thank you Nick.
Extremely useful stuff. Thanks a ton!
As always qucik and catchy.
Quite useful. Thank you!
Nicely explained
Thanks.
Can you please make a video on expression trees?
Thanks for the video! Any plans for Func and Action video?
It's currently scheduled for the 7th of March but I keep pushing it back because other videos are being prioritized
What tools do you mean in 8:22?
Well explained. Big plus for explaining how IOptionsMonitor and IOptionsSnapshot works because not much people knows how to use them. Do you have way to update on the fly options that are used in Startup.cs eg. CORS settings?
how is Parameter store different from AWS AppConfig ?
Great content thanks!
Perfect demo 👏
Please notice that you can also edit the appsettings.json file itself at runtime and by default (reloadOnChange: true) you can propagate the changes with the same interfaces described here.
See: docs.microsoft.com/en-us/aspnet/core/fundamentals/change-tokens#monitor-for-configuration-changes
Yeah but you can't change the json files of deployed applications in containers. (I mean you technically could figure a way out, but you shouldn't)
@@nickchapsas yeah totally agree. In my day to day job there's zero chance I'm able to do it in prod, luckilly.
Fantastic again!
Why don't you use your own configuration DB, such as SQLite DB, and sync configuration in DB with default configuration from appsettings.json? In that sense, the default configuration will always keep unchanged for any particular stage of the application in production.
Why would you write your own thing when there is a high available free service that you can use?
Always excellent content here! I have been using IOptionsMonitor for a little bit, but I like this concept from AWS too. Offers a central hub for managing multiple api's or console apps.
You can also do something similar using the json files and the reload on change option.
Yeah but you can't change the json files of deployed applications in containers. (I mean you technically could figure a way out, but you shouldn't)
@nickchapsas Hi Nick. You mention in your AWS videos that you've authenticated your machine against AWS. Would you consider doing a video on how you do that, or could you point me in the right direction as I've not had much luck in my searches about it? Thanks.
Can you make some videos about Orleans?
So with IOptionsMontor and IOptionsSnapshot, would these update at runtime if the appsettings file is updated? Or if the ASPNETCORE_ENVIRONMENT system parameter is changed?
This depends on how the configuration provider is implemented. The AWS SDK team has explicitly added the updating mechanism in their provider
runtime
@@nickchapsas this also depends on how the provider is added to the pipeline, since they all (I think all?) have a property for reload on change, which can be enabled or disabled.
Then the question is if the provider actually honors them.
heard about azure app configuration? its even easier and comes with integrated features toggle loading dynamic
So does AWS AppConfig. I specifically wanted to showacse Parameter Store to focus both on the service but also on the IOptions stuff and the Configuration Provider.
this is great I already use it, but can you make a video regarding appConfig + feature management in AWS
I sure can :)
I wonder how this works in a multi tenant scenario (so hundreds of isolated databases, same schema but different contents , and only one web application). Then based on the login the system will have to provide a connection string and all other needed options from a provider e.g. a EF configuration provider or in your case an AWS configuration provider. So probably ... this will then become part of the claims in the token for such a user. (havent tried it but just thinking about this while viewing the video). Can't judge if this then each time passes the builder (which then has a dependency on the request, so auth must already have happnened while builder "adds" that later). (assuming all distributed caching includes the tentantid in the cache key) (and assuming EF has no unknown specific stuff). Ms Refers to Orchard but dont know if that is generalizable useable.
You'd most likely have to add the tenant id as part of the config path and load it dynamically.
You didnt push the code yet :) And nice video, I wanted to use doppler for this, but maybe I will switch to amazons solution :)
Ah damn you're right. I will push it after work today. Sorry for that.
.NET really has a thing for everything... here I was writing a configuration system manually
Hi sir thanks for making wonderful tutorials. Could you make a tutorials on how to for ASP.NET Identity Roles? Thanks
Thank you!, in my case I use aws secret manager ...
Is there azure counterpart to aws system manager with similar package?
I am not sure but I guess key vault is the one.
Azure app configuration :) you add it as a config source in your program builder.
@@Potato-m1l Thanks for info!
Its not that nice at all. When you create PR you will not see config changes needed for your code. Now you need to come up with process to manage it. What will prevent you from deploying code without adding settings first?
Everything fine, but today we can not do slash in name. It has to be like ConnectionString in name and thats all.
This does not work on maui
In lack of a better word, you made a mistake in the video.
You show the Value/CurrentValue from the snapshot/monitor being stored as a field.
It is recommended storing the IOptions "variant".
Reason being that you can accidentally store settings in a e.g. singleton that then does not get updated when a setting change.
You probably know this. But a new developer might copy your implementation in places where it would cause a bug.
I am not expecting anyone to store the value as a field since the only reason to have the options object registered is to inject it as a whole. Storing each value would defeat the purpose. I have to assume a lot when I make these videos, so here I assume that people understand how Dependency Injection works. If they don't, then they'll figure it out one way or another.
@@nickchapsas I understand. But perhaps you could mention when doing the opposite of the general recommendation, for the sake of making an example.
Oh, and congratulations on the sponsorship. I know nothing about aws, so I'm excited to see your videos that show aws feature :-)
Colon!!! :)
Whenever he starts advertising the channel, I can't understand one iota. 😅
It's a miracle I've made it this far with the same ad bit
@@nickchapsas irony aside, yes it is. Also, remember to subscribe to the hit da' notification bell and smash the sagamale^#^#£€÷7 button. 🥴 hic!
bellissimo
+1😀
👍🏽
You were supposed to fight evil not join it!
Where are Azure guides? :)
Ask the Azure marketing department 😂I've been working with AWS at very high scale for the past 3 years. I think i can offer more value with AWS advice and the AWS marketing team was kind enough to sponsor some content so two birds with one stone.
What a horrible idea to inject IConfiguration into a controller.
You obviously shouldn't be doing that. It's there to help showcase the IOptions interfaces
Why it's bad to inject IConfiguration in controller?.. help me to understand
@@dhineshkumar.m Because it gives you access to everything about the app's configuraiton. You should narrow it down to only the things that conern the Controller
@@dhineshkumar.m You want to keep your controllers clean and free of any logic.
You would have services for that, even though, lately and with the large adoption of the Mediator pattern, The only service you would inject into a controller would be the Mediator, Nothing else.
Google for "Thin controllers" to learn more.
@@rafaelherscovici6438 Thank you 👍