28 posts tagged with "architecture"

Why Should We Care About Architecture?​

The answer is: to reduce the human resources spent on each feature.

Mobile developers evaluate the quality of an architecture on three levels:

1. Whether the responsibilities of different features are evenly distributed
2. Whether it is easy to test
3. Whether it is easy to use and maintain

Tight Coupling MVC​

For example, in a multi-page web application, when you click a link to navigate to another page, the entire page reloads. The problem with this architecture is that the View is tightly coupled with the Controller and Model.

Cocoa MVC​

Cocoa MVC is the architecture recommended by Apple for iOS developers. Theoretically, this architecture allows the Controller to decouple the Model from the View.

However, in practice, Cocoa MVC encourages the use of massive view controllers, ultimately leading to the view controller handling all operations.

Although testing such tightly coupled massive view controllers is quite difficult, Cocoa MVC performs the best in terms of development speed among the existing options.

MVP​

In MVP, the Presenter has no relationship with the lifecycle of the view controller, allowing the view to be easily replaced. We can think of UIViewController as the View.

There is another type of MVP: MVP with data binding. As shown in the figure, the View is tightly coupled with the Model and Controller.

MVVM​

MVVM is similar to MVP, but MVVM binds the View to the View Model.

VIPER​

Unlike the three-layer structure of MV(X), VIPER has a five-layer structure (VIPER View, Interactor, Presenter, Entity, and Routing). This structure allows for good responsibility distribution but has poorer maintainability.

Compared to MV(X), VIPER has the following differences:

1. The logic processing of the Model is transferred to the Interactor, so Entities have no logic and are purely data storage structures.
2. ==UI-related business logic is handled in the Presenter, while data modification functions are handled in the Interactor==.
3. VIPER introduces a routing module, Router, to implement inter-module navigation.

Why Use Lambda Architecture?​

To address the three issues brought by big data:

1. Accuracy (good)
2. Latency (fast)
3. Throughput (high)

For example: The problems of scaling web browsing data records in a traditional way:

1. First, use a traditional relational database.
2. Then, add a "publish/subscribe" model queue.
3. Next, scale through horizontal partitioning or sharding.
4. Fault tolerance issues begin to arise.
5. Data corruption phenomena start to appear.

The key issue is that in the AKF Scaling Cube, ==having only the X-axis for horizontal partitioning of one dimension is not enough; we also need to introduce the Y-axis for functional decomposition. The lambda architecture can guide us on how to scale a data system==.

What is Lambda Architecture?​

If we define a data system in the following form:

Query=function(all data)

Then a lambda architecture is:

batch view = function(all data at the batching job's execution time)
realtime view = function(realtime view, new data)

query = function(batch view, realtime view)

==Lambda architecture = Read/Write separation (Batch Processing Layer + Service Layer) + Real-time Processing Layer==

What is architecture?​

Architecture is the shape of the software system. Thinking it as a big picture of physical buildings.

• paradigms are bricks.
• design principles are rooms.
• components are buildings.

Together they serve a specific purpose, like a hospital is for curing patients and a school is for educating students.

Why do we need architecture?​

Behavior vs. Structure​

Every software system provides two different values to the stakeholders: behavior and structure. Software developers are responsible for ensuring that both those values remain high.

::Software architects are, by virtue of their job description, more focused on the structure of the system than on its features and functions.::

Ultimate Goal - ==saving human resources costs per feature==​

Architecture serves the full lifecycle of the software system to make it easy to understand, develop, test, deploy, and operate. The goal is to minimize the human resources costs per business use-case.

Very Large JS App = a lot of developers + large codebase

How to deal with a lot of developers?​

empathy​

What is a ==senior engineer==? A team of senior engineers without junior engineers is a team of engineers

1. being senior means is that I’d be able to solve almost every problem that somebody might throw at me.
2. make the junior engineers eventually be senior engineers.

what’s the next step of a senior engineer?

1. senior: “I know how I would solve the problem” and because I know how I would solve it I could also teach someone else to do it.
2. next level: “I know how others would solve the problem “

good programming model​

how people write software, e.g. react/redux, npm. Here comes a model that affects all large JS apps - code splitting.

1. People have to think what to bundle and when to load
2. ==route based code splitting==
3. But, what if it is not enough?
   1. lazy loaded every single component of our website
   2. How does Google do? split them by rendering logic, and by application logic. ==simply server side render a page, and then whatever was actually rendered, triggers downloading the associated application bundles.== Google does not do isomorphic rendering - no double rendering

How to deal with a large codebase?​

==Code Removability/Delete-ability==​

e.g. CSS is bad in code removability

1. one big css file. There is this selector in there. Who really knows whether that still matches anything in your app? So, you end up just keeping it there.
2. People thus created CSS-in-JS

==avoid central configuration of your application at all cost==

1. Bad example
   1. central routes configuration
   2. central webpack.config.js
2. Good example
   1. decentralized package.json

avoid central import problem: router imports component A, B, and C

1. to solve this problem, do ==“enhance” instead of “import”==
2. However, developers still have to decide when to enhance and when to import. Since this might lead to very bad situations, we make “enhance” illegal, nobody gets to use it–with one exception: generated code.

avoid base bundle pile of trash

1. e.g. base bundle should never contain UI code
2. Solve this problem with forbidden dependency tests
3. ==most straight forward way must be the right way; otherwise add a test that ensures the right way.==

Be careful with abstractions​

We have to become good at finding the right abstractions: Empathy and experience -> Right abstractions