DEV Community: Atri

My understanding of MVI architecture

Atri — Mon, 26 Jun 2023 13:38:17 +0000

Context

Recently, I’ve been attempting to construct an RSS reader app on the iOS platform. Despite my limited experience in iOS development, I’ve utilized the MVVM pattern to structure my code due to its simplicity.

However, as the development process unfolded, I discovered the challenge in managing and understanding data flow when dealing with multiple views. I also faced difficulty when certain actions necessitated the modification of multiple states, without a straightforward method to illustrate these changes. Although I sought to encapsulate the state updating logic, achieving this proved difficult.

Fortunately, during a knowledge-sharing session at work, a mobile developer colleague introduced a potent architecture for iOS development: the MVI pattern.

Subsequently, I’ve devoted time to studying this architecture via resources like ChatGPT 😉 and Google. I’ve successfully transitioned my code to this new architecture. Even though my daily responsibilities do not involve mobile development, the learning journey provided insightful concepts. As such, I’ve compiled these findings into this article to provide a succinct overview.

Overview

While it’s essential for an article to concentrate on a single topic, I intend to explore multiple themes in this piece, given their significance in elucidating my understanding.

Initially, I plan to delve into the mechanics of the modern UI framework. Regardless of whether the framework is employed on a browser or mobile platform, employing different technologies, these exist shared principles underpinning it.

Drawing on the discourse around the UI framework, we will then address the fundamental challenge that front-end development aims to overcome.

Following that, I’ll outline the mental model pertaining to the MVI architecture. We won’t devote extensive time to specific MVI concepts, as they are not the crux of our discussion. Instead, we’ll delve into the precise functionality of this architecture and how it aids in reducing system complexity.

UI framework

There exists a multitude of UI frameworks worldwide. Given that different platforms utilize different languages, the frameworks for mobile platform differ from those for the web. However, if we disregard the technical specifics, what is the primary function of a UI framework?

The answer lies in maintaining synchronization between the UI and the state.

Contrasted with the framework of decade ago, today’s UI developers handle an enormous amount of data. This data comes from varied sources and possesses different structures. Our task extends beyond merely retrieving a static array from the backend and wrap it within a series of <li>. Our focus lies in generating data from rendering. Hence, the UI framework assumes the remaining responsibility: maintaining synchronization between the UI and the data (state).

By the way, the state referred to here denotes data that induces side effects by updating the UI.

If you find this topic engaging, here’s an amazing article offering a detailed information.

The difficult in UI development

As previously mentioned, the UI framework updates the UI based on the state, making our task the production of data usable by the UI framework. Sounds straightforward, doesn’t it? However, it’s actually the most complex part of the process.

The first challenge is the diversity of data sources. We need to render data originating from the Backend, and user actions can also create new data impacting existing data.

The second challenge lies in the dynamism of the data. Backend data may be changed by other systems, and users can also modify the data. In other words, the data transitions into a data stream, requiring us to update the state based on this stream. This introduces logical mutability to the state. Regardless of the framework or platform in use, a pressing question arises: how to comprehend the logic of state changes within a large system?

The third challenge is that a single UI update might involve multiple states. For instance, when we dispatch a network request to the backend, we usually need to disable the submit button, display a loading animation, and upon receiving the response, render the UI based on the results. Sometimes, an error screen might also be required. As can be seen, the states are interdependent and operate collectively in various scenarios.

From the above discussion, you may discern that the crux of UI development challenges is how to devise an architecture that facilitates our understanding and testing of state changes with ease.

MVI architecture

MVI, the most recent addition to the MV* family, structures an application into three components.

Model: Represents the states for the UI
View: Represents the UI itself
Intent: Represents actions triggering state updates

The following diagram provides a comprehensive overview of the MVI architecture.

The term “someone” at the bottom of the diagram refers to any entity that could potentially alter the UI, such as user input, network requests, or asynchronous work.

Under the MVI architecture, these entities are disallowed from directly modifying the state. Instead, they generate an intent. This intent essentially comprises logic designed to update several states based on the intent’s function, which is crucial to understanding the MVI architecture.

Consider the following code as a typical intent function. Note that in actually development, we wouldn’t write code exactly like this; it’s purely to illustrate the function of intent.



