DEV Community: Mark

[Boost]

Mark — Tue, 11 Aug 2026 10:10:02 +0000

Mark

Aug 11

Rethinking DELETE: Idempotency Design and Correct Semantics for Delete Endpoints

#api #architecture #backend #systemdesign

5 min read

Rethinking DELETE: Idempotency Design and Correct Semantics for Delete Endpoints

Mark — Tue, 11 Aug 2026 10:08:05 +0000

In many backend projects, the DELETE endpoint is often treated as the simplest kind of CRUD operation.

The typical implementation looks like this:

DELETE /users/123

And the logic behind it:

Find the user
Delete the data
Return success

If the data doesn't exist:

404 Not Found

This seems intuitive enough.

But once we dig deeper into REST semantics, idempotency, network retries, and distributed systems, we discover that the DELETE endpoint isn't nearly as simple as it looks.

A well-designed DELETE endpoint shouldn't ask:

"Did I actually perform a delete action?"

It should instead ask:

"After this request completes, is the resource in a nonexistent state?"

This shift in perspective is the key to rethinking DELETE.

1. What Is Idempotency?

In the HTTP specification, idempotent means:

Executing the same request once versus multiple times produces the same final effect on the server's state.

For example:

PUT /users/123

Setting the username:

{
    "name": "Tom"
}

First call: name = Tom
Second call: name = Tom

The final state is the same, so PUT is idempotent.

DELETE is expected to be idempotent as well. For example:

Initial state: User 123 exists

Call	Result
1st `DELETE /users/123`	User 123 no longer exists
2nd `DELETE /users/123`	User 123 still doesn't exist
3rd `DELETE /users/123`	User 123 still doesn't exist

Even though the first call actually changed the data, subsequent calls don't change anything further — but the final state remains consistent.

So DELETE is naturally idempotent.

2. A Common Mistake: Treating "No Change" as Failure

Many endpoints are designed like this:

First request:

DELETE /users/123

200 OK
{
    "success": true
}

Second request:

DELETE /users/123

404 Not Found
{
    "success": false,
    "message": "User does not exist"
}

This looks reasonable at first glance, but there's a real problem: did the second request actually fail?

The answer is: no.

Because what is the client's actual goal? It's not to ask the server to:

"Perform one delete action"

It's to ensure:

"User 123 does not exist"

After the second request executes, user 123 still doesn't exist — the goal has already been achieved.

So from DELETE's true semantics, the second request should also be considered a success.

3. The Real Semantics of DELETE: Ensuring the Resource Does Not Exist

Many developers think of DELETE as:

"Delete the data"

But a more accurate way to understand it is:

"Ensure the resource enters a nonexistent state"

For example:

DELETE /currencies/123

This expresses:

"Please make sure Currency 123 does not exist."

Therefore:

Request	Before	After
1st	Exists	Does not exist
2nd	Does not exist	Does not exist
3rd	Does not exist	Does not exist

Final state: does not exist — consistently, every time.

That is what true idempotency means.

4. Why Should "Already Nonexistent" Also Count as Success?

The biggest reason: networks are unreliable.

Consider a real-world scenario:

Client sends DELETE
Server deletes successfully
But the response is lost in transit
The client doesn't know what happened
So the client sends DELETE again

If the second request returns 404, the client is left confused:

Did the first request actually succeed?
Do I need to refresh the page?
Do I need to show an error to the user?

If DELETE is instead designed so that "already nonexistent" also means success, then:

First request → deletion succeeds
Second request → the target state is already satisfied

The client doesn't need any extra logic to handle the ambiguity.

5. What Should `success` Actually Represent?

This is a critical design principle:

success indicates whether the request completed successfully — not whether the data actually changed.

Many systems run into trouble because they conflate these two concepts.

Wrong approach:

{
    "success": false,
    "message": "No data was deleted"
}

Because: not deleting any data does not mean the request failed.

Better approach:

{
    "success": true,
    "data": {
        "deleted": false
    }
}

Meaning:

The request executed successfully
But it didn't produce a data change

These are two separate concepts, and they should be kept separate.

6. Recommended DELETE Response Design

For simple resources

Examples: tags, categories, currencies, personal settings.

Recommended:

DELETE /currencies/123

{
    "success": true,
    "message": "Deleted successfully"
}

Regardless of whether it's:

the first deletion,
a repeated deletion, or
the resource was already gone,

the response is always success.

When you need to know whether a change actually occurred

{
    "success": true,
    "data": {
        "deleted": true
    }
}

First call: "deleted": true
Second call: "deleted": false

Note that success is true in both cases, because the request itself succeeded.

7. Why Are Orders and Contracts Different?

You might ask: shouldn't order deletion work the same way?

Answer: not necessarily.

Orders, contracts, and approval records are no longer simple resources. They represent:

Business facts
Legal records
Financial data
Audit information

Deletion itself becomes a meaningful business action.

For example, an order typically flows through states:

Created → Paid → Cancelled

And a contract:

Draft → Signed → Terminated

In these scenarios, a real DELETE is usually never performed. Instead, the system records a state change, such as:

status = CANCELLED

or:

deleted = true
deleted_by = xxx
deleted_time = xxx

Because the system needs to know:

Who deleted it
Why it was deleted
When it was deleted
What state it was in before deletion

8. When Do You Need to Know Whether the Resource Existed Before Deletion?

Sometimes you do. For example:

Audit systems

When an administrator deletes a contract, the system needs to record:

Deleted contract A
Operator: Zhang San
Time: 2026-08-11

Here, whether the resource genuinely existed beforehand matters a great deal.

Financial systems

When deleting a payment record, the system must confirm whether the payment record genuinely existed — otherwise it could cause accounting discrepancies.

But this kind of requirement should not be expressed through success = false. It should instead be handled through:

Audit logs
Business status fields
Dedicated response fields

9. Practical Design Recommendations

For ordinary CRUD resources (users, categories, tags, settings):

DELETE means "ensure the resource does not exist"
Nonexistence is not a failure

For business objects (orders, contracts, approvals, payments):

Use state transitions
Avoid actual deletion

10. Summary

A mature DELETE endpoint design is not this:

Call the delete method
    ↓
Check whether data was actually deleted
    ↓
Return success or failure

It should instead be this:

Understand the client's goal
    ↓
Bring the resource to that target state
    ↓
Return the outcome of the request

Core idea: the goal of DELETE is not the act of deletion — it's the final state.

Therefore:

DELETE should be idempotent
A nonexistent resource is not necessarily a failure
success reflects whether the request completed, not whether the data changed
Whether data actually changed is a business-level result
Business-critical data should not be casually hard-deleted

In one sentence:

