Clean Architecture is a pretty bold statement and quite a hollow and opaque thing to say. I think of Clean Architecture as philosophy. It is not about the system today, but about the system today and tomorrow. More details inside
Systems do evolve and unavoidably evolution leads to breaking changes... If you are doing event sourcing, events evolution is unavoidable, ultimately you will crash 🔥🚒 into it. The more you know, the better you prepared, as they say 🤓
Just want to share one of the tools I'm using daily. A React component for building Web forms from JSON Schema. Transform annoying, time consuming task into simple routine
Events, events, events... Events are everywhere... Event Sourcing, Event Streaming, Asynchronous services and much more. All these technical contexts have something in common, but a lot is different. And this is what this article is about 🤓
Too often, I found myself with bloated Controllers. Or when Controllers seemed like an awkward and redundant solution. Anyhow I kept using them. I know I'm not the only one who trapped in a similar situation? Is it Controllers or us doing something wrong? Here I tried to shed a bit of light on this topic.
I wrote this article in the Visual Studio Code. It was a markdown file in the separate article-dedicated GitHub branch, which eventually became a Pull Request. And if you are reading it, it means that the post made its way to the master branch. The merge event triggered the process that transformed markdown file into a static HTML file, which was finally pushed to a hosting. And now you can read it.
The State Management Goes Wild his is the final article of the series where we explore Redux and its boundaries. In the previous articles, we first dived into the main principles of the Redux, then we tried to move things around and conceptually move Redux from one side to another. This article is all about hands-on experience, and by the end of it, we will have a working application that will follow the design we settled before.
The State Management Goes Wild This is the second article of the series where we will try to find out if there’s a place for Redux on the other side of the fence. Even though this series is base on the assumption that you are more or less familiar with what is Redux, don’t worry if not, as we covered all necessary concepts in the previous article. Take your time and make yourself comfortable with Redux.
The State Management Goes Wild This is the first article of the series where we will try to find out if there’s a place for Redux on the other side of the fence. Even though this series is base on the assumption that you are more or less familiar with the Redux, but don’t worry if not, as we will go over necessary concepts first. Once we are confident with the Redux as a React state manager, we will be exploring how we can use it as a back-end state management and state distribution tool and gradually build the conceptual design.
This article continues the series dedicated to the CQRS pattern. We will be looking at the Command Query Responsibility Segregation pattern as an architecture, particularly dive into the Querying part and try to find out how to fit it in the HTTP. At the time this article is written, two main protocol versions exist HTTP/1.1 and HTTP/2. Version 3.0 is in the draft, so we are not considering it. The main difference between 1.
This article starts the series dedicated to CQRS on top of HTTP. We will be looking at the Command Query Responsibility Segregation pattern as an architecture, particularly dive into the Commanding part and try to find out how to fit it in the HTTP. At the time this article is written, two main protocol versions exist HTTP/1.1 and HTTP/2. Version 3.0 is in the draft, so we are not taking it into consideration.
It is not a guide for building a single page application with the help of React JS. This article is about the tool that empowers modern web to look the way it looks today and provide a seamless experience of navigation, enabling single page applications to exist. Good old days Back in the days, the internet and everything around it was different, as well as expectations from web sites. A typical web site would be a set of HTML pages tied together with cross-references.