func viewOnAppear() {
  model.isLoading = true

  networkService.fetch("https://www.example.com/api") { result in
    switch result {
    case .success(let data):
            model.data = data
      model.isLoading = false
        case .failure(let error):
            model.isError = true
    }
  }

  // ...
}

The code demonstrates a scenario where we wish to perform certain actions when the view appears. Consequently, we have a function named viewOnAppear to execute these tasks, which includes displaying a loading screen, fetching data from an API, and assigning data or showing an error screen depending on the network response.

This function involves multiple UI updates. Reading through this function’s code makes the behavior abundantly clear. Using the same concept, we can encapsulate other actions into distinct intent functions like submit, onTapListItem, onDeleteItem.

In essence, the function of an intent is to bundle state changes into various actions, thereby simplifying the understanding and testing of these logical processes.

Code example

From the preceding discussion, we’ve underscored that the crux of the MVI architecture lies in managing state changes. Understanding this principle enables us to apply this architecture universally.

In this section, we’ll demonstrate how to implement the MVI architecture in iOS development using Swift.

To begin with, we’ll construct the model for our sample app. The model’s role is to mange the data and state, providing various helper functions for easier using.



class ExmapleModel: ObservableObject {
    @Published var contentState: ContentState = .loading
}

// MARK: - Helper function
extension ExampleModel {
    func update(rawData: [Item]) {
        contentState = .content(data: rawData)
    }

    func displayLoading() {
        contentState = .loading
    }

    func displayError(_ error: Error) {
        contentState = .error(text: error.localizedDescription)
  }
}

// MARK: - Helper enum
extension ExampleModel {
    case loading
    case content(data: [Item])
    case error(text: String)
}

In this example model, we have a singular state: contentState. Leveraging the functionality of SwiftUI, any updates to contentState will trigger a UI re-render. In the first extension, we’ve introduced several helper functions, all of which manage intricate state manipulation logic, ensuring consistent and predictable state changes. These functions are purely functional and do not induce any side effects.

Having completed the model code, it’s now time to create an intent class.



class ExampleIntent {
    private weak var model: ExampleModelProtocol?
    private weak var networkService: NetworkServiceProtocol?

    // This is a series of Publishers
    let routerSubject = Subjects()

    init(...) {
        // ...
    }
}

// MARK: - Intents
extension ExampleIntent {
    func viewOnAppear() {
        model?.displayLoading()

        networkService.fetch(to: "https://example.com/api") { [weak self] result in
            switch result {
            case let .success(data):
                self?.model?.update(rawData: data)
            case let .failure(error):
                self?.model?.displayError(error)
            }
        }
    }

    func onTapItem(id: String) {
        // This code will go to another page
        routerSubject.screen.send(.tapFollow)
    }
}

In the above code, we’ve re-implemented the viewOnAppear function. As can be observed, we’re updating several states and issuing a network request within this intent. Our state changing code is no longer dispersed but encapsulated within intent functions.

At this point, we can proceed to implement the view.



struct ExampleView: View {
    private var state: ExampleModelProtocol
    private var intent: ExampleIntentProtocol

    var body: some View {
        VStack {
            switch state.contentState {
            case .loading:
                LoadingContent(text: "loading...")
            case .content(let items):
                ListContent(items: items)
            case .error(let text):
                ErrorContent(text: text)
            }
        }
        .onAppear(perform: intent.viewOnappear)
    }
}

// MARK: - Views

private extension ExampleView {
    struct LoadingContent: View {
        // ...
    }

    struct ErrorContent: View {
        // ...
    }

    struct ListContent: View {
        let items: [Item]
        let intent: ExampleIntentProtocol

        var body: some View {
            List {
                // render the items
                Row()
                    .onTapGesture {
                        intent.onTapItem()
                    }
                // ...
            }
        }
    }
}

Using the MVI architecture to structure our code makes state changes and view updates predictable. The view will transition between loading, error, and list based on the contentState. All actions potentially altering the state are enclosed within the intent functions, making them easier to comprehend.

Summary

In this article, we’ve explored the MVI architecture.

Before diving into any new architecture, it’s essential to identify the problems we’re facing and the crux of those issues.

