RabbitMQ: message broker

Different Architecture Model: push & pull

Storage: rabbitmq delete after ack, kafka stored on disk, and durable

ordering: rabbitmq harder to guarentee, kafka: guarenteed per partition

TCP: use three handshake to establish connection between sender and receiver, more reliable, has flow control, has ordering, and guarantee data arrived exactly as sent. used on browsing, email

UDP: connectionless, no guarantee on the data sent will be received, order. also no overhead on set up connection error checking, faster and lower latency, best for live streaming, online gaming

Connection:

tcp sets up connection, for any data sent there is a three way handshake, to make sure both the sender and receiver are ready.

-i: ignore case

-v: match doesn't contain

-n: show line number

-o: only show part that exactly matches

-A n: n lines after the occurrence

-B n: n lines before the occurrence

-C n: both n lines before and after

-E: use regular expression

-c: show matched line count

-r: recursive search, usually for folder

less is suggested for reading log, large file, less is more

g - go to top

G - go to bottom

/keyword - search for keyword

b - go backward 1 page

f - go forward 1 page

q - quit

common usage of cat:

cat a b > c: concatenate content of a and b and redirect the output to file c

cat > foo.txt: read from stdin and redirect to foo.txt

Property

Snowflake

UUID v4

UUIDv7

Size

64-bit int

128-bit

128-bit

Format

Integer (e.g. 1541815603606036480)

Hex string (e.g. 550e8400-e29b-...)

Hex string (e.g. 018e-...)

Time-sortable

✅ Yes (ms precision)

❌ No

✅ Yes (ms precision)

Globally unique

⚠️ Within a coordinated cluster

✅ Yes (~2¹²² entropy)

✅ Yes (~74 bits entropy)

Requires coordination

✅ Yes (machine ID assignment)

❌ No

❌ No

DB index performance

✅ Excellent (sequential)

❌ Poor (random, index fragmentation)

✅ Excellent (sequential)

Embeds timestamp

✅ Yes

❌ No

✅ Yes

Human extractable time

✅ Yes

❌ No

✅ Yes

Collision risk

Very low (coordinated)

Negligible (random)

Very low

Standard

Proprietary

RFC 4122

RFC 9562 (2023)

Cross-system portability

⚠️ Epoch is custom

✅ Universal

✅ Universal

@Component is a class-level annotation. Its basically telling ioc container “during your startup scan, when u meet this class, please initiate it and keep it in your pocket”

• Sterotypes:

  • @Controller: for web request handler

  • @Service: for business logic

  • @Repository: for data access

• Best for: you own the source code and have full control over the code

@Bean is a method-level annotation. Usually found in a class marked with @Configuration. Instead of spring find the class and do the job, you write code to initialize it and return it.

• Best for: third party libaries where we have no access to the source code so that we can not annotate with @Component'

So what is the tradeoff?

Advantages of navigator.sendBeacon:

• Specifically designed for sending data when a page is being unloaded

• Asynchronous with low priority, won't block page unload process

• Browser ensures data transmission completion even after page closure

• Simple to use with a clean API interface

• Automatically uses POST method

• No need to handle responses, ideal for one-way data reporting

Limitations of navigator.sendBeacon:

• Only supports POST requests

• Cannot receive response content

• Size limitations (Chrome limits to approximately 64KB)

• No custom headers support (except Content-Type)

Advantages of fetch + keepalive:

• Supports all HTTP methods (GET, POST, PUT, etc.)

• Allows custom request headers

• Can handle response content

• No data size limitations

• More flexible error handling

Limitations of fetch + keepalive:

• More complex implementation

• Requires manual keepalive option setting

• Slightly lower browser compatibility compared to sendBeacon

Usage examples:

1. Using navigator.sendBeacon (for simple data reporting):

javascriptCopywindow.addEventListener('unload', () => {
  navigator.sendBeacon('/api/log', JSON.stringify({
    event: 'page_exit',
    duration: performance.now()
  }));
});

2. Using fetch + keepalive (for more control):

javascriptCopywindow.addEventListener('unload', () => {
  fetch('/api/sync', {
    method: 'POST',
    keepalive: true,
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer token'
    },
    body: JSON.stringify({
      data: 'important_data'
    })
  });
});

Recommendation: Choose navigator.sendBeacon for simple analytics and logging scenarios, and fetch + keepalive when you need more control over the request or need to handle responses. For critical data, consider synchronizing during user interactions rather than waiting for page unload.

• —save (-S)

• —save-dev (-D)

So what is the diff?

npm install <package> —save

• Is equivalent to npm install <package>, which is the default behavior.

• It install the package under node_modules, and add the package’s version information into the package.json’s dependencies.

npm install <package> —save-dev

• Not the default behavior, === npm install <package> -D.

• It install the package under node_modules, and add the package’s version information into the package.json’s devDependencies.

• These packages would not be install in prod env.

• Suitable for packages that would only be used in dev env, like eslint, webpack, @types/react (type definition packages, provided by TS community)

Note: the reason @types/react exist only in the dev env is

