I spent the last week fighting fires, and I went to Tweb Conf over the weekend (my first time at this kind of event), so I didn’t have much output. But the stress, bustle and anxiety of this week have made me understand a few things, and I’m writing this article. It’s not much, just a lot of chatter.

Another important milestone for me last week was when the Nuggets reached LV5. It’s a relief to have achieved my goal. I don’t want to write articles to get more likes, more reads, more sensationalist headlines, nothing to prove. I’ve noticed that the frequency with which I’m checking out for nuggets has dropped dramatically. I used to checkout dozens of times a day.

In the New Year, I hope I can settle down, delve deeply into my own direction, and put more energy into participating in open source.


The outline

  • The plight of small and micro/outsourcing enterprises at the front
  • The concept of the middle platform
  • The front and back ends separate and reseparate
  • Minimal technology stack
  • Avoid ‘single points of failure’
  • The collective good is greater than the individual good
  • Talk about personal development: job-hopping and job-hopping road
  • conclusion
  • extension




The plight of small and micro/outsourcing enterprises at the front


I believe that the head programmers in Dacang are only a minority, and most of the front end programmers still live in the front end team of small and micro enterprises (🔴 note: refers to the team with weak engineering ability, excluding Dacang and Daniu start-up companies), looking at the wall of Dacang. Imagine them shiny and passionate. The same screws are turned, the same front-end engineering is practiced, and the same Vue and React family barrels are used. Others are rivets on the aircraft carrier, while you are screws of Audi double drill.


Dafang talks about high technology, structure and scene. When we talk about food and clothing in front of small and micro enterprises, we more or less face these difficulties:

marginalized

In this type of company, the front end has little say, they are just a simple page implementation, short for cut diagram.

In essence, the nature and size of the business determines that the front-end work will not take up too much weight, and naturally will not be too much attention, and the substitutability is very high. Such companies tend to be in traditional industries, such as hardware and electricity. On the contrary, in industries that rely on the end, such as e-commerce and social networking, the position of the front end will be much higher.

In this environment, the front end doesn’t care too much about the business, and of course it’s easy to be marginalized, playing the straight man in crosstalk.


Assist with chaos/weak infrastructure

Small and micro enterprises, because the overall level of personnel is not high, the collaboration is usually more chaotic, non-standard. This refers to the overall r&d collaboration of a project.

For the front end, our upstream might be the back end, and the code quality and normativity of the back end will have a particularly big impact on the front end. Such as interface chaos, documentation is not standard, application scenarios are not considered, interfaces are not tested… In this kind of work environment, efficiency can be very low and front-end development can be very painful.

The infrastructure is weak, and front-end engineering always feels constrained.


busy

Feel very busy every day, but like what did not do. The daily routine repeats itself over and over again, marking time.


A lonely island

Like being on an island, knowledge and information are closed, and it is difficult to make major breakthroughs in personal ability and technology. The pattern of the company determines the pattern of the individual.


Personnel changes

Can not attract excellent talents, and excellent talents can not stay, the overall level is low, it is difficult to have technical precipitation and development.


Identity with ideals/corporate culture

We’re just here to make money. Don’t talk to me about dreams. We feel like we’re being squeezed, like machines, and that’s not going to make us happy.

Etc etc…




The concept of the middle platform

This year, the concept of zhongtai is very popular, but I don’t pay much attention to it, because I think it is far away from our front end, and only big factories can make it up. Until I heard Zhang Yunlong’s “Headless CMS — Business Middle Platform Solution for Small and micro Projects” on TWeb Conf, I got interested in “Middle Platform”.

Here is the article “Comics: What is The Middle Station?” Popularly explained the concept of the middle station.

It is not a big factory that can practice the middle platform. I found that our application also has a lot of repeated business. Every new application, the back end has to repeat to copy and implement these businesses. It’s a waste of resources on the back end and a disaster on the front end. Because we found that while the business at the back end is inherently repetitive, each copy exposes interfaces and processes that are more or less inconsistent with the previous application for human reasons, and each front-end needs to be readapted.



Zhang yunlong introduced a business platform solution suitable for small and micro projects. He gave an example of Strapi: this is a Headless CMS, which translates to “Headless” content management system in Chinese. The biggest difference between it and traditional CMS is Headless, that is, it only exposes the interface, there is no fixed interface.