In UI development, the framework ensures synchronization between the state and view, which shifts our focus to managing state changes. In a large system, these state changes can become quite complex. Thus, we employ the MVI architecture to reduce system complexity. The linchpin of this architecture is the Intent, a discrete level solely focused on altering states through clear, identifiable actions.

Reliable, Scalable, and Maintainable Applications

Atri — Mon, 09 Jan 2023 12:38:04 +0000

This is a reading note for Designing Data-Intensive Applications

Overview

For a developer working in a commercial company, the most frequently encountered systems are data-intensive systems. Different companies have different businesses, but behind the different business models is a set of general abilities. For example, application code, in-memory cache, primary database, message queue, e.g., The commercial company doesn't have enough resources to allow developers to implement all of them; therefore, we make architecture decisions according to the problem scales. A website with only 2,000 visits per day doesn't need to consider caching, but things become entirely different for a website with 2,000 visits per second.

Before jumping into the details of data-intensive systems, we need to know how to evaluate a system. Or in other words, when we say a good system, what exactly are we talking about? Generally, we will evaluate a system from three aspects: reliability, scalability, and maintainability. We will discuss some techniques, architectures, or algorithms to achieve these goals. But before it, we need to understand these terms clearly. Consistent and clear terms understanding is the first step in discussing system design.

Reliability

We often refer to this term when discussing system architecture, but people often misunderstand it. It's worth noticing that reliability is not describing the system returning the right value that the user expected or tolerating mistakes made by users; it means continuing to work correctly, even when things go wrong. Therefore, when we talk about reliability, we are actually talking about fault-tolerant. A good paper called A Conceptual Framework for System Fault Tolerance expounds on this topic. Thus, we will focus on this paper in this section.

Faults and failures

A precise understanding of these two terms is the first step in understanding system reliability.

A fault is usually defined as one component of the system deviating from its specification, whereas a failure is when the system as a whole stops providing the required service to the user. A system may continue to provide its service even when encountering a fault. Such a system is called fault tolerant.

It's impossible to reduce the probability of a fault to zero. Therefore it is usually best to design fault-tolerance mechanisms that prevent faults from causing failures.

Dependencies and failure regions

If a component's behavior's correctness requires the second component's correct behavior, we say the first component depends on the second component. An actual system may have a set of possible dependencies forming a graph. The graph is acyclic if it forms part of a tree, while it is cyclic if part of the dependencies connects to themselves. It is better to describe the second situation as a directed cyclic graph.

When we design a fault-tolerant system, it is essential to identify the dependencies between components of the system. Dependencies may be static, or they may change.

A fault that occurs on a component may transmit in the dependencies graph. Thus it is essential to understand the failure regions. We define the failure region as a limitation of considering faults and failures to a portion of a system and its environment.

Fault tolerance mechanisms

Based on the discussion above, we introduce three fault tolerance mechanisms.

The first is redundancy management. It provides redundant resources for the system and automatically replaces a component when it fails so that it can continue providing service for the users. The second is acceptance test techniques. The components of the system execute the testing for the information from other components before using it. This mechanism can work in the non-redundant system. The third is comparison techniques. Multiple processors are used to execute the same program and compare the results across processors.

Achieve reliability

Based on the discussion of reliability and fault-tolerant system, it's easy to understand the first step in implementing a reliable system is to understand your system precisely. You need to know the system's requirements so that you will have enough information to identify the portions that may go wrong. Determine the appropriate fault containment regions to deal with fault and make the time/space trade-offs.

Scalability

Reliability describes if a system can work reliably at that moment, but it does not mean a reliable system can still provide reliable service in the future. The number of users may increase, which puts the system under more pressure. Therefore, we use scalability to describe a system's ability to cope with increased load.

We will discuss the load and performance first. A good understanding of these two concepts can give us enough information to make trade-offs when developing the system's solution. After that, we will briefly talk about some approaches. It's hard to talk about all details of these approaches in an article; thus, we only talk about some conceptual stuff.

Describing load

Succinctly describing the load is the first step in improving the performance of our system. We always use a few numbers called load parameters for this requirement.