Good API design doesn't describe what the server did — it describes what state the client wants to reach.

This is exactly why a seemingly simple DELETE endpoint can reveal so much about a backend engineer's understanding of REST, distributed systems, and business modeling.

Java Concurrency Programming Learning Roadmap: Understanding Threads Through Problems

Mark — Thu, 23 Jul 2026 04:27:50 +0000

Many developers start learning concurrency by memorizing APIs directly.

For example:

How to create a Thread.
How to use Runnable.
How to add synchronized.
What is the difference between ReentrantLock and synchronized.
What is AQS.

However, this learning approach has a problem:

You may know how to use the APIs, but you do not understand why you need them in real business scenarios and how to choose the right solution.

Therefore, I believe the best way to learn concurrency is not starting from APIs.

Instead, we should start from problems.

1. Why Do We Need Concurrency?

Let's start with a question:

Why do programs need concurrency?

Assume we have an order system.

After a user submits an order, the system needs to perform several operations:

Deduct inventory.
Create the order.
Process payment.
Send notifications.

If everything is executed sequentially by a single thread, the workflow looks like this:

First:

Deduct inventory

After it finishes:

Create order

After it finishes:

Process payment

After it finishes:

Send notification

The total execution time of all steps becomes the response time of the entire request.

However, after analyzing the process carefully, we can find that some operations do not need to block the user.

For example:

Sending SMS notifications.
Recording operation logs.
Updating statistics.

These operations do not affect whether the order is successfully created.

Therefore, we can move them to background threads and execute them asynchronously.

This is the first value of concurrency:

Improving system response time

Besides asynchronous execution, there is another important reason:

Making better use of multi-core CPUs

Modern servers may have:

8 CPU cores.
16 CPU cores.
32 CPU cores.

If an application only uses one thread, then effectively only one CPU core is doing the work.

If a task can be divided into multiple independent parts, multiple threads can execute them simultaneously.

Therefore, concurrency mainly solves two problems:

Improve system responsiveness.
Improve hardware resource utilization.

2. When Multiple Threads Run Together, What Problems Appear?

Many people think:

Multithreading simply means splitting tasks among multiple threads.

But things are not that simple.

The real challenge is:

What happens when multiple threads access shared data at the same time?

For example:

We have a variable:

int count = 0;

100 threads execute:

count++;

According to our expectation:

The final result should be:

However, the actual result may be:

98
99

or even lower.

Why?

Because:

count++ is not a single operation.

It actually contains three steps:

Read count.
Increment the value.
Write the new value back.

Suppose two threads execute simultaneously:

Thread A reads:

count = 0

Thread B also reads:

count = 0

Then:

Thread A calculates:

0 + 1 = 1

Thread B calculates:

0 + 1 = 1

Finally, both write:

count = 1

One update is lost.

This is the first core problem in concurrency:

Atomicity

Atomicity means:

An operation should either completely execute or not execute at all.

It should not be interrupted halfway by another thread.

3. Visibility Problem

Besides atomicity, there is another issue:

Visibility

What does visibility mean?

Suppose:

Thread A modifies a variable.

When will Thread B see this modification?

Many people assume:

Once Thread A changes the value, Thread B immediately sees it.

But this is not always true.

To improve performance, modern CPUs use caches.

Threads may read values from their own CPU cache.

Therefore:

Thread A has already updated the value.

But Thread B still sees the old value.

This is the visibility problem.

4. Ordering Problem

The third problem is:

Instruction Ordering

When we write code:

a = 1;
b = 2;

We naturally assume execution happens from top to bottom.

However, for performance optimization:

The compiler.
The CPU.

may reorder instructions.

If there are no dependencies between instructions, usually there is no problem.

But when dependencies exist, reordering may cause unexpected behavior.

This is the ordering problem.

Therefore, Java concurrency has three fundamental problems:

The Three Core Problems

Atomicity.
Visibility.
Ordering.

5. How Do We Solve Concurrency Problems?

After understanding the problems, let's look at solutions.

volatile

volatile mainly solves:

Visibility.
Ordering.

For example:

When one thread modifies a variable, other threads can immediately see the latest value.

However:

volatile does not guarantee atomicity.

For example:

count++;

Even with volatile, this operation is still not thread-safe.

synchronized

synchronized is the most commonly used lock mechanism in Java.

It solves:

Atomicity.
Visibility.
Ordering.

The simple idea:

Only one thread can enter the synchronized section at the same time.

For example:

Multiple threads modify an account balance.

With locking:

Thread A
   |
   v
Update balance

Thread B waits

Thread B
   |
   v
Update balance

Although performance is reduced slightly, data correctness is guaranteed.

ReentrantLock

ReentrantLock is another locking mechanism.

Compared with synchronized, it provides more advanced features:

Try acquiring a lock.
Timeout when waiting for a lock.
Interruptible lock acquisition.

However, another question appears:

When multiple threads compete for the same lock:

How do they wait and queue?

This leads us to:

AQS (AbstractQueuedSynchronizer)

AQS is the core foundation behind many Java synchronization tools.

It maintains a waiting queue.

Threads that fail to acquire a lock do not continuously consume CPU resources.

Instead:

They enter the waiting queue.

When the lock is released:

The next waiting thread is awakened.

This is the core design idea behind Java locks.

CAS (Compare And Swap)

Besides locks, another approach is:

CAS

The idea is:

Before modifying data:

First compare whether the current value is the expected value.

If yes:

Modify directly.

If no:

Someone else has modified the data.

Retry.

Java classes such as:

AtomicInteger
AtomicReference

use CAS internally.

Advantages:

High performance.
Lock-free design.

Disadvantages:

Under heavy contention, repeated retries may occur.

6. How Do Threads Cooperate?

After solving thread safety issues, another question appears:

How do multiple threads cooperate to complete tasks?

Thread cooperation mainly includes several scenarios.

Why Do Threads Need to Wait?

Example:

A consumer thread.

If there are no messages:

Should it continuously check?

Like:

while(true){
    checkMessage();
}

This wastes CPU.

A better approach:

The thread enters a waiting state.

When messages arrive:

It gets awakened.

Related mechanisms:

sleep

Meaning:

"I will pause for a certain amount of time."

wait

Meaning:

"I am waiting for a specific condition."

park

A lower-level thread blocking mechanism.

How Do Threads Communicate?

A simple approach:

Shared variables.

For example:

A volatile variable.

One thread updates the state.

Another thread reads the state.

Another mechanism:

wait() and notify().

One thread waits.

Another thread sends notification.

In real-world development, concurrent utilities are more commonly used.

CountDownLatch

Scenario:

One thread waits for multiple threads to finish.

