Milan Jovanović's Linkedin Analytics

A single exposed API key or database password can compromise your entire infrastructure. Yet many developers still store sensitive data with basic encoding or weak encryption. Properly implemented encryption is your last line of defense. When other security measures fail, it ensures stolen data remains unreadable. This is especially crucial for API keys, database credentials, and user secrets that grant direct access to your systems. .NET has built-in support for cryptography and the AES algorithm. AES is a symmetric encryption algorithm. Here's how you can use it to encrypt sensitive data: https://lnkd.in/ewBxdj72

I made one small change for a 400x performance improvement. I was implementing cursor pagination with EF and Postgres. But I need to make the query faster. How do you make an SQL query faster? Add an index, and you're good to go. Right? Not quite... I created a composite index on the required columns to speed up the query. BUT THIS MADE THE QUERY SLOWER!!! This led me down a rabbit hole to figure out why the index wasn't used. I knew about tuple comparison from before, and this solved the problem. But I didn't know how to translate this into an EF Core query. Luckily, the Postgres provider supports this with a custom function. Here's everything you should know: https://lnkd.in/eEv65JeU

What is Dapr? Dapr is a portable, event-driven runtime that simplifies building microservices. At its core, Dapr provides standardized building blocks that abstract away the complexity of common microservice patterns. Rather than wrestling with infrastructure-specific code, you can focus on your business logic while Dapr handles the rest. Dapr uses the sidecar architectural pattern, where it runs as a separate process alongside your application. Your application communicates with the Dapr sidecar through HTTP or gRPC, and Dapr handles communication with infrastructure services. Want to learn more about Dapr? I wrote a getting started guide for .NET developers. Find it here: https://lnkd.in/ecwhTHUw

Architecture testing can help you control technical debt. Technical debt is the consequence of prioritizing development speed over well-designed code. With architecture testing, you can control: - Direction of dependencies - Naming conventions - Various design rules Curious to learn more? I wrote this in-depth guide that I think you'll enjoy: https://lnkd.in/dE5YMq_n

Your web applications need to serve increasing numbers of users and handle surges in traffic. When a single server reaches its limits: - Performance degrades - Leading to slow response times - Or even complete downtime The solution? Just add more web apps and load balancing. Load balancing between multiple API servers improves the scalability of your system. Here's how you can introduce a load balancer in .NET: https://lnkd.in/eTiT4fNR

I run my integration tests inside the CI/CD pipeline. This gives me maximum confidence in my code. It's all thanks to Testcontainers and Docker. You can run external services as containers and access them in the tests. Here's how to spin up: - PostgreSQL - Keycloak - Redis And now you can connect to these services from your application code. Ready to take your integration testing in .NET to the next level? You will love this article: https://lnkd.in/dJQMrSnV

Did you check out the new IExceptionHandler in .NET? It's a simplified way to handle exceptions globally. IExceptionHandler is part of the built-in exception handling middleware. You can handle all exceptions or a specific exception. Which also means you can chain handlers. Want to learn more? Here's an in-depth article: https://lnkd.in/emipsCZq

What does your CI pipeline look like? Here's a simple GitHub Action for building and testing your .NET application. This is an easy way to get instant feedback when something breaks in your application (assuming you have tests in place). You can steal the source code for the CI pipeline from my article. Check it out here: https://lnkd.in/ekuCRW54

Multiple EF Core DbContexts in a single application? Here's when it makes sense to do this: - Working with multiple databases - Separating concerns - Modular monolith - Read replicas I did this when implementing a modular monolith application. Each module had a dedicated schema in the database and a separate DbContext in the code. The surprising part? How EF Core deals with database migrations and different schemas. Here's a breakdown of how I solved this: https://lnkd.in/eK8p-azY

How do you draw architectural diagrams? The most popular option is UML diagrams. However, there's also the C4 model. C4 stands for: - (System) Context Diagram - Container Diagram - Component Diagram - Code Diagram It's a lightweight model to describe your architecture. Want to learn more about the C4 model? Check out this article: https://lnkd.in/ezQ8EBUa

Why should you use Clean Architecture? Or Hexagonal architecture or Onion architecture... All three of these architectures follow similar ideas: - The direction of dependencies is toward the center - The core contains the domain entities and business rules - The core should be independent of any external concerns What do we get from this? The two qualities I want to highlight are: - Stability - Testability Our business rules and domain entities are in the center and don't depend on anything. This makes them stable because the things around them can change, but it won't affect the business rules. The second quality is testability. Because our business rules depend on abstractions, they are easy to test. We can provide a mock implementation of the abstraction and use it for testing. Of course, I still do integration testing with a real database. So, the essence here is decoupling the business rules from the framework and infrastructure-specific code. Once you understand these ideas, you don't need a fancy name for the architecture. Another thing you should consider is cohesion. Here's why cohesion is important: https://lnkd.in/eKpTW-Kq What do you think about domain-centric architectures?

How did we make a simple idea so complicated? CQRS is the simplest pattern out there. CQRS separates the writes and reads in the application. This separation can be logical OR physical. CQRS has many benefits: - Complexity management - Improved performance - Scalability - Flexibility - Security My preferred approach is starting with logical CQRS. One database + separate flows for writes and reads. You can design a data model fine-tuned for each operation. A lot of developers stay away from CQRS out of fear of complexity. They think you need MediatR to implement CQRS. This isn't true. Here's why: https://lnkd.in/eFMnSNsX What do you think about the CQRS pattern?

Do you know all 3 ways to define Middleware in ASP .NET Core? Middleware allows you to introduce additional logic before or after executing an HTTP request. Middleware is an excellent choice for solving cross-cutting concerns in your application. You are already using many of the built-in middleware available in the framework. I'm going to show you three approaches to define custom middleware: - Request Delegates - Convention based - Factory based Here's everything you need to know: https://lnkd.in/ezupCfNb How do you prefer to define middleware in .NET?

