Are you using Structured logging in your application?
You better be, or you're losing valuable information.
Structured logging is a standard for my projects.
And Serilog is my go-to library.
Serilog supports structured logging out of the box.
It also has powerful concepts of sinks and enrichers.
Sinks are like destinations for your application logs.
They can range from console or file sinks to App Insights or Datadog.
Enrichers allow you to add extra information to structured logs.
An example of using enrichers is adding a correlation identifier.
What's the point of using structured logging?
Structured logs can easily be searched and analyzed.
Of course, you'll need a tool to do that.
Tomorrow, I'll show you a free tool to filter structured logs.
And 4 more best practices to improve structured logging with Serilog.
Join 35,674+ engineers here: https://t.co/ZhzaPlA9l6
P.S. Repost this so more people can find out about The .NET Weekly. ♻️
What is API versioning, and why is it important?
It's a critical concept to understand if you're building APIs.
Here's a fun story from a project I worked on.
I was building a public API that had dozens of integrations.
Many (independent) mobile applications use the API to server content.
When your API is serving so many clients, breaking changes are costly.
So, everything I implemented on the public API had to be planned.
❌ Adding a new field?
✅ Forget about it.
❌ Renaming existing fields?
✅ Forget about it.
If I wanted to introduce breaking changes, I had to version the API.
Here are 3 popular ways to do API versioning:
- URL versioning
- Header versioning
- Query parameter versioning
ASP .NET Core supports all of these versioning approaches.
You can learn more about API versioning here: https://t.co/uiB8jNhG6z
Back to the application I was working on.
I used URL versioning on that API.
The default version was v1.
New endpoints would go to v2.
So you can have two instances of the same endpoint:
- api/v1/products
- api/v2/products
The API consumer decides which version they will use.
Sometimes, we had to deprecate old API endpoints.
You first create a new version of the API endpoint.
Then, let your clients know they should move to the latest version.
After a while, you remove the endpoint from the API.
Monitoring the old endpoint usage is helpful here.
You will need API versioning for public APIs.
It's also practical in Microservices architecture.
P.S. If you got value from this post and want to improve your software architecture skills, subscribe to The .NET Weekly - my newsletter with 35,000+ engineers.
Subscribe here → https://t.co/VYvfbj4G2h
How do you version your API?
You won't become a senior software engineer with 2 years of experience.
And that's not to discourage you - quite the opposite.
I've seen a lot of talk about becoming a senior engineer quickly.
It only takes 1-2 years. Right?
And it probably does - for some people (power to them).
But this isn't a realistic timeline for the majority of developers.
It took me ~4.5 years to get promoted to a senior role.
I'm willing to bet I solved many more problems than my peers with the same experience. I worked damn hard - and experience compounds.
So how can you get there faster?
It's simple: you need to become more competent.
You need skills.
A whole lot of skills.
✅ More skills = bigger impact
✅ More skills = better job
✅ More skills = better pay
You need to be hungry for knowledge:
- Books
- Articles
- Courses
- Workshops
- Conferences
But you don't want to be just "book" smart.
The real difference maker is real-world experience.
You need to work on challenging projects. And you need to do that for an extended period of time. And I promise you, you'll get promoted sooner or later.
This is why some folks get promoted to senior roles in 2 years.
They worked their butts off to get there.
They also sacrificed many things along the way.
Things you might not be willing to sacrifice.
You choose your own path (fast or slow).
But don't forget to enjoy it.
---
P.S. If you liked this, consider joining The .NET Weekly - my newsletter with 35,000+ engineers that teaches you how to improve at .NET and software architecture.
Subscribe here → https://t.co/VYvfbj4G2h
The crucial developer skill you need is refactoring.
Refactoring is a technique for restructuring existing code without changing its behavior.
You can think of refactoring as a series of small code transformations.
One change (refactoring) does little. But, a sequence of refactors produces a significant transformation.
Every refactoring should have a clear goal.
For example, I want to improve three qualities of my code:
- Testability
- Readability
- Maintainability
And the best way to learn refactoring is to practice.
Here's an interesting refactoring challenge to try: https://t.co/GIWuki5JEX
What is GraphQL, and how can you use it in .NET?
First, let me explain what GraphQL is in simple terms.
GraphQL is a query language for APIs.
It enables clients to get the exact data they need.
And all this from querying a single GraphQL endpoint.
How is this useful?
Well, it can improve performance by reducing round trips.
GraphQL endpoints can return all the data you need in one request.
At this point, your engineer brain might light up. 💡
How does this work on the server?
When a GraphQL query hits your API, you still query the database. But you parse the GraphQL query and fetch the required data.
So GraphQL is like REST in that regard.
However, with GraphQL, it's easier to shape the API response.
You can also implement this with REST APIs, but it's more verbose.
Hot Chocolate is a popular GraphQL server for .NET applications.
It takes the complexity away from building GraphQL-compliant APIs.
I'll dedicate a separate post to Hot Chocolate.
You don't have to wait for that, though.
It's open-source, so go check it out.
So, how do you test GraphQL APIs?
You can use the Postman GraphQL client to test your APIs.
Here's how to get started with GraphQL: https://t.co/owfrZx68j2
REPOST = Teach your audience about GraphQL ♻️
𝗪𝗵𝗮𝘁 𝗶𝘀 𝗴𝗥𝗣𝗖 𝗮𝗻𝗱 𝘄𝗵𝗲𝗻 𝘀𝗵𝗼𝘂𝗹𝗱 𝘆𝗼𝘂 𝘂𝘀𝗲 𝗶𝘁?
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.
It's a way to execute code on another server, like a local method call. RPCs 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.
If you want to test your gRPC APIs - Postman has excellent tooling.
Check it out here: https://t.co/KeBGMGbpVZ
Have you ever built a gRPC service before?
REPOST = Teach your audience about gRPC ♻️