Example:

System startup:

Database initialization.
Cache initialization.
Message queue initialization.

Only after all complete:

The system starts.

CyclicBarrier

Scenario:

Multiple threads wait for each other.

Example:

A competition.

All participants finish preparation.

Then:

The competition starts.

Semaphore

Scenario:

Limit resource access.

Example:

Database connection pool.

Maximum:

100 connections

Extra requests must wait.

7. How Do Multiple Threads Complete Complex Tasks?

Modern systems often require multiple asynchronous operations.

Example:

Product detail page.

Need:

Product information.
Inventory information.
Promotion information.
User information.

These can be queried in parallel.

Then combine results.

Technologies:

Callable.
Future.
FutureTask.
CompletableFuture.

CompletableFuture supports:

Parallel execution.
Task dependency.
Result combination.
Exception handling.

8. How Should Threads Be Stopped?

Threads eventually need to finish.

Previously Java provided:

Thread.stop()

However, this approach is unsafe.

Because it may cause:

Locks not being released.
Data not being saved.

The recommended approach today:

interrupt()

interrupt() does not forcibly kill a thread.

Instead:

It sends a stop signal.

The thread decides when and how to exit safely.

This is called:

Graceful Shutdown

9. Too Many Threads: What Happens?

If every request creates a new thread:

What problems appear?

Threads are not free.

Creating threads requires:

Memory.
CPU scheduling.
Context switching.

Too many threads may actually reduce performance.

Therefore:

We need:

Thread Pool

A thread pool is responsible for:

Creating threads.
Managing thread lifecycle.
Reusing threads.

The core class:

ThreadPoolExecutor

It manages:

Core thread number.
Maximum thread number.
Task queue.
Rejection policy.

10. Concurrent Collections

Normal collections:

HashMap.
ArrayList.

are not thread-safe.

Java provides:

ConcurrentHashMap

It uses:

CAS.
Lock mechanisms.

to achieve high-performance concurrent access.

CopyOnWriteArrayList

Suitable for:

Read-heavy, write-light scenarios.

11. Why Do Threads Get Stuck?

The final question:

Why can threads stop making progress?

The classic problem:

Deadlock

Example:

Thread A:

Lock 1 acquired

Waiting for Lock 2

Thread B:

Lock 2 acquired

Waiting for Lock 1

Both wait forever.

Nobody can continue.

This is deadlock.

How to Avoid Deadlocks

Common approaches:

Use consistent lock ordering.
Reduce lock scope.
Avoid nested locks.
Use timeout-based lock acquisition.

Summary

Learning Java concurrency should not start from:

Thread.
Lock.
ConcurrentHashMap.

The correct learning path is:

Why do we need concurrency?
        ↓
How do threads execute?
        ↓
Why do multiple threads cause problems?
        ↓
Atomicity, Visibility, Ordering
        ↓
How to guarantee thread safety?
        ↓
volatile, synchronized, CAS, AQS
        ↓
How do threads wait and communicate?
        ↓
How do threads cooperate?
        ↓
How to stop threads safely?
        ↓
How thread pools manage execution?
        ↓
Concurrent collections and asynchronous programming

The real purpose of concurrency programming is:

When multiple execution flows run simultaneously, how do we guarantee correctness while improving system performance?

This is the concurrency mindset that a senior Java engineer truly needs to understand.

GitHub:
github.com/markliu2013/...

MVCC Concept: The No-Lock Approach for High-Concurrency Systems

Mark — Sat, 14 Feb 2026 06:57:41 +0000

In high-concurrency systems, traditional locking mechanisms often become performance bottlenecks. MVCC (Multi-Version Concurrency Control) provides a way to minimize locks or avoid them entirely. By using a “versioning + snapshot” approach, MVCC allows high-concurrency access while ensuring transaction isolation and data consistency. This article explains MVCC from its principles, essence, design philosophy, and practical insights for developers, so you can not only understand it but also apply its ideas in high-concurrency system design.

1. What is MVCC

MVCC (Multi-Version Concurrency Control) is a concurrency control mechanism with the core idea:

Instead of directly overwriting existing data, each write operation creates a new version. Each transaction works with its own snapshot of the data and determines which versions are visible based on version IDs, allowing reads and writes to proceed without blocking each other.

In MySQL InnoDB, MVCC supports:

Snapshot Read: Reads historical versions without locking
Current Read: Reads the latest version with locks, e.g., SELECT … FOR UPDATE

With this mechanism, read operations do not block write operations, and write operations do not unnecessarily block reads, greatly improving concurrency.

2. How MVCC Works

(1) Version Information and Undo Log

Each row in InnoDB contains hidden metadata:

trx_id: The transaction ID that last modified this row
roll_pointer: Points to the Undo log for retrieving previous versions

When a transaction reads data, InnoDB determines the visible version according to the transaction ID.

(2) Visibility Rules

The rules for determining whether a row is visible to a transaction:

If row.trx_id < current transaction ID and the corresponding transaction has committed → visible
If row.trx_id ≥ current transaction ID → not visible
Rows modified by the current transaction are always visible

(3) Undo Log and Snapshot Read

Undo logs store historical versions
Snapshot reads retrieve the correct version from the undo logs according to the transaction snapshot
Supports consistent reads without locking historical data

(4) Transaction Isolation Levels and MVCC

REPEATABLE READ: Default in InnoDB; ensures consistency within a transaction and prevents phantom reads using MVCC
READ COMMITTED: Reads the latest committed data each time
SERIALIZABLE: Reads acquire locks, limiting the effect of MVCC

3. The Essence of MVCC

At its core, MVCC can be summarized as:

Using multiple versions of data to enable snapshot reads and transaction isolation, improving concurrency while maintaining consistency.

Key points:

Multiple versions: Every modification creates a new version, preserving history
Transaction snapshots: Each transaction sees its own consistent view
Minimized locking: Reads are mostly lock-free, and writes only lock when necessary

4. The Philosophy of MVCC

From MVCC, we can extract several design principles for high-concurrency systems:

1. Minimize dependency on locks

Reads and writes do not block each other; locks are used only when necessary

2. Versioning and Snapshot Reads

Each transaction sees its own view
Reading older versions reduces lock contention

3. Consistency over immediate mutual exclusion

Not all operations need to be synchronized in real-time
Use snapshots and versioning to determine visibility

4. Practical development principles

High concurrency is not about adding more locks, but using versioning, snapshots, and asynchronous processing to avoid blocking
Applicable to caches, queues, distributed systems, and microservices

5. Insights for Developers

1. Read-write separation: Use caches or read replicas to reduce lock contention

2. Versioned operations: Optimistic locking, historical records, soft deletes