• Type definitions are only used during development to provide code hints and type checking

• These type definitions are not needed in the production environment

• All type information is removed in the compiled JavaScript code

• window.innerHeight

• window.innerWidth

• window.navigator

• window.location

  • url info

• window.history

• window.localStorage

• window.sessionStorage

methods:

• window.alert()

• window.setTimeout()

• window.open()

  • open a new tab by default

  • window.open("https://example.com", "_blank");

navigator

• navigator.userAgent

• navigator.language

• navigator.platform

• navigator.onLine

• navigator.geoLocation

document

• document.title

• document.cookie // cookie

• document.location // URL related

• document.getElementById()

• document.querySelector()

• document.createElement()

location

• location.href // full URL

• location.protocol

• location.host

• location.hostname

• location.port

• location.pathname

• location.search

• location.hash

history

• history.back()

• history.forward()

• history.pushState()

• history.replaceState()

1. Build Processing

• src/assets: Files will be processed by build tools (like webpack, Vite)

  • Images may be compressed and optimized

  • CSS/SCSS will be compiled and prefixed

  • Filenames will be hashed, e.g., logo.png → logo.a5d4f.png, for cache control

  • Filename caching is critical for updates, since the browser would cache the resource. If the browser find no changes on the name, it would not fetch the updated version, through giving them a hash name it is easier to do cache control and version control.

• public: Files will be copied to their build directory as-is

  • No compression or optimization

• Filenames remain unchanged

• Suitable for files that need fixed paths

2. Usage Method

• src/assets: Need to be imported

import logo from '@/assets/images/logo.png'

• public: Referenced directly via absolute path

<img src="/images/logo.png" />

3. Use Case Examples: Files to put in public:

• favicon.ico

• robots.txt

• sitemap.xml

• Resources that need to be referenced directly in index.html

• Files that require fixed access paths

• Large media files (like videos) that don't need build processing

Files to put in src/assets:

• Images used by components

• Style files

• Other resources that need build tool processing

• Files that need frequent modifications

In simple terms, if a resource needs to be processed by build tools or changes frequently, put it in src/assets; if it needs to remain unchanged with a fixed path, put it in public.

Here is a sample of using Vite’s plugin to optimize & compress the image.

// vite.config.js
import { defineConfig } from 'vite'
import imagemin from 'vite-plugin-imagemin'

export default defineConfig({
  plugins: [
    imagemin({
      // WebP conversion
      webp: {
        quality: 75
      },
      // PNG compression
      pngquant: {
        quality: [0.8, 0.9],
        speed: 4
      },
      // JPEG compression
      mozjpeg: {
        quality: 75
      }
    })
  ]
})

My first thought was web worker, we could create web worker and run the tasks on another thread, without blocking the main thread that is responsible for rendering. (Obviously the task is not related to ui rendering, since web worker have no access to the DOM)

While they told me that another solution could be batch processing, like using setTimeout(), and there is one more api could be used in this scenario: requestIdleCallback. This api would register a callback function and would get it executed when the main thread is idle.

Here is a sample:

requestIdleCallback(function(deadline) {
  // check if there is enough idle time in the browser
  while (deadline.timeRemaining() > 0) {
    // execute the task, untill there is no more idle time left
    doSomeTask();
  }
}, {timeout: 2000});  // force execution if the browser is not idle within 2 seconds

The final take away from this interview question is that: to ensure the browser remain smooth and doesn’t freeze, the key is to avoid long-running synchronous tasks that block the main thread.

This post is a shallow comparison between the normal http requests, short polling, long polling, webSocket, and SSE.

• Communication Method

  • HTTP Requests: One-way request/response.

  • Short Polling: One-way request/response.

  • Long Polling: One-way request/response.

  • WebSocket: Full-duplex, bidirectional communication.

  • SSE: One-way communication (server to client).

• Connection Persistence

  • HTTP Requests: A new connection is established for every request.

  • Short Polling: Each request closes after completion.

  • Long Polling: Each request closes after completion.

  • WebSocket: Persistent connection until explicitly closed.

  • SSE: Persistent connection until explicitly closed.

• Real-Time Capability

  • HTTP Requests: Low (requires new requests after each response).

  • Short Polling: Medium (depends on polling frequency).

  • Long Polling: Medium-High (server can push data proactively).

  • WebSocket: Very high (minimal latency).

  • SSE: Medium-High (server can push data proactively).

• Performance

  • HTTP Requests: High overhead (frequent connection setup).

  • Short Polling: Medium (frequent requests).

  • Long Polling: Lower (reduces unnecessary requests).

  • WebSocket: Optimal (single connection, low overhead).

  • SSE: Efficient (single connection, low overhead).

• Use Cases

  • HTTP Requests: Static data fetching or short-lived interactions.

  • Short Polling: Scenarios with infrequent data updates (e.g., weather updates).

  • Long Polling: Applications needing real-time updates (e.g., chat systems).

  • WebSocket: High-frequency, real-time bidirectional data exchange.

  • SSE: One-way real-time data streams (e.g., notifications, live feeds).