With it, you can:

  • Visual, fast business model creation. Similar to creating a database model (database independent), you have the flexibility to configure various field types (in addition to primitive types, support for mailboxes, file uploads) and model relationships.
  • Expose the interface of the specification. supportRestful 和 GraphQL. Built-in support for sorting, paging, filtering, and automatic document generation
  • Built-in permission control system. Role and JWT authentication
  • Easy integration of internal systems. They have the flexibility to interconnect with their own internal systems
  • Extensibility. Plug-in system

Headless CMS is a business ‘middle station’ solution designed for small and micro businesses. With Strapi, we can quickly build simple, peripheral business models that reuse common services and plug-ins.

You can also think of it as a layered architecture that separates the core business from the periphery. The outer layer is more variable and jumbled than the inner layer. The Strapi mid-platform layer separates the UI from the core services. It allows the core services to sink down and focus on implementing more generic services. Strapi can quickly build non-core peripheral derived business models and expose standardized interface paradigms. On the one hand, it can timely respond to the changeable needs of the front end; on the other hand, it can provide standardized and consistent interface paradigms, which can also reduce communication costs and improve development efficiency. Based on this, the front end can also precipitate its own reusable business components.

Of course, as Zhang yunlong pointed out, Strapi is a toy compared to dafang. But for small and micro businesses, developing prototypes quickly to respond to the market and improve r&d efficiency is a good medicine.




The front and back ends separate and reseparate

You can see that the systematization and formalization of front-end development is actually accompanied by a deepening of the separation of the front and back ends:

  • Pangu opens the Sky: There is no before and after end

  • Template age: According to THE MVC architecture, the back end is responsible for MC, implement business and provide data to the front end. The front end takes care of V, or write the template. There was no separation in the structure of the project behind the front end, but responsibilities began to diverge.

  • Interface Era: The back end provides the HTTP/WS interface, while the front end is responsible for requesting the interface and implementing page rendering. Backbone, Angular, React… The front end has been separated from the back end in the project structure. Development efficiency has been further improved. An interface is a convention. In accordance with the convention first principle, the front and back ends can be developed in parallel. However, at this stage, the back-end interface implementation still needs to care about the rendering of the page, and must provide an interface that can satisfy UI rendering.

  • BFF era: BFF is Backends for Frontend. With labor, the anterior and posterior ends are further separated. There are two main reasons: terminal diversity, desktop, iOS, Android, front end, applets… Different clients have different requirements for the interface, and these requirements are variable. In addition, the back-end business is evolving into microservices, so the back-end interfaces tend to be atomized, more single, and more versatile.

    But it can also be painful for front-end development, as implementing a single page requires a lot of interface calls and the resulting performance of the page is reduced. This layer is called BFF, which lets client developers glue back-end common services to the server according to their needs. You don’t have to worry about the UI at this point. In the BFF era, GraphQL and NodeJS are attracting much attention.

  • Serverless Age: BFF implementation requires good infrastructure and r&d process support, and is difficult to build, so it is usually only done by large factories. Serverless leverages the cloud platform to reduce infrastructure dependency and ease of development and maintenance. So Serverless based BFF has a lower threshold. The significance of Serverless for front-end development goes beyond that. I highly recommend the article “Serverless Revolutionizes the new Front-end technology”.


The back end doesn’t want to care about the data needed for UI rendering, it just wants to focus on the implementation of the business. The front end also wants to get rid of the downstream dependence of the back end, since everyone thinks it is not appropriate, separate is the best.

Going back to the opening sentence, the systematization and normalization of front-end development is accompanied by the separation and reseparation of the front/back end, and conversely, it is because of the deepening of the separation of the front/back end that front-end development is normalized and systematized. The concept of “middle platform” introduced by Zhang Yunlong in the last section, in a sense, is also a deepening of the separation of the front and back ends.

So if your team is feeling the pain, it’s a good sign that business is on the upswing, and if nothing else, you’re on the same path that everyone else has been on before, and the back end is further torn.




Minimal technology stack

Keep it Simple, Keep it Stupid. I’ve learned a lot about this principle recently. Technology selection for small and micro teams should not follow the trend and follow the latest and hottest technology, but should choose the minimalist technology stack that suits your team level and business situation.

These four principles are very important:

  • simple
  • automation
  • Clear and sound documentation
  • The constraint

A few examples:

