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.
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.
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.
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.
Last time I wrote a post about the commands. Events are quite similar to the commands – the main difference between these 2 patterns is that the events are related to the things that have actually happened to our entity e.g. by invoking the command. They’re also a core part of the DDD (Domain Driven Design) and can be easily implemented within our software solution.
Which one of us doesn’t like to give commands? It’s the natural way to ask (in a polite way) for a specific task that needs to be completed. Therefore, it shouldn’t be surprising that the command pattern can be also easily implemented within our software, which might provide some serious benefits in terms of loose coupling the existing code.
Do you ever feel like (well, you should) these huge switch + case statements or too many ifs seem to be wrong? What if I told you, there’s one simple trick that will change your life, by getting rid of them? Ok, seriously – I have nothing against switch or if as the way of controlling the flow (I use them quite often) however, there are certain occasions at which the things could be done better. And let me show you another way to achieve the same goal which is much cleaner in terms of code readability and maintenance.
JSON format has been a standard used amongst many different framework and languages for quite a few years now. It’s so cool, that even the .NET Core team have decided to include it in its framework which results in e.g. being able to store the application settings within a JSON file, which is much more human readable and less bloated than the old one App or Web.config written using the XML.
In today’s post, I’d like to present how easy it is to create your own JSON configuration reader and move the application settings to such file.
Post/Redirect/Get or PRG in short is a common pattern used amongst many web applications, that was designed to prevent duplicate submissions of the forms. Not using such pattern may result e.g. in multiple transactions by POSTing the same form twice, which is something that we definitely do not want to see in our applications. Although, it’s quite easy to be implemented in it’s purest form, it’s a little bit more tricky if we want to save the input data provided by the user (let’s say the form has a lot of fields, and regular redirect would reset it to its initial state since it renders a brand new view). In this post, I’ll present how to add such filters to the MVC application that will both save the input data and also the display the validation errors from the ModelState object.
Pagination is (should be) a well-known concept for most of the developers. Whether we want to execute an optimized query on a database that will fetch just a small subset of all available records or increase the web service throughput by returning less data than it’s needed – it all boils down to the efficient usage of the pagination.
I’m going to present my approach to this mechanism, both for the MSSQL and MongoDB databases, yet it can be also used in any other scenario such as in memory pagination.