Welcome to the first, or actually, the episode number 0 of my first online course ever named “Becoming a software developer”.
It’s been a few months already since I’ve started working for good with distributed systems using (micro)services and asynchronous processing via service bus. Many issues and question raised and one of these was how to not lose the information about commands and events being processed and even more importantly, how to notify the user once the request has completed? I’ve had to come up with some solution that seems to be sufficient (at least for now) and I’d like to share it with you.
Choosing a service bus that meets our demands is a crucial part when developing a distributed system. There are many services to choose from like MSMQ, Azure Service Bus or RabbitMQ and even more frameworks that you can use in your projects as an additional layer of abstraction that makes your coding much easier when it comes to dealing with the specific service bus implementation. In this article, I’d like to present how to use the RabbitMQ in .NET Core with the help of really nice RawRabbit library.
I’ve eventually decided to start using the *NIX system for the software development.
Being a Windows user and the .NET developer for many years now, it might seem like a radical change, but let me tell you this – it was a great decision and here is the explanation.
It’s been quite a while since I’ve started gathering some knowledge about the microservices architectural pattern that’s been on a hype recently. After reading many articles, some books like Microservices in .NET Core and talking with smart guys in the Devs PL Slack channel, I’ve eventually decided that the time has come to try to make the microservices happen in the real world project. That’s the beginning of my journey into the distributed programming and architecture, so please keep that in mind while reading this newbie’s post and remember I’d be more than happy to hear your opinions and feedback about the approach that I’m about to present.
It’s been 2 months since the latest version of the Warden has been released as the NuGet packages. Although our focus (yes, I’m not the only one person anymore working on this project) has moved towards the development of so-called stack (brand new API, Website, Microservices etc.) I’m still actively developing the core library in order to make it even more useful than before.
Nowadays, the HTTP APIs act as gateways for petabytes of data and some chunk of it might actually require enhanced access rules. For example, you could create a link that allows the user to download the file only once, and within such link you would find a token.
I was in a need of creating such solution for my open source project Warden – a specialized, one-time link that can be used fetch the configuration object from the API.
It turned out to be fairly straightforward to implement the most basic version of such behavior.
In case you’re not familiar with the Warden project that I’ve been working for the last few months, I strongly recommend you to take a look, as you may find this tool especially useful for monitoring your infrastructure and resources. So what is the Warden Spawn?
It’s a brand new repository within the Warden Stack that will let you configure the instance of the Warden monitoring application using the human readable configuration files – and that’s just the beginning!
There are many ways to perform a validation of our models living within the system.
Whether there’s an incoming request from the user who would like to create an account or there’s a need to ensure about the correct amount of money in a bank transaction, the validation process should always (I really mean that) take place. In today’s post, I’d like to present one of the possible solutions that might help you validate your entities.