4 minutes to read read
Around four years ago when .Net Core was in its early stages, I wrote back a Configuration provider for .net core 1.x. This has been a long time. The package did picked up very well and there were multiple downloads and a few queries as well. Many people would never know that .net core started with json project files. But since then a lot changed and my package went obsolete.
A few days back got some time and bandwidth and wised to revise the package. This would not only update the latest package but would also help me understand what changes have been done as in framework as a whole. So, my fellow countrymen let me present you the MongoDbConfiguration Provider for .net Core (😁) /s
Read on further to get the details as I explain the “simple” steps to write a custom configuration provider for .net core 3.1.
5 minutes to read read
In the modern everything is evolving very rapidly, and so is Web and standards. From SOAP to REST, standards have been shifting, but they seemed to have been stuck for a while while with the REST. Well, now again the ball is getting rolling with gRPC, the latest kid in the town. Not only it has all the latest and cool gadgets in its pocket, it is fast, really fast secure and can solve some of the typical problems that have been with since ailing the normal REST communications.
But.. There is always a but.. But, there are always two side of coin with all flexibility, there are some challenges. This is first part of the 3 article series on gRPC, what – why and how series including the handon demo. So without wasting time, lets dive in. This is a bit theoretical shit. For quick codies, you can jump to implementation in next article.
5 minutes to read read
With the advent of .Net Core, web Api have become more common. Apologies to my non-dotnet background friends, but with .net hands-on, its always inclined towards .net. Coming straight to the point, be it Mobile Apps, SPAs (Single Page Applications), micro-services or name whatever, you will see REST everywhere. In background of this post, old kishore kumar songs are running, so don’t offend a bit of nostalgia 😊.
But as in most cases, everyone is so busy in implementing the APIs, many of my friends don’t ever pay attention on how an API be named. Or rather, not an API but the endpoints and methods (hate to call them methods). Well, for an API the problem there is no standard as such, but rather some best practices, that should be followed ‘ideally’. Lets discuss them one by one. Most importantly, in this post shall be talking only on the API naming. I also had OpenApi in mind, but lets leave it for another post. So lets dive in.
6 minutes to read read
Async Await is one of the best feature that has changed a lot of dynamics in the recent past, but it has created same amount confusion and chaos. Lot of bad practices, wrong usage has plagued the very usage. I have refactored a very huge WPF code with lots of out ref and reference based codebase to new pattern, on covering ~80% of it, faced a few challenges reverted back. Then after a month took the task again and completed migration.
I do receive a lot of issues in PRs around this. Based on this feeling that there would be many others who are facing such isssue, this post is more targetted from experiences. There could be log of posts and videos and shit load of resources, but I would try to write it concisely and in simple language/. Again, comments are open for discussion.