All the front-end grayscale schemes you want to know are here.

background:

when users open the page, they need to render different iterative versions according to the active id of the page. For example, the code used by activity An is v0.0.1 (featureA), and the version used by activity B is v0.0.2 (featureB)

of course, the grayscale strategy is not only the active id, but may include the following situations

1. by percentage of traffic
2. by region
3. user id
4. activity id
5. Press ip
6. wait

purpose

Let product applications be put on the market step by step, find and modify problems step by step, and adapt to the market

method:

1. nginx + lua + apollo

recommendation index: ⭐️⭐️⭐️⭐️

modify cost: ⭐️⭐️⭐️

specific practice: the user requests nginx,nginx to determine the version that the user needs to render according to the grayscale policy and returns the corresponding version of html. The logic of judging the version is processed by nginx, and the grayscale policy is stored in a database or apollo (such as whitelist ip, whitelist id, percentage value)

advantages:

• does not change the front-end business code, and is easy to maintain

disadvantages:

• the cost of modification is slightly higher, and it requires backend or operation and maintenance support, lua language, and may need to modify the construction process.

2. bff + apollo

recommendation index: ⭐️⭐️⭐️

modify cost: ⭐️⭐️⭐️⭐️

specific approach: similar to the first, only nginx is replaced with node.js, which is suitable for projects with bff layer and bff is responsible for rendering front-end pages

advantages:

• does not change the front-end business code, and is easy to maintain

disadvantages:

• for projects without bff or projects with bff but no rendering tasks, the transformation cost is high, and the bff layer needs to be introduced

3. The front-end ajax requests the backend interface.

recommendation index: ⭐️

modify cost: ⭐️⭐️⭐️⭐️⭐️

specific method: the user requests nginx,nginx to return html, the frontend rendering html, executes the ajax script written by script, requests the backend API, gets the grayscale version number, and finally the frontend dynamically loads different versions of the entry main.js. Here, the grayscale strategy and grayscale version judgment logic are all put on the backend

.

advantage: no

disadvantages:

• the cost of transformation is higher than 2, and both the front end and the back end have to be changed

• Front-end synchronization ajax delays page loading, resulting in white screen, user perception, and possible redirection.

4. Front-end business code logic judgment

recommendation index: ⭐️

modify cost: ⭐️⭐️⭐️⭐️

specific method: the front end is judged by if else in the code, for example, A user uses A component, B user uses B component

advantages:

• pure front end

disadvantages:

• is not suitable for project-level control of Amax B test, but only for component level
• Code redundancy, there may be multiple versions, multiple if judgments, maintenance trouble

5. The front end makes its own judgment on the entry of resources

recommendation index: ⭐️⭐️⭐️⭐️

modify cost: ⭐️

specific method: the user requests nginx,nginx to return html, the front end renders the html, executes the script script, the front end determines the grayscale version number, and finally dynamically loads different versions of the entry main.js. Here the grayscale strategy and grayscale version judgment logic are all processed by the script script in the front-end html.

advantages:

• there is no need for back-end OPS to participate in the transformation.
• Grayscale at the project level without modifying specific business codes

disadvantages:

when grayscale is needed, the frontend needs to be modified to increase the frontend workload

looking at the above situations, and then summing up, there are only three essential problems of grayscale publishing

1. How to deal with packaged resources, that is, how to distinguish between featureA resources and featureB resources

usually when we pack, we only put it in these three places. How do we record the version number?

1. upload to cdn

you can judge by the hash value of the resource address

2. put it on CVM

you need to package different directory names each time, and then the essence is that the address hash is different according to the resource directory name

3. docker image

judge by the version number of the image

2. Where to put the grayscale strategy

1. put it in the database of the backend business
2. apollo
3. Front end

3. Where is the judgment logic of the grayscale version

1. can be put in nginx
2. can be put in BFF (Node.js)
3. can be put on the front end

but when these three problems are combined, there will be a lot of grayscale solutions, which will increase the difficulty of project selection, and may also involve Docker, multiple server environments, for example, when using grayscale, is the grayscale to another set of environment, or just the grayscale of front-end resources. I hope this article can give you some inspiration.