The main purpose of “simplicity” is to reduce the threshold of learning and reduce the burden of the mind. The simpler the interface, the better:

  • Conventions > Configuration
  • Explicit > implicit
  • Declarative > imperative
  • Interface protocol: JSONRPC > Restful
  • Build tools: Parcel > Webpack, as well as vue-cli, create-React-app
  • Framework: Random example Vue > React. Vue is’ relatively ‘easy to get started with, React is so flexible, the community is so full of flowers, and as much as I love it, it doesn’t stop people from doing stupid things.
  • Status management: Mobx > Redux > Rxjs.
  • Of course, scenario-by-scenario


‘Automation’, the things that can be automated, do not rely on documentation, verbal communication:

  • ESlint, Styleint, HTMLlint, Markdownlint… * Lint. There are various Lint tools and community recommendations that automatically detect compliance.
  • The Prettier code is formatted. There is only one code style, not BB


The importance of ‘documents’ is self-evident. Have a look at the document first, then ask others

Restraint. I can feel the despair when things get out of control. This is when you wish you had more constraints and tried to keep your code under control. Examples include Typescript, various * lints. Without a constraint mechanism, a specification would always be a specification.




Avoid ‘single points of failure’

In small and micro front end teams, personnel resources are very limited, and often each person is responsible for different projects, which may cause ‘single point of failure’. If the person in charge of the project takes a leave of absence or leaves, people will be caught off guard. On the one hand, the project handover process can be prolonged, on the other hand, the context switch of other members can be costly. We are especially afraid of taking on a project that is a mess.

The only way to solve the single point of failure is to have more people cross over and work on different projects. The responsibility for a project lies with the team, not the individual. In addition, it can be combined with tools such as code Review, a variety of ways for team members to familiarize themselves with the project’s code.

Code specifications and shared code can also play a big role here. If ‘knowledge’ can be reused and shared across multiple projects, the cost of project context switching is relatively low.


The collective good is greater than the individual good

Whether large or small, the interests of the collective always outweigh those of the individual.

Last week, I made two wrong decisions: one was to ask an emergency project leader for leave; the other was to lead the team to attend Tweb Conf before the project was fully tested and put online. These two decisions led to great risks and were criticized by the superior. Fortunately, they were both settled in the end. Reflect on the following deficiencies:

  • The collective good is greater than the individual good. This is what we have been taught since childhood, that in a group, your actions and decisions are responsible for the group.
  • Lack of overall control of the project and inadequate risk assessment. Although the front end is only part of a complete project, as the front end team Leader, you need to understand the overall progress of the project. You need to know the project’s start time, due time, launch time, development/test progress, current resources, etc. This information is used to make resource allocation plans and risk estimates.
  • Drive the improvement of collaboration efficiency. As a team Leader, you can’t just focus on technology and code. We need to pay attention to the collaboration channels between teams, improve the collaboration efficiency at the team level, and remove communication barriers for team members.

Just as I often tell our team members: the problem is not terrible, but the terrible thing is that you don’t know where the problem is. If you want to make progress, you should reflect more and ask more why…


Talk about personal development: job-hopping and job-hopping road

What do big companies have?


What does a small company have? It may not have anything at all. The space may be large and the ceiling may be low. Most of the time, it’s probably just a stepping stone for you. You’re either in the process of changing your job, or you’re numb and confused.

In any case, the front end of small and micro businesses need to think more about their own personal development. Including myself, I am constantly thinking, unwilling to mediocrity, and trying to find a career that I can spend my whole life striving for, not just work.


For personal development, I have the following suggestions:

  • Decide where you want to dig deeper. Most of the so-called bulls are experts in a specific field. The front end also has a lot of niches right now. Just look at the Tweb Conf layout, which breaks down the main conference (traditional front end), small program & Engineering, Node& Architecture, and cross-end & Synthesis. In addition, GMTC conference theme division also has reference
  • Step out of your comfort zone and try something new
  • Courage. As bold as the man, so great is the land. There are many things you miss without courage
  • Get involved in the community and build your personal brand
  • Stay hungry, Stay foolish
  • Basics are important. Don’t worry to learn the bells and whistles, don’t worry to follow others to see the source code
  • Try to understand the business, understand how the business and the world work, and develop patterns and soft skills




conclusion

The wall of small and micro enterprises cannot be torn down by one person, the expansion and upgrading of business is the real power. If you feel that your company has momentum and momentum, and you share the company’s values, work together to move the company forward. Instead, think seriously about your own development.


Don’t say, each treasure, hard work

extension

  • Serverless For Frontend
  • Serverless sets off a new front-end technology revolution