Milan Jovanović's Linkedin Analytics

I failed an interview because I didn't know how locks work in C#. Read this to make sure it never happens to you. Locking allows us to control how many threads can access some piece of code. Why do you need this? Because you want to: 1. Protect access to expensive resources 2. You need concurrency control I rarely work with low-level code. But the company I was interviewing for does. Of course, they'd have this in the interview process. Here's the situation: - I knew I needed a locking mechanism - But the method was async (oof!) - So I tried to solve this using the `lock` statement And that's where it all went to shit... The `lock` statement doesn't work with async-await. And it makes sense. You can't guarantee which thread will complete the method. So what's the solution? You need to use an asynchronous synchronization primitive Luckily, C # has many to choose from. Semaphore, SemaphoreSlim, Mutex, Monitor, etc. Two important remarks: 1) Use a timeout when waiting on the semaphore 2) Always release the lock with a try-finally Here's a tough question for you. How would you implement a lock in a database? If you want to find the answer, go here: https://lnkd.in/eYPhrcZs Would you have nailed this interview?

I like my API endpoints "thin" - something you can achieve with MediatR. Here's why you should implement this. The API endpoint's only responsibility becomes: 1. Accepting a request 2. Constructing a command/query object 3. Sending it using MediatR and getting a result The best part? You don't need MediatR. With it going commercial, I'm sure many people will switch away. I implemented my custom solution with a few lines of code. Here's how: https://lnkd.in/e-GVRPhN What do you think about this approach?

The riskiest line of code you'll write today is the one without a feature flag. Fortunately, .NET has you covered right out of the box. Feature flags are a software development technique that allows you to wrap application features in a conditional statement. You can then toggle the feature on or off at runtime to control which features are enabled. .NET already has feature flag support built in. You can use the IFeatureManager in your code to check whether a feature is enabled. Want to learn more about using feature flags? Check out this article: https://lnkd.in/eaDHTXGV

I replaced my Redis cache with Postgres. Here's what happened... You can do pretty much anything with Postgres. I'll show you how to turn Postgres into an efficient key-value store. Turns out, it can be pretty damn fast: https://lnkd.in/eu8ZnvU4

Are you manually creating an HttpClient? Here's why this is a problem. 1. Configuring the base URL 2. Adding required headers I know a better way. Using IHttpClientFactory solves most of these issues. The "trick" is using a named or typed client. Configure the default values once, when defining the client. Find out more in my HttpClient article: https://lnkd.in/ewvQYJDW

.NET + Sentry = awesome app monitoring But how do you get started? In my new video, you'll learn: - Configure Sentry in .NET - Distributed tracing in microservices - Debug N+1 problems and fix them - Investigate exceptions across services - Use telemetry data to validate fixes in production Click here to learn more: https://lnkd.in/ebsGdFPb

Why aren't you using Central Package Management in .NET? I remember the days when managing NuGet packages across multiple projects was a pain! You know what I mean. You open a large solution and find out every project uses a different version of the same package. Not fun! Think of CPM as a control center for all your package versions. Instead of setting versions in each project, you set them once in one place. Then, you just reference a package you want to use without specifying the version. It's that simple. Click here to learn more about CPM: https://lnkd.in/exAf_46K

