DEV Community: Janice

How to make Docker work in China

Janice — Mon, 09 Feb 2026 04:46:04 +0000

While I'm on my holiday in China, I surprisingly found out that Docker was unable to download images from Docker Hub at all, not even behind a VPN. It took me some time to figure out this work-around and I hope it can help you save your time.

Step 1 - Launch a proxy server

Launch an EC2 instance on AWS as a proxy server, make sure the server locates at somewhere that's not restricted from accessing Docker Hub.

For personal uses, t2.micro is enough. Remember to open an SSH port because we'll need to run commands in our instance later.

Step 2 - Install Squid

sudo yum update -y
sudo yum install squid -y
sudo systemctl start squid
sudo systemctl enable squid

Squid is listening on 3128 by default. Open the port 3128 on your EC2 instance so that traffic can be accepted.

Edit your Squid configurations:

sudo vi /etc/squid/squid.conf

Find the line

http_access deny all

and change it to

http_access allow all

but really for security enhancement, you should replace all to IP addresses you want to allow.

Then

sudo systemctl restart squid

Testing if your proxy server works:

curl -x http://new-instance-public-ip:3128 https://whatismyipaddress.com/

Step 3 - Configure in Docker

I'm using a Mac and I have Docker Desktop installed. The steps can vary based on different operating systems and how you installed Docker so make sure you find your own way.

Let Docker know your proxy server by going to Settings - Resources - Proxies and fill in the below three fields:

# Http server
http://new-instance-public-ip:3128
# Https server
http://new-instance-public-ip:3128
# bypass proxy settings for these
registry-1.docker.com,*.docker.com,10.0.0.0/8

Final Step - Testing

Now try downloading images in your Docker to test. Docker should have worked by now!
Remember to stop your EC2 instance when it's no longer used to avoid any unwanted charges. Happy docking!

My attempt on Cloud Resume Challenge in 2026 (Part 2)

Janice — Thu, 22 Jan 2026 06:31:38 +0000

This blog continues from My attempt on Cloud Resume Challenge in 2026.

Table Contents

Smoke Tests with Cypress
Multiple Environments
AWS Cross-Account Access
Lambda Gotchas
DynamoDB Gotchas
GitHub OIDC Gotchas with Multiple Environments

Smoke Tests with Cypress

Cypress is used for smoke tests to verify that the page loads correctly and to run basic sanity checks against real API requests.
In GitHub Actions, the Cypress binary must be installed explicitly and cached. This is because Cypress installs its binary via a postinstall script, while pnpm only downloads the JavaScript wrapper and Node APIs by default.

Multiple Environments

