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.
Command Query Responsibility Segregation This pattern gains popularity lately. And there’re certain benefits of using it as well as drawbacks. I would like to share my own experiences and thoughts on this topic. ℹ️ Don’t forget to check out more advanced series dedicated to appliying CQRS architectural patter on top of HTTP [CQRS via HTTP]. The series covers in depth main actors of the pattern, such as Commanding and Querying, as well as how do they fit in the HTTP.
The JSON Schema Have you ever found yourself in a situation when your application requires pre-defined data which you will use to build your business logic, but besides that you need a capability to extend your data, in a way so it stays meaningful. Maybe even extend it differently depending on circumstances. It might depend on the users location, or preference. Or it might depend on the customer, and customer-specific data.