What is gRPC and when should you use it? gRPC is a high-performance remote procedure call framework developed by Google. Its primary use case is service-to-service communication. That's why you will often see it used with microservices. RPC stands for Remote Procedure Call. RPCs are a way to execute code on another server, like a local method call. They are a great way to implement communication in distributed systems. gRPC stands out with Protocol Buffers for the interface definition language (IDL). It allows gRPC to have strong typing and code generation support. Protobuf is an efficient method for serializing structured data. It's a binary format and can be 𝟱𝘅 𝗳𝗮𝘀𝘁𝗲𝗿 𝘁𝗵𝗮𝗻 𝗝𝗦𝗢𝗡. Additionally, gRPC uses HTTP/2 for improved network efficiency and real-time communication. You define the services that expose RPC calls and the message contracts inside a `.proto` file. Then, you can generate the gRPC client and server code. .NET supports building gRPC services, and they can use the built-in: - Logging - Dependency injection (DI) - Authentication and authorization By now, you should have an idea of what gRPC is. But where should you use it? The ideal use cases for gRPC are microservices, streaming, and IoT. Each microservice can use a different programming language. gRPC is language-agnostic, so it's a good fit for these scenarios. However, you could also use REST to implement this. What's the difference between REST and gRPC? The key difference is the data format. REST uses JSON (or XML). gRPC uses Protobuf. Both use HTTP, but gRPC requires HTTP/2 for the streaming operations. REST is more popular, and it's perfect for public APIs. gRPC is highly efficient for distributed server-to-server communication. Have you ever built a gRPC service before? --- Do you want to simplify your development process? Grab my free Clean Architecture template here: dub.sh/caw16

Everyone gets this wrong about Clean Architecture. I see the same mistake happen over and over again. Developers discover Clean Architecture. They get excited about its principles. And then... they turn the famous CA diagram into a project structure. But here's the thing: 𝗖𝗹𝗲𝗮𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗶𝘀 𝗻𝗼𝘁 𝗮𝗯𝗼𝘂𝘁 𝗳𝗼𝗹𝗱𝗲𝗿𝘀. It's about dependencies. Simon Brown wrote a "missing chapter" for Uncle Bob's Clean Architecture book that addresses exactly this issue. Yet somehow, this crucial message got lost along the way. 1. You can get the benefits of Clean Architecture without layers 2. As long as you respect the direction of dependencies Here are 2 better ways to structure your Clean Architecture applications: https://lnkd.in/e2xwKJgn

Find security risks at build time? Here's how you can implement this in .NET. Imagine being able to find security risks when you build your code. You can do this with static code analysis. Here's an example build error that warns me my password hashing code is insecure. 👇 Static code analysis can help you write secure and consistent code. And you can also enforce this at build, even in CI pipelines. If you want to see how to set this up from scratch, check out this article: https://lnkd.in/eyytSx8a --- Simplify your development process with my free Clean Architecture template. Download it here: https://dub.sh/caw15

Did you hear about EF Core interceptors? They let you intercept queries at different points in the lifecycle. I use EF interceptors to extend my query with custom behavior. Here are 3 examples: - Audit logging - Publishing domain events - Storing outbox messages Want to learn more about EF interceptors? Start here: https://lnkd.in/euGKh9Tf Do you use EF Core interceptors?

Your software architecture needs testing. Yes, you read that right. Architecture tests help you enforce your software design rules. Here are some design rules that you can enforce: - Services must be internal - Entities and Value objects must be sealed - Controllers can't depend on repositories directly - Command (or query) handlers must follow a naming convention You can learn more about Architecture Testing here: https://lnkd.in/eUzvdCeZ

I rewrote a 40-year-old APL system to a modern tech stack. It powers a $10M manufacturing business with 460+ database tables. Here are 5 lessons I learned in 4 years: 1. Start with core business logic first 2. Modular architecture is worth the investment 3. Data sync is harder than you think 4. Balance technical needs with business pressure 5. Document institutional knowledge before it's gone Want the full story of our legacy migration journey? Check out my blog post: https://lnkd.in/e9hb4mt2

Are you still juggling multiple tools for your API development workflow? I've been there - switching between design tools, testing platforms, and documentation systems. But there's a better way. Let me introduce you to Apidog. I've been testing Apidog for the past few weeks, and it's transformed my API development process. What makes Apidog different is how it unifies the entire API lifecycle in one interface: - Design REST, GraphQL, WebSocket, and SOAP APIs with a visual editor - Auto-generate beautiful, interactive documentation that stays in sync - Create mock servers with zero configuration (realistic test data instantly) - Build and run comprehensive API tests without complex scripting - Collaborate seamlessly with your entire team in real-time The biggest game-changer for me is how Apidog eliminates context switching. No more exporting from one tool to another or manually keeping documentation updated. The branching feature has been crucial for our parallel development workflows. I can create an API branch, test changes, and merge without disrupting others. Apidog even handles Postman scripts natively, so migration is painless. And possibly the best part? The free tier is genuinely useful - not just a demo. Start simplifying your API workflow today: https://lnkd.in/evGgKNBy What API development pain points would you like to eliminate?