Multiple environments are set up to support controlled deployments.
Staging: Pull requests merged into the main branch trigger CI/CD and deploy automatically to the staging environment.
Production: Commits that have passed CI/CD are promoted to production by creating a release/* branch and tagging a release (for example, v1.0.0).

AWS Cross-Account Access

HCP Terraform authenticates to the AWS production account via OIDC to create most resources.
It then assumes a role in the admin account specifically for modifying DNS records.

Lambda Gotchas

Use structured JSON logging to improve integration with log aggregation and analytics platforms.
Lambda functions containing non-trivial business logic should be covered by unit tests.

DynamoDB Gotchas

Use the ADD operation in UpdateItem to simplify value initialization and atomic increments.
Use auto-generated table names to allow resource replacement (for example, when changing billing modes).
When a replacement occurs, restore the table from a backup rather than reinitializing it from scratch.

GitHub OIDC Gotchas with Multiple Environments

GitHub OIDC assumes an IAM role in the target AWS account, where the sub claim controls which repository is allowed to assume the role.
The sub field is often restricted to a single repository, but to support multiple environments, it must allow all refs:

"StringLike": {
  "token.actions.githubusercontent.com:sub": "repo:<org>/<repo>:*"
}

My attempt on Cloud Resume Challenge in 2026

Janice — Mon, 12 Jan 2026 02:20:07 +0000

Table Contents

About the project
My suggestions before getting started
How much time I spent
Reflection
- Project Architecture
- DynamoDB
- API Gateway
- Security
Git Repo
More to come

About the project

Cloud Resume Challenge is a project designed to help you get started in the Cloud field if you aspire to become a Cloud/DevOps engineer. The challenge emphasizes real-world experience, and the end goal is to build something you will actually use—not a toy project.

The project itself is a resume website with a page view counter.

You can learn more on the official site and also here, where the creator explains the motivation and goals behind the challenge in more detail.

My suggestions before getting started

If you have limited time and want some practical advice before starting, here are my two cents:

You can skip the HTML/CSS part. It doesn’t really matter what the site looks like before you put it on your resume. The real value lies in the cloud architecture and implementation.
If you’re not very familiar with AWS (or the cloud provider you choose), start with the web console instead of Infrastructure as Code (IaC). This allows you to move faster and get a working demo early. When you later switch to IaC, you’ll better understand which configurations were implicitly handled by the console.
Be conservative with the time you spend on each topic. There’s a lot to cover in this project, and there’s always more to explore. Focus on understanding the overall architecture rather than getting stuck in low-level details.

How much time I spent

I was a frontend engineer transitioning into DevOps. I spent less than a week on this challenge, completing all requirements on the website.

To be honest, the absolute amount of time spent is meaningless. It correlates with how deep someone wants to go and how comprehensive their solution is. Instead, here’s the rough ratio of time I spent on each part:

HTML/CSS: I used Next.js to build a static site and typed in some basic content, so this took almost no time—around 0–1%.
Web console setup: By this, I mean creating a fully working demo using the AWS console. This took about 30% of the time, including learning new concepts like API Gateway and Lambda.
IaC + CI/CD: This took around 50–60% of the time, which I did not anticipate. CI/CD involves a lot of trial and error, and IaC introduced unexpected issues due to hidden configurations created by the web console.
Blog writing: The remaining time (~10%) was spent on reflection. In my opinion, this is actually the most important part.

Reflection

Spoiler alert: Please stop reading if you haven’t completed the challenge yet, as I’m about to reveal my solution.

Project Architecture

The domain name (janice-zhong.com) is resolved into an IP of a CloudFront distribution, which is connected to a S3 bucket with static hosting. The S3 displays the website content which involves calls to API Gateways that trigger lambda functions to read from and write into a DynamoDB.
Two TLS certs are provisioned in the us-east-1 region for CloudFront and in the apsouth-east-2 region for the API Gateways.

Lambda Function

Lambda is a managed compute service that allows you to run functions on AWS without managed servers. The important point to note is that each Lambda function should be idempotent, which means running your function multiple times should always result in the same outcome. Lambda supports concurrent invocations where each invocation will start with a fresh state, you should assume no state persisting between invocations.

DynamoDB

DynamoDB provides serial writes at the item level

DynamoDB is where I made my first mistake. I thought concurrent Lambda functions will incur race conditions on writes to DB when updating the same record. Therefore, I started with inserting one record per page visit and counting the total number of records.

This approach quickly became problematic because Scan operations in DynamoDB are O(n), which is inefficient for a simple page view counter. Later, I discovered the following:

DynamoDB provides serial writes at the item level by default.

Prevent throttled concurrent writes via client retries

DynamoDB functions based on RCU (Read Capacity Unit) and WCU (Write Capacity Unit). There is a cap to how many concurrent reads/writes per second you can have. The on-demand capacity mode provides 4000 writes/second. Once this cap has been reached, DDB returns a ProvisionedThroughputExceededException error which you can use to attempt retries on the client side.

API Gateways

I'm going to omit details here because the article will get way too long if I covered every topic in depth. I just want to highlight about throttling in API Gateways.

API Throttling

During development, I noticed there were many bot traffic to my CloudFront, which alarmed me to set up throttling in API.
API Gateway throttling can be applied at multiple levels: account (default), stage, and route.
I had applied throttling at the stage level and set burst to 50 and limit to 200. More advanced per IP throttling can be achieved via WAF.

Terraform (IaC)

Remote State + Locking

State should not be committed to VSC to avoid credential leaks and state corruption. Therefore, I initially kept state stored in S3 and later migrated to HCP terraform.

Always pin versions

Always pin provider and module versions to avoid unexpected breaking changes caused by upstream updates.

Use HCP Terraform for automated terraforming (CI/CD)

HCP Terraform offers audit logs, manual approval workflows out of box, without extra configurations compare to GitHub Actions. This significantly reduces operational overhead for Terraform-based CI/CD.

Security

OIDC

OpenID Connection allows GitHub workflows to access AWS using short-lived credentials. GitHub assumes an IAM role defined in your account to perform actions on your behalf. This approach improves security by eliminating long-lived access keys stored in GitHub secrets and reduces the operational burden of credential rotation.

TLS

TLS are used to encrypt traffic between clients and servers. Two TLS certs are provisioned in the us-east-1 region for CloudFront and in the apsouth-east-2 region for the API Gateways.

Adding Human Verification Process

The volume of bot traffic raises concern that legitimate human users would be blocked due to these limits I set. To address this, there are two options:

CloudFront + AWS WAF. Native AWS solution but comes with some costs. The managed bot control rule group costs:

$10 per month (prorated hourly). Includes processing the first one million web requests of each month. Includes analysis of CAPTCHA and challenge attempts.

A tutorial can be found here.

I plan to integrate Cloudflare Turnstile which serves the same purpose but free.

Git Repo

Frontend: https://github.com/qianzhong516/janice-zhong
IaC: https://github.com/qianzhong516/janice-zhong-iac

More advanced features

To read more features I implemented in thsi project: My attempt on Cloud Resume Challenge in 2026 (Part 2)

What Makes a Winning Hackathon Project? A Judge’s Perspective

Janice — Tue, 08 Apr 2025 06:35:56 +0000

I recently had the chance to be a judge in a hackathon challenge proudly sponsored by KendoReact and the DEV community—and it completely changed how I see tech competitions. From reviewing submissions under pressure to spotting the difference between a polished MVP and an over-scoped idea, the experience was both inspiring and eye-opening.

In my latest blog post, I share practical tips for both participants and fellow judges. Whether you’re preparing your next hackathon submission or curious about what goes on behind the scenes, you’ll find helpful insights.

👉 Read the full post on my website

(Spoiler: there’s a judge badge flex at the end.)

I’m Janice, a freelance web developer based in Australia. I run my own web design and SEO business, working closely with small businesses to help them grow online. While I do speak “human” when needed for my clients, I proudly spend most of my time in full-on tech nerd mode.

If you like my content, follow me on: Instagram, Facebook, LinkedIn

`this` Used In Objects

Janice — Wed, 15 May 2024 15:16:05 +0000

this is one of the most tricky concepts in JavaScript. Fully understanding this topic sets us apart from the other devs in job interviews.

Previsouly I wrote a post Learn From Mistakes I Made With this in JS, which is about handling this used in a function passed as a reference to another function. Here is a continued part talking more about this when it's used with objects. Here's an example:

function makeFox() {
  return {
    name: 'fox',
    ref: this
  }
}

const fox = makeFox();
fox.ref.name // what's the result?

The code results in an error calling .name on undefined. This is because this refers to the context of the function makeFox, not the object returned from it. Here's a way to fix this problem:

function makeFox() {
  return {
    name: 'fox',
    ref() {
        return this;
    }
  }
}

const fox = makeFox();
fox.ref().name // 'fox'

By making ref a function, this becomes dynamic. Its value depends on the object which evokes this function. In this case, the calling object is fox.

Takeaway

Ring off the alarm in your brain once you see this is exposed without being wrapped within a code block as a property of an object. For example,

let obj = {
  prop: this
}

Chances are a mistake has been made unconciously.

Learn From Mistakes I Made With `this` in JS

Janice — Wed, 15 May 2024 14:53:48 +0000

Here I'd like to talk about the mistake I made in one of the online assessments for a job interview regarding this in Javascript.

Here's the question - What would be logged from below code?

function Fox(color) {
  this.color = color;
}

Fox.prototype.speak = function () {
  console.log(`I'm ${this.color}`);
};

const myFox = new Fox('blue');
setTimeout(myFox.speak, 1000);

If you were like me, thought it would log "I'm blue", then congrats, you are perfectly wrong! The correct answer is "I'm undefined".

So why did this lose its context? This is because myFox.speak is passed into setTimeout as a function reference only, without the correct calling context. To fix this problem, here are a few ways.

Use arrow function

Arrow function does not have this and it takes the value of this from an outer context. In this case, the outer context refers to myFox.

setTimeout(() => myFox.speak(), 1000)

Use `bind`

The calling context is bound by using bind.

setTimeout(myFox.speak.bind(myFox), 1000)

Explicitly evoke speak()

setTimeout(function() {
  myFox.speak()
}, 1000)

Takeaway

Ring off the alarm in your brain whenever you see a function containing this is passed as a reference.

React Callback Refs

Janice — Sat, 28 Oct 2023 11:44:03 +0000

React refs are used when you want to update a value between renders but do not want the update to trigger rerendering. Here's one of the examples: useIsFirstRender returns true only if it is on the first render.

function useIsFirstRender(): boolean {
    const isFirstRender = useRef(true);

    useEffect(() => {
        isFirstRender.current = false;

        return () => {
            isFirstRender.current = true;
        }
    }, []);

    return isFirstRender.current;
}

Making isFirstRender a ref object would be better than making it a state, because modifying a state could potentially trigger other side effects unnecessarily during rerenders.

Now let's take a look at another example of useRef. We need to customize a hook useFocus. useFocus returns a ref object to be assigned to an input element and a boolean isFocus indicating if the input is currently being focused.

function useFocus<T extends HTMLElement>(): [Ref<T>, boolean];

function App() {
  const [ref, isFocused] = useFocus<HTMLInputElement>()
  return <div>
    <input ref={ref}/>
    {isFocused && <p>focused</p>}
  </div>
}

At the first glance, you might be thinking to use a useEffect block, so we can add focus & blur event listeners from the input in the useEffect, and remove the listeners in a cleanup function. However, this would not work out well in the case that we have two inputs in the same component and the ref could potentially be switched from one input the other input. Let's visualise what I mean:

export function App() {
    const [buttonLabel, setButtonLabel] = useState(0);
    const toggle = () => setButtonLabel(buttonLabel ? 0 : 1);
    const [ref, isFocused] = useFocus<HTMLInputElement>()

    return <div>
                <input ref={buttonLabel ? null: ref}/>
                <input ref={buttonLabel ? ref : null} />
                <button onClick={toggle}>Toggle input</button>
                {isFocused && <p>focused</p>}
    </div>
}

As you can see, when the ref changes, we need a way to force the useEffect cleanup function to run, otherwise it will cause the problem where the event listeners retain in the previous input.

Introducing Callback Refs

Here is when ref callbacks become useful.

<div ref={(node) => console.log(node)} />

By default ref callbacks are invoked when you pass in a new ref callback. Basically this happens in the following scenarios:

The component mounts
The component unmounts
The component rerenders

Now back to our example, here's the solution with ref callbacks:

  const refCallback = useCallback((node: T) => {
    if(inputRef.current) {
      inputRef.current.removeEventListener('focus', handleFocus);
      inputRef.current.removeEventListener('blur', handleBlur);   
    }

    if(node) {
      node.addEventListener('focus', handleFocus);
      node.addEventListener('blur', handleBlur);
    }

    inputRef.current = node;
  }, [])

We wrap the ref callback with useCallback to avoid the callback being triggered every time the component rerenders. E.g, when the user focuses/unfocuses on the input. Now when the ref changes, node changes from the old input to undefined, then takes the new input. The logic sequence goes:

Remove the listeners from the old input
inputRef.current becomes undefiend
Attach the listeners to the new input
Assign the new input to inputRef.current

Here is the full solution:

import React, { Ref, useState, useRef, useCallback } from 'react'

export function useFocus<T extends HTMLElement>(): [Ref<T>, boolean] {
  const [isFocused, setFocused] = useState(false);
  const input = useRef<T>();

  const handleOnFocus = useCallback(() => setFocused(true), []);
  const handleOnBlur = useCallback(() => setFocused(false), []);

  const inpurRefCallback = useCallback((node: T) => {
    if (input.current) {
      // cleanup listeners on previous ref
      input.current.removeEventListener('focus', handleOnFocus);
      input.current.removeEventListener('blur', handleOnBlur);
    }

    if (node) {
      // Add listeners on new ref
      node.addEventListener('focus', handleOnFocus);
      node.addEventListener('blur', handleOnBlur);
    }

    // save new ref
    input.current = node;
  }, [])

  return [inpurRefCallback, isFocused]
}

Ref callbacks would be a perfect usage in the custom hooks like useFocus and useHover etc. It gives you more control over your implementation when the node changes.

I hope you have learnt something from this post. Feel free to post any questions in the comment section below.

Bonus

There's also a solution if you really want to use useEffect to solve the problem in the example. Here's the code:

export function useFocus<T extends HTMLElement>(): [Ref<T | undefined>, boolean] {
  const [isFocused, setFocused] = useState(false)
  const ref = useRef<T>()
  useEffect(() => {
    const currentElement = ref.current
      if (!currentElement)
      return

    // initialize the focus state when currentElement changes.
    setFocused(document.activeElement === currentElement)

    const onFocus = () => setFocused(true)
    const onBlur = () => setFocused(false)

    currentElement.addEventListener('focus', onFocus)
    currentElement.addEventListener('blur', onBlur)

    return () => {
      currentElement.removeEventListener('focus', onFocus)
      currentElement.removeEventListener('blur', onBlur)
    }
  }, [ref.current]) // now we can pass a dependency array to get much better performance.

  return [ref, isFocused]
}

However, I personally would not recommend this approach because when you specify ref.current in the useEffect's dependency array, how side effect updates immedicately becomes unintuitive. For example, with the above code on the first render:

useEffect gets triggered, and it double sets focused to false
attach the event listeners

When the user focuses on the input for the first time:

useEffect gets triggered again since ref.current has changed from undefined to the input, and it double sets focused to true

When the user focuses on the input after the first time:

useEffect won't be triggered again

The problem is that the value of ref in the deps array is not in sync with the one in the useEffect's body.

Create React App From Scratch With Isomorphic Rendering

Janice — Thu, 14 Sep 2023 11:03:52 +0000

I'd been always curious about how to manually configure a React project from scratch using webpack. Let me share my learnings with you in this post.

The benefits of learning configuring your own project:

Prodviding you a bare bone to start with when create-react-app is an overkill because it includes many redundant functionalities.
Learning about how babel transpiles your project, how it works with typescript during development and how to auto build your project along with changes.
Mastering webpack configurations to build your own library in the future.

Isomorphic rendering/Server-side rendering

SSR can greatly improve user's first interaction experience by optimizing the first page load time. It also provides a better search engine experience where the crawl bot can access more meaningful content in your pre-generated html file whereas a pure client-side rendering page only contains <div id="root"></div>.

Project Structure

After building our project, we are expecting a dist/ folder containing client/ and server/ where client/ contains the code for hydrating the pre-generated content and server/ contains the server code with NodeJS. Hence, we need two webpack.config.js for configuring each directory respectively. Later on, we can boost the server by running node dist/server/main.js and see the page result by accessing the localhost url. Here is the preview:

>> dist
>>>> client
>>>> server
>> node_modules
>> server
>>>> ...
>>>> webpack.config.js (builds dist/server)
>> src (components)
>> client.tsx (clients-side entry file)
>> webpack.config.js (builds dist/client)

Client side logic

The code below tells React to compare the pre-generated content from server to the component App we want to render. Any mismatch is not allowed because SSR provides users an illusion of faster page load time by showing users content generated from server, then attaches React to it. Any mismatch between the content will break that illusion.

import { hydrateRoot } from 'react-dom/client';
import { App } from './src/app';
import React from 'react';

hydrateRoot(document.querySelector('#root')!, <App />);

In the webpack.config.js, we have HtmlWebpackPlugin configured to automatically inject the built scripts to the html template we provide, which is a simple boilerplate includes <div id="root"></div>. filename: '[name].[contenthash].js' is to improve compile time by preventing re-compling files if there is no changes since last build.

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

const config = {
    entry: './client.tsx',
    output: {
        filename: '[name].[contenthash].js',
        path: path.resolve(__dirname, 'dist/client'),
        // clean /dist/client before each build
        clean: true,
    },
    resolve: {
        extensions: ['.ts', '.tsx', '.js', '.json'],
    },
    plugins: [
        new HtmlWebpackPlugin({
            title: 'Create React From Scratch',
            meta: { viewport: 'width=device-width, initial-scale=1.0' },
            template: './index.html',
            inject: 'body',
            publicPath: '/dist/client',
        }),
    ],
    module: {
        rules: [
            {
                test: /\.(ts|js)x?$/,
                exclude: /node_modules/,
                use: {
                    loader: 'babel-loader',
                },
            },
        ],
    },
    optimization: {
        // to prevent vendor chunk from being regenerated due to module resolving order is changed
        // when a new dependency is included
        moduleIds: 'deterministic',
        // extract the boilerplate for webpack runtime code
        runtimeChunk: 'single',
        // remove duplicate dependencies from bundles
        splitChunks: {
            chunks: 'all',
        },
    },
};

module.exports = (env, argv) => {
    if (argv.mode === 'development') {
        config.devtool = 'inline-source-map';
    }

    return config;
};

babel-loader is a handy plugin for transpiling js code so that the resultant code is compatible across older browser environments. node_modules is excluded because we are using packages actively maintained by the community thus we can expect them to be in a good shape for production use. In addition, we have babel-loader configured with a list of presets. Those presets provide pre-defined lists based on the target environment for transpiling js, jsx and ts code.

babel.config.json

{
    "presets": [
        "@babel/preset-env",
        "@babel/preset-react",
        "@babel/preset-typescript"
    ]
}

Server side logic

Now we have our html file ready with necessary scripts injected. The next objective is to inject the html string of the component we want to render into the html file. Here is when renderToString comes into play. renderToString renders our React component into a html string.

// template.tsx
import { renderToString } from 'react-dom/server';
import { App } from '../src/app';
import React from 'react';

export default function renderHtmlString() {
    return renderToString(<App />);
}

In server.ts, parse the html read from the file system and inject the rendered html string into div#root.

// server.ts
import fs from 'fs';
import renderHtmlString from './template';
import express from 'express';
import { parse } from 'node-html-parser';
import path from 'path';

// ...
app.get('/', async (_, res) => {
    try {
        const html = fs.readFileSync(
            path.resolve(process.cwd(), 'dist/client/index.html'),
            'utf-8'
        );
        const htmlContent = parse(html);
        const root = htmlContent.querySelector('#root')!;
        root.textContent = renderHtmlString();
        res.send(htmlContent.toString());
    } catch (err) {
        throw err;
    }
});

In webpack.config.js, it is worth mentioning that we use webpack-node-externals to exclude packages from node_modules and externalsPresets: { node: true } to exclude native packages provided by the environment from being bundled into our code.

const path = require('path');
const nodeExternals = require('webpack-node-externals');

const config = {
    target: 'node',
    entry: path.resolve(__dirname, 'server.ts'),
    output: {
        filename: '[name].js',
        path: path.resolve(__dirname, '../dist/server'),
        // clean /dist before each build
        clean: true,
    },
    resolve: {
        extensions: ['.ts', '.tsx', '.js', '.json'],
    },
    plugins: [],
    module: {
        rules: [
            {
                test: /\.(ts|js)x?$/,
                exclude: /node_modules/,
                use: {
                    loader: 'babel-loader',
                },
            },
        ],
    },
    // in order to ignore built-in modules like path, fs, etc.
    externalsPresets: { node: true },
    // in order to ignore all modules in node_modules folder
    externals: [nodeExternals()],
    optimization: {
        // to prevent vendor chunk from being regenerated due to module resolving order is changed
        // when a new dependency is included
        moduleIds: 'deterministic',
        // extract the boilerplate for webpack runtime code
        runtimeChunk: 'single',
        // remove duplicate dependencies from bundles
        splitChunks: {
            chunks: 'all',
        },
    },
};

module.exports = (env, argv) => {
    if (argv.mode === 'development') {
        config.devtool = 'inline-source-map';
    }

    return config;
};

Using ECMAScript in Node

You may be wondering how to configure to use ESM imports in Node. Most people suggest to add "type": "module" in package.json, which requires to explicitly name the file extension while importing the scripts. We can avoid that by adding a tsconfig.json under server/ to support ESM imports. You may find this file isn't necessary since babel has support for ts syntax. Babel also doesn't compile options from tsconfig. However, this step is essential if you are using ts-node in your development because ts-node reads from tsconfig file. It wouldn't have recogonised ESM import syntax in otherwise.

{
    "compilerOptions": {
        "target": "esnext",
        "jsx": "react" ,
         /* supports both ECMAScript imports and CommonJS require */
        "module": "NodeNext" ,
    }
}