3. Asynchronous processing: Handle non-critical writes asynchronously

4. Snapshot awareness: Use snapshot data for analytics, pagination, or reporting to reduce blocking

5. System design mindset: High concurrency is achieved through design, not by adding locks

Conclusion

MVCC is not just a database implementation—it is a design philosophy for high-concurrency systems:

It aims to minimize locks by using versioning, snapshots, and visibility rules, allowing operations to proceed without blocking while ensuring data consistency. What we should truly learn from this is the underlying mindset—and apply it to our development practices. For example:

- Caching and read replicas: Serve read requests from cache or replicas to reduce lock contention on the main database.

- Optimistic concurrency control: Use version numbers or timestamps to handle updates without locking resources.

- Asynchronous processing: Queue non-critical writes or long-running operations to avoid blocking user requests.

- Snapshot-based analytics or reporting: Perform statistical queries or pagination on a snapshot to prevent interference with real-time writes.

- Distributed systems and microservices: Design state management so that each service can work with its own consistent view, reducing cross-service blocking.

In short, the MVCC mindset is about designing systems so that operations can proceed concurrently as much as possible, without relying on locks, while still maintaining consistency.

How to Contribute to Open Source Projects

Mark — Fri, 26 Jul 2024 05:05:17 +0000

Recently, I have made a contribution to material-ui, a very popular React UI component library.

I picked up the task from this issue, this is my merged pull request.

In this article, I would like to share the basic steps about contributing to open source projects for beginners.

Fork the repository, you should fork all branches.

Clone the fork to your local machine and add the upstream remote

git clone https://github.com/<your username>/material-ui.git
cd material-ui
git remote add upstream https://github.com/mui/material-ui.git

Synchronize your local next branch with the upstream one:

git checkout next
git pull upstream next

