Whenever a team is about to start a new project, there’s one question that always comes up: “Which architecture are we going to follow?” And every developer tends to have their own opinion on the matter, which makes perfect sense, because it’s such an important topic. By Vincent Pradeilles.
Think about it: Good architectures result in apps that perform well, are easy to maintain, and are fun to work on. On the other hand, a subpar architecture usually ends up delivering the kind of glitched and clunky project that people neither want to use or maintain.
The goal of a functional reactive architecture is therefore to enable the flexibility of reactive programming while relying on the principles of functional programming in order to structure the code in a viable manner. If we build upon the previously stated definition, we could say that a functional reactive program explicitly subscribes to future events, in order to process them once they have been emitted, in a scalable and maintainable way.
The article then goes over:
- Functional, Reactive?
- Let’s look at a concrete use case
- Beyond front-end development
- Making your project more reactive
The term functional reactive architecture definitely feels like a mouthful. And it should, because it encompasses two very broad concepts of software programming: Functional programming and reactive programming. So let’s start with a quick recap of these two concepts.
The code examples in this article mainly use RxSwift and RxKotlin, but thanks to the API standardization, everything you learn here will be easily applicable in your favorite language. Excellent read!
[Read More]