Babel transpiles your code without type checking, type check your code with typescript

Babel transpiles your code without type checking, which can slip runtime errors into production. In order to prevent that, we should type check our code during build time or even type check in watch mode during development. Here is the tsconfig.json on client side, where noEmit is specified for only type checking purpose.

{
    "compilerOptions": {
        "target": "esnext" /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */,
        "jsx": "react" /* Specify what JSX code is generated. */,
        "module": "commonjs" /* Specify what module code is generated. */,
        "allowSyntheticDefaultImports": true /* Allow 'import x from y' when a module doesn't have a default export. */,
        "forceConsistentCasingInFileNames": true /* Ensure that casing is correct in imports. */,
        "strict": true /* Enable all strict type-checking options. */,

        /* Babel does not type check the code, use tsc for type checking */
        "declaration": true /* Generate .d.ts files from TypeScript and JavaScript files in your project. */,
        "isolatedModules": true /* Ensure that each file can be safely transpiled without relying on other imports. */,
        "noEmit": true
    }
}

tsconfig.json on server side

{
    "compilerOptions": {
        "target": "esnext" /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */,
        "jsx": "react" /* Specify what JSX code is generated. */,
        "module": "NodeNext" /* supports both ECMAScript imports and CommonJS require */,
        "allowSyntheticDefaultImports": true /* Allow 'import x from y' when a module doesn't have a default export. */,
        "forceConsistentCasingInFileNames": true /* Ensure that casing is correct in imports. */,
        "strict": true /* Enable all strict type-checking options. */,
        "moduleResolution": "NodeNext" /* in sync with "module" config */,

        /* Babel does not type check the code, use tsc for type checking */
        "declaration": true /* Generate .d.ts files from TypeScript and JavaScript files in your project. */,
        "isolatedModules": true /* Ensure that each file can be safely transpiled without relying on other imports. */,
        "noEmit": true
    }
}