Install the dependencies with pnpm (yarn or npm aren't supported):

pnpm install

You can run the project on your local machine

npm run start

Now you can get familiar with the project structure, it use monorepo to manage many projects in a single code repository. You can check out my series, Building a Vue 3 Component Library from Scratch, if you are getting fear about this big project.

The next step is to pick up a task that you can handle, https://github.com/mui/material-ui/issues

Before you pick up your first issue, You should read this https://github.com/mui/material-ui/blob/next/CONTRIBUTING.md#your-first-pull-request

For me, I picked a task from this issue.

Before you change the code, Create a new topic branch with meaningful name.

git checkout -b react-complier-mui-utils

Make changes, commit, and push to your fork:

git push -u origin HEAD

You can learn the pull request witch fix similar issues merged successfully, checkout how they changed the code.

For me, I refer to this pull request, it just add some comment code in File Changes, so I try to add some comment for the files too.

After pushing your code, you can see pull request button, click it and write your own pull request.

After submitting pull request, the project maintainer will review your code, sometimes they will give you suggestion to make your changes better, you will learn a lot here. When everything is ok, they will merge it.

Throttling and Debouncing in JavaScript

Mark — Sun, 21 Jul 2024 09:45:11 +0000

Throttling and Debouncing is involved where high-frequency events are triggered, such as resize, scroll, input, etc. The core idea of debounce and throttle is to add a control layer between events and functions to delay execution. The goal is to prevent frequent execution of certain operations within a certain period of time, which would lead to a waste of resources.

The control layer between events and functions is usually implemented in two ways:

Using a timer. Each time an event is triggered, it is determined whether there is already a timer.
Using timestamp difference. Record the timestamp of the last event trigger, each time an event is triggered, determine whether the difference (delay - (now - previous)) between the current timestamp and the last execution timestamp has reached the set delay time.

Debouncing

Definition

Debouncing is the process of executing a callback function after an event is triggered for a specified time. If the event is triggered again within the specified time, the timer is reset according to the last trigger.

When an event is continuously triggered, the event handling function will only execute once if no event is triggered within a certain period. If an event is triggered again before the set time arrives, the delay is restarted. As shown in the following figure, the handle function is not executed when the scroll event is continuously triggered. Only when no scroll event is triggered within 1000 milliseconds, the scroll event will be delayed and triggered.

Example - Autocomplete Input

Unoptimized Implementation

Search box suggestion prompts: When we input character, we may request data from an API. If there is no optimization, the API will be continuously triggered from the start of the input, which will inevitably lead to resource wastage. It's also not wise to frequently change the DOM element in html tree.

// Bad code 
<html>   
    <body>     
        <div> search: <input id="search" type="text"> </div>   
        <script>
            const searchInput = document.getElementById("search"); 
            searchInput.addEventListener('input', ajax);       
            function ajax(e) { 
                // mock         
                console.log(`Search data: ${e.target.value}`);       
            }     
        </script>   
   </body> 
</html>

In the above code, we don't have any optimization. We use the ajax() method to simulate data requests. Let's see the result.

If a real API is being called, it would continuously hit the server-side interface from the moment of input. It could also easily trigger rate limiting measures of the API. For example, the API provided by Github has a maximum request limit per hour.

Debounce Optimization

The principle is to use a marker to determine whether there are multiple calls within a specified time. When there are multiple calls, the previous timer is cleared and the timing starts again. If there is no further call within the specified time, the passed-in callback function (fn) is executed.

function debounce(fn, ms) {   
    let timerId;    
    return (...args) => {
        if (timerId) {       
            clearTimeout(timerId);     
        }    

        timerId = setTimeout(() => {       
            fn(...args);     
        }, ms);   
    } 
}

Usage

const handleSearchRequest = debounce(ajax, 500)  
searchInput.addEventListener('input', handleSearchRequest);

This is much better. When users input stops, it takes the last input text as the data param to request the API, avoiding request too many times.

Throttling

Throttling is the execution of a callback function at a specified interval after an event is triggered.

When an event is continuously triggered, it ensures that the event handling function is called only once within a certain time period. A common analogy for throttling is like water flowing from a faucet. When the valve is opened, water flows down rapidly. In the spirit of frugality, we want to reduce the flow from the faucet, ideally letting it drip down at a certain interval according to our wishes. For example, when a scroll event is continuously triggered, the handle function is not executed immediately, but rather every 1000 milliseconds.

Example - Scroll to The Top

The page has many list items, and after scrolling down, we hope a 'Top' button appears that can take us back to the top when clicked. At this point, we need to get the distance from the scroll position to the top to determine whether to display the 'Top' button.

Unoptimized Implementation

<body>   
    <div id="container"></div>   
    <script>     
        const container = document.getElementById('container');
        window.addEventListener('scroll', handleScrollTop);
        function handleScrollTop() {       
            console.log('scrollTop: ', document.body.scrollTop);       
            if (document.body.scrollTop > 400) { 
                // Handler to show top button       
            } else {      
                // Handler to hide top button
            }     
        }   
    </script> 
</body>

As we can see, without any optimization, a single scroll might trigger hundreds of times, and processing each one is evidently a waste of performance.

Throttling Optimization

Implement a simple throttle function, is very similar to debounce. The difference is that here we use a flag to determine whether it has been triggered. Once it has been triggered, incoming requests are directly terminated until the previous specified interval has elapsed and the callback function has been executed, then it accepts the next process.

function throttle(fn, ms) { 
    let flag = false;   
    return (...args) => {   
        if (flag) return;    
        flag = true;     
        setTimeout(() => {  
            fn(...args)      
            flag = false;  
        }, ms);   
    } 
}

Usage

const handleScrollTop = throttle(() => {  
    console.log('scrollTop: ', document.body.scrollTop);  
        // todo: 
}, 500); 
window.addEventListener('scroll', handleScrollTop);

This one is much better with the above one.

Two Ways to Implement Throttling: Timestamps and Timers

Timestamp

var throttle = function(func, delay) {            
　　var prev = Date.now();            
　　return function() {                
　　　　var context = this;                
　　　　var args = arguments;                
　　　　var now = Date.now();                
　　　　if (now - prev >= delay) {                    
　　　　　　func.apply(context, args);                    
　　　　　　prev = Date.now();                
　　　　}            
　　}        
}        
function handle() {            
　　console.log(Math.random());        
}        
window.addEventListener('scroll', throttle(handle, 1000));

Timers

var throttle = function(func, delay) {            
    var timer = null;            
    return function() {                
        var context = this;               
        var args = arguments;                
        if (!timer) {                    
            timer = setTimeout(function() {                        
                func.apply(context, args);                        
                timer = null;                    
            }, delay);                
        }            
    }        
}        
function handle() {            
    console.log(Math.random());        
}        
window.addEventListener('scroll', throttle(handle, 1000));

Summary

Function Debounce: Combines multiple operations into a single operation. The principle is to maintain a timer, which triggers the function after a delay time. However, if it is triggered again within the delay time, the previous timer will be cancelled and reset. In this way, only the last operation can be triggered.

Window Resize Event, It is used when window size adaptation is needed. In this case, debounce is generally used because only the last change needs to be considered.
Search Input Event, If the input interval is greater than a certain value (such as 500ms), it is considered that the user has finished inputting and then starts searching.

Function Throttle: Ensures that a function is only triggered once within a certain period. The principle is to trigger the function by determining whether a certain time has been reached.

Scroll to Top
Search Input Event, for example, to implement real-time search input, throttle can be used.

Difference: Function throttling ensures that no matter how frequently the event is triggered, the actual event handling function will be executed once within a specified time, while function debounce only triggers a function after the last event. For example, in the scenario of infinite page scroll loading, we need the user to send an Ajax request every once in a while when scrolling the page, instead of requesting data only when the user stops scrolling. This scenario is suitable for the use of throttling technology.

My CSS Units Best Practices

Mark — Wed, 17 Jul 2024 16:44:20 +0000

There are many units in CSS, such as %, px, em, rem, vw, vh, etc. Each unit has a specific usage.

How to pick which css units to use in different circumstance, in this article I am going to talk about the best generalizations.

Before we dive in, I want you to remember this is just rule of thumb, It is just for helping you choose which unit in different situation.

Width

In the most situation, % in combination with a max-width is the best choose.

.container {
  width: 50%;
  max-width: 1000px
}

Height

In the most situation, you don't need set fixed height, use min-height instead.

Padding and Margin

In the most situation, use rem or em.

If your padding and margin is consistent use rem, if it is base on font size use em.

For example, we always use em for button padding, it will grow and adjust along with font size.

.btn {
  display: inline-block;
  text-decoration: none;
  background: #000;
  color: #fff;
  padding: 1em;
  font-size: 2rem;
}

If you change font-size bigger, the padding will grow too.

Media Query

We use em for media query break point, check out this article for detail, https://zellwk.com/blog/media-query-units/

Other Rules

px only for little things like shadows, borders etc.

This article is based on this youtube video.
https://www.youtube.com/watch?v=N5wpD9Ov_To

Top 6 React Hook Mistakes Beginners Make

Mark — Sun, 14 Jul 2024 16:46:04 +0000

The hardest part about learning react is not actually learning how to use react but instead learning how to write good clean react code.

In this article, I will talk about 6 mistakes that I see almost everyone making with the useState and useEffect hook.

Mistake 1, Using state when you don't need it

The very first mistake that I want to talk about is using state when you don't actually need any state.

Let's take a look at this example.

import {useState} from "react";

const App = () => {

  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')

  function onSubmit(e) {
    e.preventDefault();
    console.log({ email, password });
  }

  return (
      <form onSubmit={onSubmit}>
        <label htmlFor="email">Email</label>
        <input
            value={email}
            onChange={e => setEmail(e.target.value)}
            type="email"
            id="email"
        />
        <label htmlFor="password">Password</label>
        <input
            value={password}
            onChange={e => setPassword(e.target.value)}
            type="password"
            id="password"
        />
        <button type="submit">Submit</button>
      </form>
  )

};

export default App;

We use email and password state here, but the problem is we only care the email and password value when submit the form, we don't need re-render when email and password updated, so instead of tracking the state, and re-render every time I typed a character, I am going to store these inside of a ref.

import { useRef } from "react";

const App = () => {

  const emailRef = useRef();
  const passwordRef = useRef();

  function onSubmit(e) {
    e.preventDefault();
    console.log({
      email: emailRef.current.value,
      password: passwordRef.current.value
    });
  }

  return (
      <form onSubmit={onSubmit}>
        <label htmlFor="email">Email</label>
        <input
            ref={emailRef}
            type="email"
            id="email"
        />
        <label htmlFor="password">Password</label>
        <input
            ref={passwordRef}
            type="password"
            id="password"
        />
        <button type="submit">Submit</button>
      </form>
  )

};

export default App;

If you click the submit, and look at the console again, it will print the values. You don't need any state at all for this.

So the first tip for you is thinking do you really need to use states, and re-render the components every time state changes, or can you use a ref if you don't need re-render the components.

Also you can access the data in the form directly, so you don't need refs too.

import { useRef } from "react";

const App = () => {

    function onSubmit(event) {
        event.preventDefault();
        const data = new FormData(event.target);
        console.log(data.get('email'));
        console.log(data.get('password'));
        fetch('/api/form-submit-url', {
            method: 'POST',
            body: data,
        });
    }

    return (
        <form onSubmit={onSubmit}>
            <label htmlFor="email">Email</label>
            <input
                type="email"
                name="email"
                id="email"
            />
            <label htmlFor="password">Password</label>
            <input
                type="password"
                name="password"
                id="password"
            />
            <button type="submit">Submit</button>
        </form>
    )

};

export default App;

Mistake 2, Not using the function version of useState

Let's take a look at this example.

import { useState } from "react";

export function Counter() {

    const [count, setCount] = useState(0);

    function adjustCount(amount) {
        setCount(count + amount);
        setCount(count + amount);
    }

    return (
        <>
            <button onClick={ () => adjustCount(-1) }> - </button>
            <span> {count} </span>
            <button onClick={ () => adjustCount(1) }> + </button>
        </>
    )
}

If you click the button, the count will update only once, even you setCount twice. This is because when the second setCount trigger, the first setCount not finished, the count value is not updated.

You should use function version to fix this problem.

https://legacy.reactjs.org/docs/hooks-reference.html#functional-updates

import { useState } from "react";

export function Counter() {

    const [count, setCount] = useState(0);

    function adjustCount(amount) {
        setCount(prevCount => prevCount + amount);
        setCount(prevCount => prevCount + amount);
    }

    return (
        <>
            <button onClick={ () => adjustCount(-1) }> - </button>
            <span> {count} </span>
            <button onClick={ () => adjustCount(1) }> + </button>
        </>
    )

}

Mistake 3, State dose not update immediately

Let's take a look at this example.

import { useState } from "react";

export function Counter() {

    const [count, setCount] = useState(0);

    function adjustCount(amount) {
        setCount(prevCount => prevCount + amount);
        // count is the value before setCount
        console.log(count);
    }

    return (
        <>
            <button onClick={ () => adjustCount(-1) }> - </button>
            <span> {count} </span>
            <button onClick={ () => adjustCount(1) }> + </button>
        </>
    )
}

When you update your state variable, it actually doesn't change right away, it doesn't change until next render, so instead of putting code after your state setter, you should use useEffect.

import {useEffect, useState} from "react";

export function Counter() {

    const [count, setCount] = useState(0);

    useEffect(() => {
        console.log(count);
    }, [count])

    function adjustCount(amount) {
        setCount(prevCount => prevCount + amount);
    }

    return (
        <>
            <button onClick={ () => adjustCount(-1) }> - </button>
            <span> {count} </span>
            <button onClick={ () => adjustCount(1) }> + </button>
        </>
    )

}

Mistake 4, Unnecessary useEffect

Let's take a look at this example.

import { useEffect, useState } from "react";

const App = () => {

    const [firstName, setFirstName] = useState('')
    const [lastName, setLastName] = useState('')
    const [fullName, setFullName] = useState('')

    useEffect(() => {
        setFullName(`${firstName} ${lastName}`);
    }, [firstName, lastName])

    return (
        <>
            <input value={firstName} onChange={ e => setFirstName(e.target.value) } />
            <input value={lastName} onChange={ e => setLastName(e.target.value) } />
            {fullName}
        </>
    )

};

export default App;

The problem is when we update firstName or lastName, the state fullName will update and re-render component again, it re-render twice.

How to make it to be optimal.

import { useState } from "react";

const App = () => {

    const [firstName, setFirstName] = useState('');
    const [lastName, setLastName] = useState('');

    const fullName = `${firstName} ${lastName}`;

    return (
        <>
            <input value={firstName} onChange={ e => setFirstName(e.target.value) } />
            <input value={lastName} onChange={ e => setLastName(e.target.value) } />
            {fullName}
        </>
    )

};

export default App;

Mistake 5, Referential equality mistakes

Let's take a look at this example.

import {useEffect, useState} from "react";

const App = () => {

    const [age, setAge] = useState(0);
    const [name, setName] = useState('');
    const [darkMode, setDarkMode] = useState(false);

    const person = { age, name };

    useEffect(() => {
        console.log(person)
    }, [person])

    return (
        <div style={{ background: darkMode ? "#333" : "#fff" }}>
            Age: {" "}
            <input value={age} type="number" onChange={ e => setAge(e.target.value)} />
            <br/>
            Name: <input value={name} onChange={ e => setName(e.target.value) } />
            <br/>
            Dark Mode: {" "}
            <input type="checkbox" value={darkMode} onChange={e => setDarkMode(e.target.checked)} />
        </div>
    )
};

export default App;

If you change age or name, useEffect function will be triggered, but if you toggle darkMode, the useEffect function triggered too, this is not what we expected.

There are two key point make this happen.

Firstly, Each render has its own props and state, so the variable person will be initialize as a new one. Checkout this article, if you want to study this in detail, https://overreacted.io/a-complete-guide-to-useeffect/

The second point is Referential equality, https://barker.codes/blog/referential-equality-in-javascript/
so the variable person is not equal when darkMode updated.

We can use useMemo to fix this problem.

import {useEffect, useMemo, useState} from "react";

const App = () => {

    const [age, setAge] = useState(0);
    const [name, setName] = useState('');
    const [darkMode, setDarkMode] = useState(false);

    const person = useMemo(() => {
        return { age, name }
    }, [age, name])

    useEffect(() => {
        console.log(person)
    }, [person])

    return (
        <div style={{ background: darkMode ? "#333" : "#fff" }}>
            Age: {" "}
            <input value={age} type="number" onChange={ e => setAge(e.target.value)} />
            <br/>
            Name: <input value={name} onChange={ e => setName(e.target.value) } />
            <br/>
            Dark Mode: {" "}
            <input type="checkbox" value={darkMode} onChange={e => setDarkMode(e.target.checked)} />
        </div>
    )
};

export default App;

Please note, you can use React Compiler instead of useMemo in React 19 version.

Mistake 6, Not aborting fetch requests

Let's take a look at this example.

import {useEffect, useState} from "react";

export function useFetch(url) {

    const [loading, setLoading] = useState(true);
    const [data, setData] = useState();
    const [error, setError] = useState();

    useEffect(() => {
        setLoading(true)
        fetch(url)
            .then(setData)
            .catch(setError)
            .finally(() => setLoading(false))
    }, [url])

}

The problem in this example is when the component unmounted, or url changed, the previous fetch still working in the background, it will work not as expect in many situation, checkout out this article in detail, https://plainenglish.io/community/how-to-cancel-fetch-and-axios-requests-in-react-useeffect-hook

We can fix this problem using AbortController.

import {useEffect, useState} from "react";

export function useFetch(url) {

    const [loading, setLoading] = useState(true);
    const [data, setData] = useState();
    const [error, setError] = useState();

    useEffect(() => {
        const controller = new AbortController();
        setLoading(true)
        fetch(url, { signal: controller.signal })
            .then(setData)
            .catch(setError)
            .finally(() => setLoading(false))

        return () => {
            controller.abort();
        }

    }, [url])

}

This article is based on this youtube video. https://www.youtube.com/watch?v=GGo3MVBFr1A

Install and Set Up Kubernetes on Linux

Mark — Sat, 29 Jun 2024 13:58:01 +0000

This article is about setting up kubernetes use kubeadm.

Prerequisites

Prepare two or more servers running Linux in the same network.

Set Hostname

sudo hostnamectl set-hostname k8-smaster
sudo hostnamectl set-hostname k8-node1
sudo hostnamectl set-hostname k8-node2

vim /etc/hosts

192.168.x.x k8-smaster
192.168.x.x k8-node1
192.168.x.x k8-node2

Disable Selinux

Check

[root@dev-server ~]# getenforce
Disabled
[root@dev-server ~]# /usr/sbin/sestatus -v
SELinux status:                 disabled

Temporarily Closed

##Set SELinux to permissive mode
##setenforce 1 sets SELinux to enforcing mode
setenforce 0

Permanently Disable

vi /etc/selinux/config

Change SELINUX=enforcing to SELINUX=disabled. The setting will take effect after a restart.

Swap Off

Check

free -m

Temporarily Closed

swapoff -a

Permanently Disable

sed -ri 's/.*swap.*/#&/' /etc/fstab

Disable Firewall

systemctl status firewalld
systemctl stop firewalld
systemctl disable firewalld
chkconfig iptables off
sudo iptables -F
sudo iptables -X
sudo iptables -L

Enable IPv4 packet forwarding

https://kubernetes.io/docs/setup/production-environment/container-runtimes/

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

Install Docker

https://docs.docker.com/engine/install/centos/

Install CRI

wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.14/cri-dockerd-0.3.14.amd64.tgz
tar xvf cri-dockerd-0.3.14.amd64.tgz
mv ./cri-dockerd/* /usr/local/bin/

wget https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd/cri-docker.service
wget https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd/cri-docker.socket
sudo mv cri-docker.socket cri-docker.service /etc/systemd/system/
sudo sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service

systemctl daemon-reload
systemctl enable cri-docker.service
systemctl enable --now cri-docker.socket

systemctl status cri-docker.socket

Installing kubeadm, kubelet and kubectl

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

kubeadm config images pull --cri-socket unix:///var/run/cri-dockerd.sock
kubeadm version

Init Master Node

kubeadm init \
--apiserver-advertise-address=192.168.116.133 \
--control-plane-endpoint=k8smaster \
--kubernetes-version=v1.30.2 \
--service-cidr=10.96.0.0/16 \
--pod-network-cidr=192.168.0.0/16 \
--cri-socket=unix:///var/run/cri-dockerd.sock

Join Node into Master

kubeadm join k8smaster:6443 --token cgdl45.0c8wq1z9pxez59jr \
        --discovery-token-ca-cert-hash sha256:2fabc33e8c57c01f3214cf69dff97acc54ad6dd727f1255143bf310c4b40e2cb --cri-socket=unix:///var/run/cri-dockerd.sock

Next step, install canal and dashboard.

How to Read a JSON File in JavaScript

Mark — Tue, 11 Jun 2024 15:37:12 +0000

When you need to read a json file in your project, it is easy to get the idea using fetch or axios.

For example, we have data.json.

{
    "name": "Hello World",
    "age": 18
}

Use fetch to read.

fetch('https://server.com/data.json')
    .then((response) => response.json())
    .then((json) => console.log(json));

It works when your project is running in web browser environment, but when your project is running in hybrid environment, it is file protocol instead of http protocol. You will get cors error.

You can use script tag to fix this problem.

Change data.json to data.js

window.config = {
    "name": "Hello World",
    "age": 18
}

Add script tag in your html file template.

<!--      <script src="./data.js"> </script>-->
      <script>
          document.write('<script src="./data.js?t=' + new Date().getTime() + '"><\/script>')
      </script>

Now you can read data from window object in your javascript code.

const data = window.config
console.log(data)

Vite - Code Splitting Strategy

Mark — Tue, 11 Jun 2024 07:21:06 +0000

The Problem Solved by Code Splitting

Firstly, let's look at the problems with the traditional single chunk packaging mode:

Can not import on demand

All the code is bundled into one chunk, which means that the code needed for page initialization and the code for the route components are all bundled together.

Can not use network cache

Normally, the name of a chunk is generated based on the hash value of the file content. Therefore, every time the code is modified, the name of the chunk changes, which prevents the browser from using the local cache.

Code splitting is aimed at resolving these issues to enhance page load performance.

Vite's Default Chunk Splitting Strategy

Before version 2.9

One chunk corresponds to one CSS file.
Logic code will be packaged into one chunk.
Third-party dependencies are packaged into one chunk.

After version 2.9

The changed place is that both the third-party packages and the business code are now in one chunk.

If you want to control the code splitting strategy with a finer granularity, you need to use the manualChunks configuration. The config is approximately as follows:

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        /**
         * 1. Use in object form
         * Package the lodash module into a chunk, named lodash
         */
         manualChunks: {
           lodash: ['lodash'],
         },

        /**
         * 2. Use in function form
         * Package all third-party packages into one chunk, named vendor
         */
        manualChunks(id, { getModuleInfo, getModuleIds }) {
          if (id.includes('node_modules')) {
            return 'vendor';
          }
        },
      },
    },
  },
});

