Since THERE is no suitable work recently, I am idle at home, so I have made a set of technical planning, which can be discussed together. Since there is no team and project, so from a large perspective.
Most teams in the industry today should have the following questions:
- Multi-terminal outbreaks require a lot of people to develop and maintain each terminal, but most of the time there are not that many things to do at once.
- With so many terminals, the technical stack in the team is also chaotic, causing a lot of trouble for accumulation and maintenance.
- Because there are many ends, different teams are responsible for the whole experience of each end, more or less different.
- When the front end communicates with the back end, the format of the API and the data to be returned are extremely confusing.
- A lot of time on the back end is actually spent on the whole API level
It’s the 21st century. Is there a good way?
The node.js explosion brings several benefits. The front end can be developed at all levels. Therefore, we can consider the following two schemes to achieve it.
Multiterminal fusion
Let’s start with the current picture
A lot of effort and time is wasted on the maintenance of different ends, but looking at the above figure, we can see one thing in common: they all have their own component library, and depending on the actual situation, there are always some components that can be reused.
So if we deal with the scheme like this is an OK effect.
Whatever the downstream is, the upstream is consistent, and the two layers are combined through one translation layer. The translation layer can be a plurality of translation units, each corresponding to a downstream framework/language.
The nice thing is that you can do a lot of things with the post-component piece.
However, there will be another problem in this way of playing. In the later stage, a lot of energy will be put on the maintenance of translation unit. At present, it seems to be a positive profit, but it needs to be supported by business scenarios.
Why use the above solution? Is there any other plan?
First of all, there are several other schemes in addition to the above:
Cordova/PhoneGap is a solution that relies entirely on WebView, but is not suitable for complex interactions.
2. It costs a little more to create a syntax mapping framework at the client level.
Because for the client, in fact, it only needs a set of code to execute, so it should not be transferred to the end of the engineering level, increasing the cost of the end level.
After the end
When it comes to performance optimization, yahoo’s military rules are rarely mentioned these days. Why? Because The Yahoo catch-22 is actually enough, or a part of it is outdated, but pure front-end solutions are very limited. What to do? You need the back end to do some of the work, but for the back end, why help you?
The API of the SAP era was messy, and although resetful was followed, it sometimes required a lot of messy arguments and returned a lot of redundant data
The architecture layer looks something like this
How to play it? It can be
The back end is only responsible for the data and microservices at the lower level, and the front end is used to maintain the business and performance at the upper level. The division of labor is clear and clean.