• Arrow function:

  • Does not has its own this keyword, it inherits this from the surrounding lexical scope where it was defined.

  • This feature is particularly useful when working with callbacks, as the context in which the function is created may differ from the context in which it is called

  • (a) Declared in the Global Context

      const arrowFunction = () => {
        console.log(this);
      };
    
      // Arrow functions do not have their own `this`
      arrowFunction(); // `this` refers to the surrounding lexical scope (global in this case)
    

    (b) Inside an Object

      const obj = {
        value: 42,
        arrowFunction: () => {
          console.log(this);
        },
      };
    
      obj.arrowFunction(); // `this` still refers to the surrounding scope, not `obj` (global or outer context)
    

    (c) Nested Inside a Normal Function

      const obj = {
        value: 42,
        normalFunction: function () {
          const arrowFunction = () => {
            console.log(this);
          };
          arrowFunction(); // `this` refers to `obj` because it inherits from the surrounding `normalFunction`
        },
      };
    
      obj.normalFunction(); // `this` is `obj`
    

• Normal function:

  • The value of this is dynamic and depends on how the function is called.

  • It can change when the function is invoked using .call, .apply, or .bind.

  • (a) Function Declaration

      function normalFunction() {
        console.log(this);
      }
    
      // Calling it in the global context
      normalFunction(); // In browsers: `window`, in Node.js: `global`
    

    (b) Function Expression

      const normalFunction = function () {
        console.log(this);
      };
    
      // Calling it in the global context
      normalFunction(); // In browsers: `window`, in Node.js: `global`
    

    (c) As a Method of an Object

      const obj = {
        value: 42,
        normalFunction: function () {
          console.log(this);
        },
      };
    
      obj.normalFunction(); // `this` refers to `obj`
    

    (d) Extracted from an Object

      const extractedFunction = obj.normalFunction;
      extractedFunction(); // `this` is `undefined` in strict mode or `window/global` in non-strict mode
    

Arguments Object

• Normal Method:

  • Has access to the arguments object, which is an array-like object containing all the arguments passed to the function. (How come I just got to know about this?!!)

    javascriptCopy codefunction normalFunction() {
      console.log(arguments);
    }
    normalFunction(1, 2, 3); // [1, 2, 3]

• Arrow Function:

  • Does not have its own arguments object. To access arguments, you must use rest parameters.

    javascriptCopy codeconst arrowFunction = (...args) => {
      console.log(args);
    };
    arrowFunction(1, 2, 3); // [1, 2, 3]

Obviously, both localStorage and indexDB is client side storage solutions provided by modern web browser.

But there’s lots of diff between them, could be analyzed from the following perspectives:

Data structure:

• IndexedDB:

  • is a NoSQL DB, store in key-value pair format but allow structured data(obj, arr) with indexes

  • supports complex queries, transactions

  • suitable for storing large, structured data sets.

• localStorage:

  • simple string-based key-value storage

  • meant for simple storage and retrieval tasks

Storage limits:

• IndexedDB: larger storage limits: range from hundreds of MBs to GBs, ideal for data like images, videos, or entire datasets

• LocalStorage: limited to about 5-10 MB per domain

Performance:

• IndexedDB: asynchronous operation (none-blocking), high performance, handy for large DB

• LocalStorage: synchronous operation (blocking), slower with potential causing UI performance issues

When to use:

• IndexedDB: Choose this for large-scale, structured, and performance-critical tasks.

• LocalStorage: Opt for this for small, quick, and simple tasks where blocking is acceptable.

Play around at https://codesandbox.io/p/devbox/an-intresting-react-error-d9gc2l, line 60.

Problem description:

When text area wrapped in a component, the text area would lose focus whenever user type in a character.

Some might ask what is the purpose of this Wrapper: DefaultRender, since we might have different render logic and design, we would like it to be dynamically rendered based on our needs (this part is removed from the code snippet, since it is unrelated to the bug).

// Here is a normal list rendering, the normal TextArea works perfectly fine, 
// but once replaced with the DefaultItemRender would trigger the problem of losing focus.
{editingItems.map((item, index) => {
  if (!item) return null;

  return (
    <div key={index}>
      {/* <TextArea
      value={item.title || ''}
      onChange={(value) => handleInputChange(index, 'title', value)}
    /> */}
      <DefaultItemRenderer
        item={item}
        index={index}
      />
    </div>
  );
})}

// Just a normal wrapper of TextArea, the reason for this wrapper is: initially 
const DefaultItemRenderer = ({ item, index }) => {
  return (
    <TextArea
      value={item.title || ''}
      onChange={(value) => handleInputChange(index, 'title', value)}
    />
  );
};


// TextArea is just a custom component
import React, { useRef, useEffect } from "react";

const TextArea = ({ value, onChange }) => {
  useEffect(() => {
    console.log("TextArea rendered");
  }, []);

  return (
    <textarea
      value={value}
      onChange={(e) => onChange(e.target.value)}
      rows={1}
    />
  );
};

export default TextArea;

Some guess around it:

Still confused about the cause.