Multiple HTML Files Using Webpack

Mark — Mon, 10 Jun 2024 09:13:36 +0000

Frameworks like React and Vue are single-page applications, which means generating a single HTML file with all JS referenced and executed within this page.

In this article, we're going to discuss how to package multi-page application in webpack, that is, generating multiple HTML files during the packaging process, because there might still be scenarios where multi-page applications are used in some older project.

We will use the html-webpack-plugin to achieve this.

Let's Write Some Code

Besides the entry file index.js, we will create two more files: list.js and detail.js. We will use these three as the files to be bundled.



// index.js
import React, { Component } from 'react';
import { createRoot } from 'react-dom/client';
class App extends Component {
    render() {
        return <div>Index Page</div>;
    }
}
const root = createRoot(document.getElementById('app'));
root.render(React.createElement(App));

// list.js
import React, { Component } from 'react';
import { createRoot } from 'react-dom/client';
class App extends Component {
    render() {
        return <div>List Page</div>;
    }
}
const root = createRoot(document.getElementById('app'));
root.render(React.createElement(App));

// details.js
import React, { Component } from 'react';
import { createRoot } from 'react-dom/client';
class App extends Component {
    render() {
        return <div>Details Page</div>;
    }
}
const root = createRoot(document.getElementById('app'));
root.render(React.createElement(App));