Why do we need background tasks in .NET? Background tasks can offload some work in your application to the "background" outside the normal application flow. The work completes asynchronously in the background, and you can notify the user if it's needed. Here are a few examples of background tasks: - Publishing email notifications - Running a post-install step - Generating reports - Updating a cache - Image processing A robust library for scheduling recurring background jobs is Quartz. Here's everything you need to know: https://lnkd.in/eG2djyDB

Did you hear that Heroku now officially supports .NET? I've been building .NET apps for years, but deployment was always a pain. Today's post is sponsored by Heroku to help you simplify your .NET deployments. No more searching for Dockerfiles or community buildpacks. Now I can deploy any .NET 8+ app with just "git push heroku main" - it's that simple. Setup takes minutes, not days. What I love about running .NET on Heroku: - No server config headaches - Automated patching and updates - Simple, low ceremony deployment - Automatic scaling when traffic spikes - Enterprise-level security and governance The Heroku add-ons ecosystem is perfect for .NET devs. I connected: - Heroku Postgres for my data store - Redis for distributed caching - RabbitMQ for messaging All with just a few clicks - no complicated setup. You can also integrate services written in other languages (Java, Go) with Heroku. My team spends way less time on DevOps now. We can focus on providing business value instead of worrying about infrastructure. For complex apps, you just need a simple Procfile to tell Heroku how to start things up. Try Heroku for your .NET projects: https://fnf.dev/3F8hUxW What will you build first?

Do you want to learn Clean Architecture and DDD? I prepared 33 lessons for you 🔥 𝗖𝗹𝗲𝗮𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗙𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹𝘀 - Project setup - https://lnkd.in/dqZeKdvU - Minimal APIs - https://lnkd.in/eKsvdyeQ - Dependency injection - https://lnkd.in/e7KK27d9 - CA + Document database - https://lnkd.in/eEywJHFS - Project setup from scratch - https://lnkd.in/dvAVHzzg - 4 Best practices for new project - https://lnkd.in/dPfxPfuY - Structured logging - https://lnkd.in/dRT4EGvr - Message queues - https://lnkd.in/dvSsgAyn 𝗗𝗼𝗺𝗮𝗶𝗻-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝘀𝗶𝗴𝗻 𝗜𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 - Rich Domain model - https://lnkd.in/drbTK9_W - Entities - https://lnkd.in/dQzuqzR6 - Value objects - https://lnkd.in/d4iWcybq - Aggregate root - https://lnkd.in/dxb6dx-y - Domain validation - https://lnkd.in/dZMjb5_v - Domain model tradeoffs - https://lnkd.in/d2_9fBSv - Repository pattern - https://lnkd.in/dq-mst-P - Specification pattern - https://lnkd.in/enP-8n9i - Unit of work - https://lnkd.in/e668P6wK - Smart Enums - https://lnkd.in/efq34FS7 - Snapshot pattern - https://lnkd.in/eubBfFk4 - Strongly typed IDs - https://lnkd.in/dpgZ4gBw - Anemic Domain model - https://lnkd.in/dmrGQTY9 - DDD modeling - https://lnkd.in/dnvgNgfg - DDD + EF mapping - https://lnkd.in/dmSXbxqt - Incomplete aggregates - https://lnkd.in/dBDQhRNQ - Double dispatch - https://lnkd.in/dK4jQT7g 𝗖𝗤𝗥𝗦 - CQRS Fundamentals - https://lnkd.in/dKYS87-6 - Validation /w Result - https://lnkd.in/dZuc-6MM - Validation /w Exception - https://lnkd.in/dqh9ZcAD - Read models - https://lnkd.in/dD5W3FDn - UoW pipeline - https://lnkd.in/dzwg6Uad - The "Truth" on CQRS - https://lnkd.in/dbpFQ-2f - CQRS Query side - https://lnkd.in/dKfXaeNx - Materialized views - https://lnkd.in/dmfjhMKR Hope this is helpful! If you liked this, you should join The .NET Weekly - my newsletter with 64,000+ engineers. Join here → https://lnkd.in/eiwSHUqs Have an awesome day!

What are the best practices for API error handling? I always start with this - API errors need to be presented in a consistent way. - Provide a clear and consistent structure for your error response - Implement logging and monitoring - Use descriptive error messages - Document common errors - Don’t leak sensitive data Wouldn’t it be great to have a standard for returning API errors? Surprise - there is! It’s called Problem Details. You can learn more about API error handling best practices here: https://lnkd.in/dZEqWX98

How do you add Health Checks in .NET? - AddHealthChecks - introduces the required services - MapHealthChecks - exposes a health check endpoint The next thing you need to do is introduce health checks. There are many HC libraries for popular databases, message brokers, etc. If you want a complete guide, here's an article you will enjoy. Learn more about Health Checks here: https://lnkd.in/efkumAua

Building a multi-tenant system? EF Core has some great features you should know about: - Dynamic connection strings - Query filters for global tenant queries You'll need a service to provide the TenantId for the current tenant. You can grab this value from a request header or JWT claim. Side effect: you'll only be able to use the DbContext as part of an HTTP request. If you're curious to learn more about what EF can offer for building multi-tenant applications, check out this article: https://lnkd.in/eBkbktci

If I'm building a new .NET application, I use Minimal APIs. They're simpler, fit nicely with vertical slices, and they're faster. I like to view each Minimal API endpoint as a standalone component. They have some missing features compared to controllers, but there are workarounds. With a library like FastEndpoints, you can define a single use case in just one file. Here's how you can use them to structure Vertical Slices: https://lnkd.in/ejwZfyej What do you think about Minimal APIs?