Finally, putting everything together in package.json

"scripts": {
        "type-check": "tsc",
        "type-check:watch": "tsc --watch",
        "build:client": "npm run type-check && webpack --mode=production --config webpack.config.js",
        "build:server": "npm run type-check && webpack --mode=production --config server/webpack.config.js --stats-error-details",
        "build": "npm run build:client && npm run build:server",
        "dev:watch": "webpack watch --mode=development --config server/webpack.config.js --config webpack.config.js",
        "prod:watch": "webpack watch --mode=production --config server/webpack.config.js --config webpack.config.js",
        "server": "nodemon dist/server/main.js"
    },

Git repo: https://github.com/qianzhong516/create-react-app-from-scratch/tree/isomorphic-react

DEV Community: Janice

How to make Docker work in China

Step 1 - Launch a proxy server

Step 2 - Install Squid

Step 3 - Configure in Docker

Final Step - Testing

My attempt on Cloud Resume Challenge in 2026 (Part 2)

Table Contents

Smoke Tests with Cypress

Multiple Environments

AWS Cross-Account Access

Lambda Gotchas

DynamoDB Gotchas

GitHub OIDC Gotchas with Multiple Environments

My attempt on Cloud Resume Challenge in 2026

Table Contents

About the project

My suggestions before getting started

How much time I spent

Reflection

Project Architecture

Lambda Function

DynamoDB

DynamoDB provides serial writes at the item level

Prevent throttled concurrent writes via client retries

API Gateways

API Throttling

Terraform (IaC)

Remote State + Locking

Always pin versions

Use HCP Terraform for automated terraforming (CI/CD)

Security

OIDC

TLS

Adding Human Verification Process

Git Repo

More advanced features

What Makes a Winning Hackathon Project? A Judge’s Perspective

`this` Used In Objects

Takeaway

Learn From Mistakes I Made With `this` in JS

Use arrow function

Use bind

Explicitly evoke speak()

Takeaway

React Callback Refs

Introducing Callback Refs

Bonus

Create React App From Scratch With Isomorphic Rendering

Isomorphic rendering/Server-side rendering

Project Structure

Client side logic

Server side logic

Using ECMAScript in Node

Babel transpiles your code without type checking, type check your code with typescript

Use `bind`