The choice of load parameters depends on the architecture of your system. If the core function requires intensive reading and writing to the database, the ratio of that behavior is a good candidate. There is no universal parameter measure of system load; you need to understand your system or the function you're interested in before choosing them. The book takes Twitter as an example; you can read it for inspiration.

Describing performance

Generally, we want the best performance with the least amount of resources. Therefore, we have two ways to investigate the performance of our system when loading increases.

Keep the resource unchanged when you increase the load parameter and observe how the performance is affected.
Increase the resource to keep the performance unchanged. Observe how many resources you need to increase.

Like the load, we need to use a few numbers to describe the performance of our system. We always use response time for the online system to describe the performance. It describes the time between a client sending a request and receiving a response.

It is vital to recognize that response time is not a single number but a distribution of values. Therefore, looking at the average becomes meaningless from a statistical point of view. A system with an unstable response time may have the same average value as a stable system. But the resulting user experience is completely different.

We always use percentiles to bypass the fundamental issue with averages. The idea is to take the data during a period of time and sort it, then discard the worst 1% and observe the remaining value. For example, we can find the largest value that occurs at 99% of the response time. In practice, we often choose the 99.9%, 99%, 95%, and 90%.

Why can't we use the 99%? Let's suppose that the largest value that occurs at 99% of the response is 400ms. It means 99% response time during this time is better than 400ms, but we don't know the distribution of these better values. Maybe we have 100 response time records; 80 of them are 398ms. Therefore we need to review the percentiles of the response time to recognize the distribution.

At the same time, it is necessary to know what we talked about above is only researching a single request. In modern websites, a web page may need to send hundreds of requests. Therefore, although you may have put a lot of effort into improving the performance data, the users still experience the worst situation with a high probability.

If you want more information about this topic, I suggest you read Why Percentiles Don’t Work the Way You Think and Everything You Know About Latency Is Wrong.

Approaches for coping with load

Based on the discussion of load and performance, we can say when we talk about the scalability of a system, we are talking about how to maintain good performance under increasing load parameters.

We already have some common methods for addressing this requirement in modern software development. Like auto-scaling, load balancing, caching (including CDN), and distributed systems. We will talk about them in the future because each topic needs much discussion and has tons of details.

Another thing is the trade-off during the architectural design. Although we have many ways to improve the performance, we can't implement all of them because of the limited resources. Therefore. a smart way is to use the simplest way and refactor it until the current strategy or high-performance requirements force you to change it. But with the improvement of cloud service infrastructure, some approaches like distributed databases may be the default in the future.

Maintainability

The majority cost of software development is in its ongoing maintenance instead of the initial development. Although we can not eliminate the pain of maintaining an old project, we should use some ways to reduce it. To achieve this, we should pay attention to three design principles: operability, simplicity, and evolvability.

Operability

Developing software is not only include writing code; it also includes running it smoothly.

For example, we need to monitor the system's health by collecting logs and data; we need to use CI/CD to release the new version smoothly; we need to keep the software up to date; we need to share knowledge about the software with team members who doesn't participate in; we need to establish the good practices for development. Most of these requirements can be addressed by using some automatic tools.

Good operability makes the team's life easier. The team can focus on more valuable things.

Simplicity

Managing the complexity of the software is the core topic of development. As time goes by, more and more functions are added to the system, and the system may also accumulate a lot of technical debt. These factors make the system becoming complex and difficult to understand.

Two effective methods are abstraction and delamination. It can hide the complexity behind a clean facade. This book will introduce some approaches to dividing the huge system into well-defined, reusable components. If you want to know how to do the same thing for the code, a book worth reading is Structure and Interpretation of Computer Programs.

Evolvability

As we mentioned before, the system is not static stuff. We don't only refactor the code and architecture to support more users but also add new features and change the existing functions. Therefore, evolvability is an important measuring aspect of the system.

The agile working patterns provide a good framework to deal with this problem. Some technical tools and patterns from the agile community are useful for the system. Test-driving development and refactoring are probably the most well-known methodologies.

Summary

This article talked about some fundamental principles of measuring data-intensive applications. A good understanding of these principles is the first step to jumping into deep technical details. Although we will introduce more technologies to make the applications reliable, scalable, and maintainable, we will never have a one-size-fits-all solution. Succinctly understanding your system is always the first step to addressing the problems and making the application better.