Building distributed systems is hard. But Dapr makes it a lot simpler. Dapr (Distributed Application Runtime) is an open-source project that handles the complex infrastructure challenges so you can focus on what matters most: your application's business logic. Dapr helps you by: 1. Abstracting away infrastructure-specific code behind consistent APIs 2. Providing standardized building blocks for common distributed system patterns 3. Enabling you to use the same code from local development to production 4. Integrating seamlessly with .NET and ASP .NET Core applications Want to learn more? Here's how you can get started: https://lnkd.in/exkCNftG Did you ever use Dapr to build an application? --- Do you want to simplify your development process? Grab my free Clean Architecture template here: dub.sh/caw16

How does RabbitMQ really work? I used the official RabbitMQ .NET client library. And let me tell you, it's not a small amount of code. You have to define a queue, configure a consumer, etc. Here's the full story: https://lnkd.in/e_iHv_JN Goes to show how powerful messaging libraries are.

Looking for MediatR alternatives? I recommend taking a look at Channels in .NET. You can implement a simple in-memory message queue using Channels in .NET. Channels implement the producer-consumer pattern. Producers asynchronously produce data, and consumers asynchronously consume that data. A channel has a Writer and Reader, that you can use to publish and consume messages. Here's how you can use this implement a simple message bus: https://lnkd.in/enC-Nnze Remember that this is still an in-memory bus, so it's not reliable. --- Do you want to simplify your development process? Grab my free Clean Architecture template here: dub.sh/caw16

5 books I can't recommend enough: 1. Clean Architecture (Robert Martin) 2. Building Microservices (Sam Newman) 3. Unit Testing Principles, Practices, and Patterns (Vladimir Khorikov) 4. Domain Driven Design (Eric Evans) 5. Entity Framework Core in Action (Jon Smith) My favorite: Building Microservices. What should I read next? --- Simplify your development process with my free Clean Architecture template. Download it here: dub.sh/caw16

5 EF Core features you need to know 🦄🔥 1. Query splitting - Splits JOINs into multiple queries - Could improve query performance 2. Bulk updates - Uses ExecuteUpdate to update many entities - Directly goes to DB, isn't part of a unit of work 3. Raw SQL queries - Load entities from DB using raw SQL - Allows you to use SQL features 4. Bulk deletes - Uses ExecuteUpdate to delete many entities - Directly goes to DB, isn't part of the unit of work 5. Ignoring query filters - Query filter allows you to automatically filter LINQ queries - Ignoring the query filter can be useful sometimes 𝗕𝗼𝗻𝘂𝘀 - Here are five more EF Core features you should know: https://lnkd.in/eijGi98W What is your favorite thing about EF Core?

I migrated from Docker Compose to .NET Aspire. Here's what I learned. I've been using .NET Aspire a lot lately. But what is Aspire? It's Microsoft's new cloud-native development tool. ".NET Aspire is an opinionated, cloud-ready stack for building observable, production-ready, distributed applications." It solves many things for you out of the box: - Orchestration - Service discovery - Health checks, reliability - Tracing, OpenTelemetry I often use Docker Compose to configure my applications for localhost. It's a simple setup. But you need to manage environment variables and connection strings. If you're unfamiliar with Docker, it can be tricky sometimes. Aspire promises to simplify this whole setup. So, I migrated this application to .NET Aspire and documented the process. Here's the complete breakdown (+source code): https://lnkd.in/de-jGv2x What do you think about Aspire?