system architecture

In one of my earlier posts, I described the Backend-for-Frontend pattern. In short, it offers a single facade over multiple backend parts. Moreover, it provides each client type, e.g. desktop, mobile, exactly the data that it needs and not more in the format required by this client type. The use-case Imagine the following use-case. In a e-commerce shop, the home page should display multiple unrelated data at once. Products: The business could configure which items are shown on the home page.

In the good old days, applications were simple. A browser sent a request to a webapp endpoint; the latter fetched data from a database and returned the response. The rise of mobile clients and integrations with other apps upset this simplicity. I want to discuss one solution to handle the complexity in this post. The increased complexity of system architecture Let’s first model the above simple architecture. Mobile clients changed this approach. The display area of mobile clients

Some libraries, frameworks, components, and architectures either encourage statelessness, or make it a requirement. While statelessness has a lot of benefits, it’s unfortunately rarely possible in the real world. In this post, I’d like to detail this stance of mine a bit. State in Functional Programming Functional Programming is based on a set of principles. Among those principles are pure functions: A pure function is a function that has the following properties: Its return