Now we have three pages, and I want to generate three HTML pages: index.html, list.html, and details.html. How should we configure this?

Configuring Multiple Entries

Now that we have three js files, we need to configure three entry points:



...

module.exports = {
  entry: {
    main: "./src/index.js",
    list: "./src/list.js",
    details: "./src/details.js",
  },
  output: {
    clean: true,
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].chunk.js'
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: 'src/index.html', // to import index.html file inside index.js
      filename: 'index.html',
    })
  ],
optimization: {
    usedExports: true,
    runtimeChunk: {
      name: 'runtime',
    },
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          name: 'vendors',
        }
      }
    },
  ...
}

...

After running 'npm run build', we can see that it has bundled details..js and list..js:

However, there is only one HTML file, and this HTML page includes all the js files we have bundled.

This is not the result we want. What we want is to include index.js in index.html, list.js in list.html, and details.js in details.html.

In this case, we need to use html-webpack-plugin to help us generate several more pages, and include the corresponding js files or chunks.

Configuring html-webpack-plugin

To generate multiple HTML files, we still need to use the handy tool html-webpack-plugin. It has many parameters that you can refer to in the official html-webpack-plugin documentation. Here, we will use the 'filename' and 'chunks' parameters, which correspond to the names of the generated HTML files and the chunks to be included in the page, respectively. We modify the webpack.config.js configuration and add two more instances of html-webpack-plugin:



