Intro To CosmosDB - How To Easily Use Cloud NoSQL with C#

Getting started with a NoSQL database in the cloud can be intimidating, but it doesn't have to be. CosmosDB is a powerful NoSQL database system that can be globally scaled with very little effort. Best of all, CosmosDB scales with you, meaning it can be inexpensive or even free to start while giving you the ability to grow over time.
In this video, we are going to look at how to set up a free instance of CosmosDB. Then, we will connect a C# application to our new database, learning how to perform inserts, updates, deletes and read operations. This will allow you to quickly get started in this specific database type in your application.
Full Training Courses: IAmTimCorey.com
Source Code: leadmagnets.app/?Resource=Int...

[@mashwill85]

Video came at the right time just when I wanted to start learning Cosmos DB. Thanks Tim

[@IAmTimCorey]

Great!

[@andergarcia1115]

Thank you Master, it's good to start seeing things that are more at a business level. Insightful explanation as always

[@IAmTimCorey]

You are welcome.

[@egcoolmauricio]

Nice video, I always get updated with yours tutorial, thank u so much. Regards from Argentina

[@IAmTimCorey]

You are welcome.

[@toyokenstudio]

Thank you! Great tutorial! 👏🏼

[@IAmTimCorey]

You are welcome.

[@mohammadanas4377]

Was eagerly waiting for it

[@IAmTimCorey]

Great!

[@FARES-dd6ln]

Muchas gracias, funciona perfectamente, te has ganado el like, la suscripción y todo XD

[@IAmTimCorey]

You are welcome.

[@dracocendrillion9963]

Yes amazing 👏

[@IAmTimCorey]

Thanks!

[@korsbar1978]

You're very good.

[@IAmTimCorey]

Thank you!

[@DavidMartin-vs1dm]

Tim, which is cheaper for hosted DB, Azure Cosmos or Atlas MongoDB?

[@IAmTimCorey]

Good question, but a complicated answer. On the surface, MongoDB Atlas is a lot cheaper. However, it does depend on your usage and how you buy your credits. For instance, you could purchase up to three years of expected usage for a major discount (I believe up to 40% off). That's great for companies with consistent workloads. You also might be able to use Serverless for CosmosDB, which will be cheaper. Finally, you might already be using Azure for other things, so the connectivity, security cross-over, etc. might be a huge benefit. In the end, you should evaluate your specific project in order to determine which will be more affordable in both the short-term and the long-term. Don't forget to include backups, availability, reliability, and scalability as part of your evaluation.

[@msulemantube]

I have converted your entire KZbin channel into an AI question-answer chatbot. Additionally, translations are available in English, Urdu, French, German and Italian languages. please let me know I will share the link.

[@IAmTimCorey]

I appreciate the idea, but that's not something I'm interested in doing at this time. It will sound good, and it might even produce some decent answers, but it will also give bad answers. Also, the outcome of an AI is typically to pull traffic away from the creator. The AI provides answers instead of telling the viewer where to look, which in turn reduces views on the original content. That's a real danger for creators.

[@msulemantube]

@@IAmTimCorey I understand your concerns, and I appreciate your honesty. We can train the model according to the content to ensure better accuracy. AI is already taking over, and if we don't adapt our way of thinking and learning, we risk becoming obsolete. Additionally, being dependent on one platform is not very viable for the long term. If you change your mind in the future or have any other ideas on how we can collaborate, please feel free to reach out. Thank you for your time and consideration.

[@MrDexterAlan]

Serverless should be use only for deweloper purpose becouse have limited throghput. A serverless container can store a maximum of 1 TB of data and indexes. A serverless container offers a maximum throughput that ranges from 5,000 RU/s to 20,000 RU/s.

[@IAmTimCorey]

I fully disagree. Yes, serverless isn't for all situations. That's a given. However, it is absolutely for use with production apps. This is a small example, but my Suggestion Site app uses MongoDB Atlas (similar to CosmosDB). The total storage used for the production application is less than 2MB. Granted, it is a small app, but that's the point. Production apps don't need to be enterprise level massive. But even my site, with over a thousand users and almost a thousand suggestions (some have been archived - we have over 800 active) is a decent production app. Now scale that up to where it would run out of room on serverless CosmosDB. Based upon storage size, I would need over 500,000 suggestions and about 750,000 users. And that would be if we decided to keep all of that information on the production server rather than archiving it. If we base it upon RU/s, we would need even more, since I use caching to reduce my calls down to a tiny fraction of what I would otherwise need. So now let's think about how many apps are comfortably within those bounds. Not every application will need hundreds of thousands of users or entries. There are LOTS of apps that support systems. Apps for small to medium-sized businesses. Apps for services. Websites that need a place to store data. And those are just a few of the hundreds of applications that I've seen personally that could use serverless CosmosDB. It isn't for every situation, but too often I see people plan for enterprise-level applications before they have their first user. That makes for poor design as well. You need to be realistic in your planning. CosmosDB is actually rather easy to change from serverless to standard.

[@MrDexterAlan]

It is better to use to store Connecting string Azure key vault.

[@IAmTimCorey]

Better than what? Appsettings? If you set up your configuration to use Key Vault as well, it will override Appsettings. For me, I used secrets because that's where you should put it for local development. As for Key Vault being "better", there are other options that you should consider. For instance, if you were to deploy your web application to Azure, you could use the environment variables in Azure to ensure that your developers never had access to the secrets while securely providing them to your production application (and other versions as well). It is simpler than Key Vault, less to maintain, and closer to the actual item using it. Both have their place. Just don't get caught up in one solution always being right. In this particular demo, we used a Console app. In that case, there is no secure place to store the connection information, so appsettings is fine. If you used Key Vault, you might actually expose additional secrets, depending on how you access Key Vault. Regardless of how you access a secret on a desktop application like a Console app, the Console app has to see the clear-text version and has to transmit that clear-text version (over SSL). That means that if you have access to the machine that is running the desktop app, you have access to the secret in clear text.

[@karthiks4347]

Tim! Did you just say free SQL? I think it is time limited right?

[@IAmTimCorey]

Azure provides one free SQL database and one CosmosDB database. Both are free for life. You only get one each and there are size restrictions.

[@rodrigo6459]

Okay... so when trying to use System.Text.Json.Serialization instead of Newtonsoft.Json for decorating the ID does not work! kinda ridiculous!... so if you want to use System.Text.Json.Serialization you have to create a WHOLE new class which will inherit from CosmosSerializer!

[@IAmTimCorey]

In order to support both, they would have needed to put both packages in the serializer. That would have added to the dependencies. They had to choose one.