...

module.exports = {
  entry: {
    main: "./src/index.js",
    list: "./src/list.js",
    details: "./src/details.js",
  },
  ...
  plugins: [
    ...
    new HtmlWebpackPlugin({
      template: 'src/index.html',
      filename: 'index.html',
      chunks: ['runtime', 'vendors', 'main'],
    }),
    new HtmlWebpackPlugin({
      template: 'src/index.html',
      filename: 'list.html',
      chunks: ['runtime', 'vendors', 'list'],
    }),
    new HtmlWebpackPlugin({
      template: 'src/index.html',
      filename: 'details.html',
      chunks: ['runtime', 'vendors', 'details'],
    }),
    ...
  ],
  optimization: {
    usedExports: true,
    runtimeChunk: {
        name: 'runtime',
    },
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          name: 'vendors',
        }
      }
    },
  },
}

...

The 'chunks' configuration in HtmlWebpackPlugin refers to the JavaScript files, which are included into the HTML after being bundled by webpack.

Let's re-package it by running 'npm run build'. Three HTML files are generated in the 'dist' directory, and each HTML file includes the corresponding JavaScript:

index.html

list.html

details.html

Everything has been successfully bundled. When we open each page, they all run normally.

Configuration Optimization

If we add a new entry point, we need to manually add another html-webpack-plugin and set the corresponding parameters.

How do we automatically add a new html-webpack-plugin based on the entry point, let's just do it.

We can assemble the html-webpack-plugin based on the entry file:



const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

const entry = {
  main: "./src/index.js",
  list: "./src/list.js",
  detail: "./src/detail.js",
}

module.exports = {
...
  entry: entry,
  output: {
    clean: true,
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].chunk.js'
  },
  plugins: [
    ...Object.keys(entry).map(item => // loop entry files and map HtmlWebpackPlugin
      new HtmlWebpackPlugin({
        template: 'src/index.html',
        filename: `${item}.html`,
        chunks: ['runtime', 'vendors', item]
      })
    )
  ],
  optimization: {
    usedExports: true,
    runtimeChunk: {
      name: 'runtime',
    },
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          name: 'vendors',
        }
      }
    },
  }
...
};

Let's re-package it by running 'npm run build'. The page has been successfully bundled.

At this point, when we add a new entry, all we need to do is configure the entry file. For example, if we want to add a 'userInfo' page, we just need to configure it in the entry file:



entry: {
    index: "./src/index.js",
    list: "./src/list.js",
    details: "./src/details.js",
    userInfo: "./src/userInfo.js"
},

DEV Community: Mark

[Boost]

Rethinking DELETE: Idempotency Design and Correct Semantics for Delete Endpoints

Rethinking DELETE: Idempotency Design and Correct Semantics for Delete Endpoints

1. What Is Idempotency?

2. A Common Mistake: Treating "No Change" as Failure

3. The Real Semantics of DELETE: Ensuring the Resource Does Not Exist

4. Why Should "Already Nonexistent" Also Count as Success?

5. What Should success Actually Represent?

6. Recommended DELETE Response Design

For simple resources

When you need to know whether a change actually occurred

7. Why Are Orders and Contracts Different?

8. When Do You Need to Know Whether the Resource Existed Before Deletion?

Audit systems

Financial systems

9. Practical Design Recommendations

10. Summary

Java Concurrency Programming Learning Roadmap: Understanding Threads Through Problems

1. Why Do We Need Concurrency?

Improving system response time

Making better use of multi-core CPUs

2. When Multiple Threads Run Together, What Problems Appear?

Atomicity

3. Visibility Problem

Visibility

4. Ordering Problem

Instruction Ordering

The Three Core Problems

5. How Do We Solve Concurrency Problems?

volatile

synchronized

ReentrantLock

AQS (AbstractQueuedSynchronizer)

CAS (Compare And Swap)

CAS

6. How Do Threads Cooperate?

Why Do Threads Need to Wait?

sleep

wait

park

How Do Threads Communicate?

CountDownLatch

CyclicBarrier

Semaphore

7. How Do Multiple Threads Complete Complex Tasks?

8. How Should Threads Be Stopped?

Graceful Shutdown

9. Too Many Threads: What Happens?

Thread Pool

10. Concurrent Collections

ConcurrentHashMap

CopyOnWriteArrayList

11. Why Do Threads Get Stuck?

Deadlock

How to Avoid Deadlocks

Summary

MVCC Concept: The No-Lock Approach for High-Concurrency Systems

1. What is MVCC

2. How MVCC Works

3. The Essence of MVCC

4. The Philosophy of MVCC

5. Insights for Developers

Conclusion

How to Contribute to Open Source Projects

Throttling and Debouncing in JavaScript

Debouncing

Definition

Example - Autocomplete Input

Unoptimized Implementation

Debounce Optimization

Throttling

Example - Scroll to The Top

Unoptimized Implementation

Throttling Optimization

Two Ways to Implement Throttling: Timestamps and Timers

Summary

My CSS Units Best Practices

Font Size

Width

5. What Should `success` Actually Represent?