DEV Community: Aoda Zhang

How to sharing TypeScript codes Across Frontend and Backend in a Monorepo

Aoda Zhang — Thu, 25 Dec 2025 15:02:25 +0000

Background

In my monorepo project, pawHaven, the frontend and backend are not completely isolated systems.

They naturally share a portion of code, including:

Constants
Configuration schemas
Enums and dictionaries
Pure utility functions

It seemed natural to extract these common pieces into a shared package and use it across both frontend and backend.

Initially, this architecture appeared almost trivial to implement.

With TypeScript, pnpm workspaces, and a monorepo already in place, it felt like everything was aligned.

When the Problems Started

The real issues did not appear while writing the shared code, but when running the applications.

After building the frontend and backend separately, I started encountering errors:

Node reported Unexpected token 'export'
Frontend builds succeeded but failed at runtime
Some modules were reported as missing
CommonJS could not handle ESM syntax

Although these errors seemed random, the underlying issue was clear:

Frontend and backend expect completely different module systems.

My Initial Wrong Assumption

I initially assumed it would be possible to produce a single build output compatible with both CommonJS and ESM.

I spent days experimenting with:

module: ESNext
module: CommonJS
"type": "module"
Different moduleResolution strategies
Various tsconfig combinations

After nearly three days of trial and error, it became clear:

A single build output cannot satisfy both CommonJS and ESM.

These two targets are fundamentally incompatible.

The Key Shift in Thinking

The breakthrough came from a simple question:

Why must a shared package produce only one output?

Frontend and backend environments are inherently different:

Environment	Module Expectation
Frontend (Vite/Webpack)	ESM
Node backend (Nest/require)	CommonJS

Thus, the correct approach is to produce separate builds for each environment rather than compromise with a single artifact.

1. One Source of Truth

The shared package maintains a single source code base written in TypeScript using ESM syntax.

All code resides in a single src directory and uses standard export statements.

2. Two TypeScript Configurations, Two Targets

The package uses two separate TypeScript configurations:

packages/shared/
├─ tsconfig.esm.json
├─ tsconfig.cjs.json

One configuration for ESM output targeting frontend and bundlers
One configuration for CommonJS output targeting Node.js backend

This setup produces:

An ESM build for frontend and bundlers
A CommonJS build for Node.js backend

// tsconfig.cjs.json
{
  "extends": "@pawhaven/tsconfig/base",
  "compilerOptions": {
    "outDir": "dist/cjs",
    "module": "CommonJS",
    "moduleResolution": "node"
  },
  "exclude": ["node_modules", "dist"]
}

// tsconfig.esm.json
{
  "extends": "@pawhaven/tsconfig/base",
  "compilerOptions": {
    "outDir": "dist/esm",
    "module": "ESNext",
    "moduleResolution": "bundler"
  },
  "exclude": ["node_modules", "dist"]
}

3. Precise Entry Resolution via `package.json`

{
  "name": "@pawhaven/shared",

  "main": "./dist/cjs/index.js",
  "module": "./dist/esm/index.js",
  "types": "./dist/index.d.ts",

  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/esm/index.js",
      "require": "./dist/cjs/index.js"
    }
  }
}
![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yi9mvpqhkigfvr8f26ri.png)

The package.json defines which build is loaded for different consumers:

main points to the CommonJS build for Node.js (require)
module points to the ESM build for bundlers (import)
types points to the TypeScript declaration files for type checking

The exports field ensures precise resolution:

Usage	Field	Output
`import`	`exports.import`	ESM build
`require`	`exports.require`	CommonJS build
TypeScript	`exports.types`	Declaration files

This guarantees both frontend and backend receive the correct implementation without runtime checks or environment variables.

Understanding `main`, `module`, and `types`

main: Used by Node.js in CommonJS mode; loaded when calling require().
module: Used by bundlers to indicate an ESM entry point and enable tree-shaking; ignored by Node.js runtime.
types: Used by TypeScript at compile time; provides type declarations for both frontend and backend; independent of runtime.

Why This Approach Is Stable

Module selection happens at module resolution time, not runtime.

Benefits:

No conditional logic in application code
No environment-dependent hacks
Fully deterministic builds across local and CI environments

Final Thoughts

These three days of trial and error taught me a crucial lesson:

The challenge of shared packages in a monorepo is not code reuse, but defining clear module boundaries.

A robust shared package should provide:

A single source of truth
Multiple explicit build outputs
Consumption strictly controlled via exports

Trying to fit all environments into a single artifact leads to conflicts.

The dual-build strategy is one of the most reliable and maintainable patterns for shared modules in large-scale monorepos.

If you want to see this in practice, feel free to check out my real-world monorepo project for stray animal rescue. pawhaven-sahred

From Pain Points to Practice: Monorepo Architecture in PawHaven

Aoda Zhang — Fri, 17 Oct 2025 14:27:24 +0000

In modern full-stack projects, frontend, backend, shared libraries, and utility scripts are often tightly interwoven. As features grow and teams expand, using multiple independent repositories (polyrepo) can lead to several challenges:

Inconsistent versions of shared modules
Confusing imports and mismatched types
Difficulty keeping cross-project refactors consistent
Scattered and hard-to-maintain configuration

Against this backdrop, Monorepo—keeping multiple sub-projects in a single repository—becomes an attractive solution.

However, it’s a misconception that Monorepo fits all projects. In this article, we will cover:

Suitable scenarios for Monorepo
Why PawHaven chose Monorepo
Architecture design and directory structure
Configuration reuse practices

1. When is Monorepo Suitable?

Monorepo has clear boundaries for its effectiveness. The following scenarios benefit the most:

Scenario	Reason
Multiple tightly-coupled sub-projects/modules	Need to share types, DTOs, utilities, etc.
Frequent cross-module changes/refactoring	One commit can update multiple packages simultaneously
Team coordination is manageable	Frequent inter-module collaboration
Desire for unified CI/CD pipelines	Shared pipelines, caching, and dependency management
Want to reuse configuration and toolchains	Centralized management for ESLint, tsconfig, styles
Reduce version conflicts	Shared dependencies are easier to align in one repo

Situations where Monorepo may not be suitable:

Small projects with simple module relationships
Modules with almost no shared logic
Significantly different tech stacks making unified config difficult
Distributed teams requiring strict permission separation

Challenges to be aware of:

As the repository grows, build, clone, and CI times may increase.

Access control, dependency boundaries, and tooling also become more complex.

✅ Conclusion: Monorepo isn’t inherently “better” or “advanced”; it should be adopted after carefully weighing the benefits against the added complexity.

2. Why PawHaven Chose Monorepo

PawHaven is a full-stack project consisting of React frontend + NestJS backend + shared libraries. The decision to adopt Monorepo was driven by several factors:

1. Shared Types, DTOs, and Utilities

Interfaces, constants, and types shared between frontend and backend can be maintained in a single repository. TypeScript path aliases or workspace references avoid duplicate maintenance.

2. Unified Configuration Management

Centralized management of ESLint, tsconfig, Tailwind, etc., allows sub-packages to inherit configurations directly, maintaining consistency and reducing maintenance costs.

3. Cross-Package Changes in a Single Commit

When shared components, DTOs, or backend interfaces need synchronized updates, a single PR can handle all changes, ensuring compatibility.

4. Centralized CI/CD Pipeline

Build, test, and deployment processes are defined once at the repo level, with shared caching and toolchains, simplifying continuous integration.

5. Dependency Hoisting and Version Consistency

Using pnpm's hoist mechanism, all sub-packages share the same dependency versions, minimizing conflicts.

6. Single Entry Point Reduces Communication Overhead

For an open-source project, having one repository means developers, documentation, and promotional materials only need to focus on a single source, reducing coordination overhead across multiple repos.

3. Monorepo Structure Design & PawHaven Example

Design Principles

Separation of business and non-business code: Clearly distinguish deployable apps from shared libraries
Centralized configuration: ESLint, tsconfig, Tailwind maintained in independent config packages
Consistent structure: Each sub-package follows uniform directory conventions (src/, tsconfig.json, package.json)
Simplified imports: Use alias/workspace references instead of deep relative paths
Toolchain compatibility: Build, type-check, and lint processes cover cross-package paths

🧭 PawHaven Directory Structure

├─ pnpm-lock.yaml
├─ pnpm-workspace.yaml
├─ apps
│  ├─ backend
│  │  ├─ gateway
│  │  ├─ ms-auth
│  │  ├─ ms-document
│  │  └─ ms-pawhaven
│  └─ frontend
│     ├─ user
│     └─ admin
├─ packages
│  ├─ shared-frontend
│  ├─ i18n
│  ├─ shared-backend
│  ├─ theme
│  └─ ui
├─ libs
│  └─ configs
│     ├─ eslint-config
│     └─ tsconfig
├─ .vscode/
│  ├─ settings.json
│  └─ extensions.json

Directory Explanation:

apps/: Independent frontend and backend business modules
packages/: Shared modules related to business (UI, theme, i18n, shared types)
libs/: Utility and configuration libraries, can be independently published

4. Unified Configuration (ESLint / tsconfig / Tailwind)

1️⃣ ESLint

Goal: Provide consistent rules for both Web and Node environments.

Implementation:

Centralized ESLint configs in libs/configs/eslint/
Separate configs for Web (eslint-config-web) and Node (eslint-config-node)
Sub-packages inherit and can override rules as needed

📦 Reference: PawHaven/libs/eslint

2️⃣ tsconfig

Goal: Unified TypeScript compilation options with support for multiple targets (Web/Node).

Implementation:

Base configuration in libs/configs/tsconfig/base.json with environment-specific extensions
Sub-packages only override output paths, rootDir, or other necessary options

📦 Reference: PawHaven/libs/tsconfig

3️⃣ Tailwind Design System

Goal: Ensure consistent styling across all frontend packages and UI components.

Implementation:

Centralized design tokens and global Tailwind config in packages/theme/
Shared theme between UI library and frontend apps
Ensure content scanning paths include shared component files

📦 Reference: PawHaven/packages/theme

5. Conclusion

PawHaven’s Monorepo architecture enables:

Centralized multi-module management and collaboration
Unified ESLint, TypeScript, and Tailwind configurations
Shared types and consistent dependencies between frontend and backend
Improved development efficiency and maintainability

✅ Key Takeaway: Monorepo is not about being “advanced” but about achieving coordination.

Careful evaluation of project scale, team structure, and maintenance costs is essential before adoption.

💡 Further Reading & Open Source Practice

For more enterprise-level full-stack, frontend, backend, and Monorepo practices, you can Star or Watch the repository:

👉 https://github.com/aoda-zhang/PawHaven

💻 Doing Something Good with Code

Aoda Zhang — Tue, 07 Oct 2025 06:32:48 +0000

We write code every day to make products faster, features cooler, and systems more efficient.

But what if code could also make the world a little softer?

🐾 A Stray Cat Changed Everything

One rainy night, my wife (a veterinarian) and I heard a faint “meow—meow—” in a dark alley.

We found a tiny, soaked kitten, shivering and exhausted. I wrapped it in my jacket and drove through the rain to an open animal hospital.

The vet said it was severely dehydrated. We stayed on the cold floor until morning.

My wife whispered:

“Some people treat animals like family.

Others treat them like trash.”

That night, I wondered — could I use code to make a difference?

🏠 Our Two Cats

A few months later, our family grew by two:

One abandoned at a clinic
One found tangled in a plastic string next to a trash bin

Now they’re healthy and spoiled, sleeping next to my keyboard or on the balcony.

Every time I watch them nap peacefully, I know — this is worth it.

💡 From Rescue to PawHaven

Over the years, we rescued more animals, but always faced the same problems:

📍 Didn’t know who nearby could help
📷 No easy way to record or share rescue info
💬 Everything relied on private chats or social media

So I built PawHaven 🐕 — “a safe haven for paws”.

On PawHaven, you can:

📸 Upload photos of rescued animals
📍 Mark their location
📖 Record rescue stories
🤝 Connect with volunteers, vets, and rescuers nearby

A space where kindness travels faster.

💻 The Technical Side

PawHaven is a React + Node.js (NestJS) full-stack open-source project.

⚙️ Frontend – React + TypeScript + pnpm monorepo
🧩 Backend – NestJS microservices
🚀 Deployment – Azure Kubernetes + GitHub Actions CI/CD

Developers can learn practical full-stack practices — from monorepo design and RPC communication to CI/CD and cloud deployment.

Where code meets compassion.

🌈 In the End

No funding, no ads — just a small dream from a developer who loves animals.

If you believe technology can make the world a little better:

🌟 Check out PawHaven

Give it a Star ⭐️, share it, or contribute a PR.

Sometimes, a single line of code can help save a life 🐶🐱

Thoughts and Practices on Enterprise-Level Project Architecture — A Case Study of PawHaven

Aoda Zhang — Wed, 01 Oct 2025 05:48:42 +0000

PawHaven is an open-source full-stack project built with React and Node.js. With this project, you can learn how to build an enterprise-grade application from scratch — covering everything from frontend and backend development to CI/CD pipelines and cloud deployment, along with best practices at every stage.

This article is based on the architecture and practical experience of PawHaven. If you’d like to explore more runnable code examples, feel free to check out the GitHub Repository and give it a star ⭐️.

1. Project Background and Design Goals

PawHaven at the design stage, I defined several key goals:

High scalability: New feature modules such as a donation system, volunteer management, and mobile applications may be added in the future.
High maintainability: Support long-term operation and multi-developer collaboration, reducing maintenance costs.
Contributor-friendly for global developers: The project is open source and may attract contributors from different regions. The code structure must be clear and standardized for quick onboarding.

These goals determined that PawHaven could not follow a temporary, scattered project structure and must adopt an enterprise-level architecture from the start.

2. Common Project Structures and Their Limitations

2.1 Traditional “Functional-Type” Structure

Many tutorials recommend a structure like this:

src
├─ components
├─ assets
├─ pages
├─ utils
├─ apis
├─ store

Advantages: Simple and intuitive, suitable for small projects or rapid prototyping.

Limitations:

Scattered logic: Code for a single business module may be spread across pages, store, components, and services.
High modification cost: Every time a feature needs to be modified or debugged, files must be searched in multiple directories.
Blurred business boundaries: Modules can become coupled, reducing team efficiency and making division of work difficult.
Difficult to scale: Adding new features often requires creating files in multiple directories.
Hard to maintain: In large legacy projects, this structure significantly increases maintenance costs and communication overhead.

2.2 DDD (Domain-Driven Design) Pattern

Complex enterprise projects usually adopt Domain-Driven Design (DDD):

Top-level directories are business modules (features)
Each feature contains all related logic: components, pages, state, services, types
Shared modules only contain cross-feature reusable functionality

Advantages:

Self-contained modules: modifying a feature does not require searching across directories
Clear business boundaries: team members can independently develop or test modules
High scalability: new business modules can be added smoothly
Easy maintenance: reduces coupling and improves readability

2.3 PawHaven’s DDD Implementation

In PawHaven, the frontend uses a feature-first directory design:

user
├─ src
│  ├─ features
│  │  ├─ RescueDetail
│  │  │  ├─ index.tsx
│  │  │  ├─ types.ts
│  │  │  ├─ rescueDetailSlice.ts
│  │  │  ├─ components
│  │  │  │  ├─ RescueTimeline.tsx
│  │  │  │  ├─ AnimalBasicInfo.tsx
│  │  │  │  └─ RescueInteraction.tsx
│  │  │  └─ apis
│  │  │     ├─ queries.ts
│  │  │     └─ request.ts
│  │  ├─ ReportStray
│  │  │  ├─ index.tsx
│  │  │  ├─ types.ts
│  │  │  ├─ constants.ts
│  │  │  ├─ reportStraySlice.ts
│  │  │  ├─ components
│  │  │  │  └─ ReportForm.tsx
│  │  │  └─ apis
│  │  │     ├─ requests.ts
│  │  │     └─ queries.ts

Each feature (e.g., RescueDetail, ReportStray) contains:

Components (components)
Pages (index.tsx)
State management (slice)
API requests (apis)
Type definitions (types.ts)
Constants (constants.ts)

This design ensures each business module is highly self-contained, facilitating independent development and maintenance by team members.

3. Component Layering Strategy

In enterprise projects, as features grow more complex, DDD alone is not enough. A layering strategy is needed. In PawHaven, layering applies not only to UI components but to all code units, including hooks, services, and utility functions.

PawHaven’s layering strategy:

3.1 Feature Layer (Internal to Feature)

Closely tied to business logic
Contains pages, business components, hooks, services, types
Example: report-animal/ReportForm.tsx, report-animal/hooks/useReportAnimal.ts

3.2 Cross-Feature Layer (Application Level)

Shared across multiple features but still contextually tied to business
Examples: user info cards, navigation menus, layout components, cross-feature hooks
Located at the application level, outside individual features

3.3 Shared Layer (Business-agnostic)

Completely decoupled from business logic
Includes UI dumb components (Button, Modal, Input), utility functions, generic hooks, constants, theme configs, internationalization text, etc.
Reusable across the entire monorepo and can be easily extracted into independent libraries

This layering strategy ensures clear business boundaries while maximizing code reuse, achieving high scalability and maintainability.

4. Monorepo vs Multi-Repo

In enterprise projects, managing multiple apps and modules is a key decision. Common approaches are Multi-Repo and Monorepo.

4.1 Multi-Repo

Each service or business has a separate repository, with tool libraries in their own repos
Advantages: independent repositories, clear permission control, low initial learning curve
Disadvantages: hard to share code, scattered dependencies, complex cross-repo refactoring
Examples: Netflix, Spotify microservices

I have personally experienced the pain of Multi-Repo, where synchronizing shared code across projects was manual and error-prone, and frequent switching between repos reduced development efficiency.

4.2 Monorepo

Multiple apps, services, and libraries are managed in a single repository
Advantages: easy code sharing, unified dependencies and rules, simple cross-project refactoring, improved developer experience
Disadvantages: requires more advanced tooling; build and test processes need optimization
Examples: Google, Meta, Uber, Airbnb

4.3 Why PawHaven Chose Monorepo

Considering PawHaven’s development roadmap:

Multiple frontend apps: user app (pawHaven), admin panel (admin), auth app (auth)
Multiple backend microservices (NestJS) and shared packages
Potential global contributors requiring a clear, standardized structure

Monorepo is therefore the most suitable choice.

Directory structure:

PawHaven-frontend/
├── apps/                  # Applications
│   ├── user/              # User app
│   ├── admin/             # Admin app
├── packages/              # Shared modules
│   ├── components/
│   ├── hooks/
│   ├── utils/
│   ├── constants/
│   ├── theme/
│   ├── i18n/
│   └── api-client/
├── package.json
└── pnpm-workspace.yaml

4.4 Why pnpm Workspace

There are multiple Monorepo tools (Lerna, Nx, Turborepo). I chose pnpm workspace for:

Fast installation: hard links and content-addressable storage save disk space and time
Strict dependency isolation: avoids “phantom dependencies”
Native workspace support: lightweight, simple configuration
Enterprise compatibility: widely adopted in large companies and community projects

Example configuration:

# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'packages/*'

This setup allows multiple frontend or backend services to collaborate in a single repository while maintaining independent build and deployment pipelines.

5. Summary

PawHaven demonstrates that enterprise-level architecture is not just about organizing code—it’s about scalability, maintainability, and team efficiency.

From the start, PawHaven adopted a DDD / Feature-first approach with self-contained modules, ensuring clear business boundaries; combined with a component layering strategy (Feature layer, Cross-Feature layer, Shared layer) to maximize reuse; and implemented Monorepo + pnpm workspace to unify frontend, backend, and shared modules while keeping responsibilities separate.

This architecture not only facilitates current development but also lays a solid foundation for future feature expansion, team collaboration, and global contributor participation.

Ultimately, PawHaven provides a practical example of building an enterprise-level full-stack project from scratch: define clear boundaries, structure layers effectively, reuse shared modules, and unify management for sustainable long-term operation.

That Weird Font Size Bug: A Deep Dive into Browser Settings and Front-End Font Strategies

Aoda Zhang — Fri, 26 Sep 2025 05:52:14 +0000

PawHaven is an open-source full-stack project built with React and Node.js. With this project, you can learn how to build an enterprise-grade application from scratch — covering everything from frontend and backend development to CI/CD pipelines and cloud deployment, along with best practices at every stage.

This article is based on the architecture and practical experience of PawHaven. If you’d like to explore more runnable code examples, feel free to check out the GitHub Repository and give it a star ⭐️.

A few days ago, I stumbled upon a bug that, at first, looked pretty trivial — but it ended up teaching me a lot about how browsers handle fonts.

One of our QA testers told me: “Hey, this page’s font size looks wrong.” I checked the page myself and everything looked fine. Fonts matched the design specs perfectly. For a second, I honestly thought they were mistaken.

But then I asked them to share their screen. Boom — on their machine, the font size was 20px, while on mine it was 16px. Same page, totally different look.

At that point, I knew something funky was going on. I switched to another browser, and sure enough, the bug showed up again. After a bit of digging, I realized the culprit: Chrome’s default font size setting. Turns out, Chrome (and other browsers) let users customize their default font size, and if you’re using rem without defining a root font-size, your entire design can shift.

The Core of `rem`: It All Starts with the Root

Here’s the deal: rem units depend on the root element’s font-size.

If you explicitly define it, like this:

html { font-size: 16px; }
body { font-size: 16px; }

then your design is safe — user browser settings won’t mess with it. But if you don’t, you’re leaving it up to the browser.

Different Sites, Different Philosophies

Curious, I went down the rabbit hole and checked a few popular websites to see how they handle this.

GitHub & YouTube

Their font sizes don’t change when you tweak the browser’s font settings. They’ve locked down the root font-size, which guarantees pixel-perfect consistency. Makes sense for design-driven products where brand identity matters a lot.

Shopify

On the flip side, Shopify actually responds to browser font settings. If you bump up your default font size, their site adjusts accordingly. That’s a user-first, accessibility-friendly approach.

Neither is “right” or “wrong.” It’s all about what the product values more: consistency or accessibility.

Accessibility vs. Consistency: The Eternal Trade-Off

So here’s the big question: Should we let users change font sizes through their browser settings?

From an accessibility perspective, yes! It helps people with vision impairments and respects their reading habits.
From a design/brand perspective, not so much. Changing font sizes can break layouts, shift components, and ruin carefully crafted visuals.

👉 My takeaway:

Content-driven sites (blogs, e-commerce) → better to respect user settings.
Design-driven products (brand sites, design tools) → safer to lock fonts for consistency.

Designers vs. Developers: The px → rem Struggle

If you’ve worked on front-end projects, you probably know this pain: designers hand over mockups in px, but developers often need to translate them into rem. That conversion step is error-prone and slows everyone down.

What’s worked for me:

Decide early whether you want to support user font scaling.
If you go with rem, ask designers to also use rem or at least provide conversion references.
Keep units consistent across design and code.
Document your project’s font strategy upfront (seriously, this saves so many headaches later).

Wrapping Up: What This Bug Taught Me

That one “tiny” bug turned into a pretty valuable lesson:

Browser settings can unexpectedly affect your UI.
If you’re using rem, always define the root font-size.
Accessibility and consistency are often at odds — you have to pick what matters for your product.
The way big sites (GitHub, YouTube, Shopify) handle fonts reflects their product philosophy.
Aligning designers and developers early on avoids painful conversions and layout issues.

My personal rule of thumb:

If your product needs to look exactly like the design mockups → set root font-size explicitly.
If your product leans toward accessibility → let the browser handle it.

This whole experience reminded me that even “small” bugs can uncover bigger product questions. Fonts aren’t just about styling — they’re about philosophy: who are you optimizing for, the brand or the user?

And honestly, that’s the kind of stuff that makes front-end dev both challenging and fun. 🚀

💡 Have you ever run into font-size issues caused by browser settings? How did you handle it?

Let me know in the comments — I’d love to hear your take!

👋 Hi, I’m Aoda — Excited to Join dev.to!

Aoda Zhang — Thu, 25 Sep 2025 10:16:50 +0000

PawHaven is an open-source full-stack project built with React and Node.js that i am building. With this project, you can learn how to build an enterprise-grade application from scratch — covering everything from frontend and backend development to CI/CD pipelines and cloud deployment, along with best practices at every stage.

If you’d like to explore more runnable code examples, feel free to check out the GitHub Repository and give it a star ⭐️.

Hello everyone!

I’m really happy to finally write my very first post here on dev.to. Since this is my introduction, let me share a bit about who I am, what I’m working on, and what I hope to learn and give back to this amazing community.

🧑‍💻 Who am I?

I’m Aoda, a software developer who has been building with JavaScript for many years. I enjoy turning ideas into digital products and exploring how technology can improve everyday life. Over the years, I’ve worked with React, Node.js, NestJS, TypeScript, and various tools for frontend/backend architecture, monorepos, and cloud deployment. more about me

But beyond the tech stack, what excites me most is problem-solving and sharing knowledge—whether it’s through open-source projects, technical writing, or community discussions.

🐾 What I’m working on

Currently, I’m creating PawHaven, an open-source platform designed to help stray animals.

A place where people can share information about rescues and adoptions,
connect with others who care about animals, and
hopefully, make a real-world difference.

This project challenges me not only technically (React, Node.js, Kubernetes, CI/CD, i18n, etc.) but also personally—it’s about combining code with compassion.

🎯 Why I’m here

I joined dev.to because I believe in learning in public. Writing about the challenges I face (and solutions I find) not only helps me grow, but also hopefully helps someone else who might run into the same issues.

I’ll be sharing posts about:

Open-source journey building PawHaven
Frontend architecture patterns in React
DevOps practices for small projects
Reflections on tech, learning, and career growth

🤝 Let’s connect!

I’d love to hear from you—whether you’re working on similar projects, curious about modern JavaScript stacks, or just want to chat about animals 🐕🐈.

Thanks for reading my first post here. I’m really looking forward to learning from this community and contributing my part!

⭐ Support PawHaven

If you find PawHaven interesting, I’d be grateful if you could check it out and give it a star on GitHub. Your support will help this open-source project reach more people and, hopefully, create more possibilities for stray animals in need.

🔗 Frontend Repo

🔗 Backend Repo

AI-Era Philanthropic Practice: From Inspiration to the Exploration of PawHaven

Aoda Zhang — Tue, 23 Sep 2025 13:18:26 +0000

PawHaven is an open-source full-stack project built with React and Node.js. With this project, you can learn how to build an enterprise-grade application from scratch — covering everything from frontend and backend development to CI/CD pipelines and cloud deployment, along with best practices at every stage.

This article is based on the architecture and practical experience of PawHaven. If you’d like to explore more runnable code examples, feel free to check out the GitHub Repository and give it a star ⭐️.

During the widespread AI revolution, new ideas are easy to come by—but "technology with a heart" that actually works needs something to keep it grounded. For me, that grounding came from real moments with my wife. She’s both a vet and a dedicated animal lover: how focused she is when treating hurt stray cats late at night, how worried she gets when finding foster homes for abandoned puppies, and how helpless she sounds when she says, "One person can’t rescue that many animals"—these small daily moments made me ask: Can AI help spread kindness, so more people can join in rescuing stray animals?

As someone who works with technology, I’m used to breaking down problems step by step. The main problems in stray animal rescue are basically two things: "not enough shared information" and "hard to join in": rescuers can’t find animals that need help, people who want to help don’t know where to start, and no one can see how rescue efforts are going. So, the first version of PawHaven started to take shape. It’s not just a "place to write down things," but a tech tool that connects "people who want to help" with "animals that need help"—and it’s my first try at mixing tech work with my wish to do good. Right now, PawHaven is still being tested and improved, but this process has already shown me clear ways AI can help with charity work.

1. From Inspiration to Requirements: AI Turns "Vague Ideas" into "Clear Scenarios"

Inspiration comes from life, but turning the fuzzy thought of "wanting to help stray animals" into real product features means figuring out exactly what users need. At first, I tried getting info from public groups (like pet rescue forums and Xiaohongshu’s stray animal topics), but sorting through all those talks by hand often left me with a mess of repeated or messy info—this is where AI really helped.

When I was gathering what the product needed, AI worked like a "fast organizer":

Finding main problems: After I put over 2,000 community talks into AI, it quickly found three big issues: "rescue info is all over the place (stray animals in the same area get reported many times)," "hard to match volunteers (people want to help but can’t find nearby rescue spots)," and "no way to see rescue progress (people donate supplies but don’t know where they go)"—this helped me avoid making features that no one actually needs.
Sorting user needs: It automatically grouped needs by "what kind of user you are"—people who start rescues (need to report animals and track progress), volunteers (need to sign up and get tasks), and regular users (need to donate or follow updates)—so the product’s features fit each group better.
Filling in missing parts: For the "adoption process," AI used examples from other charity products to add details like "showing animal health papers publicly" and "checking if adopters are a good fit first"—this stopped me from missing important steps because I didn’t have enough experience.

But I always stuck to one rule: AI gives "ideas to check," not "final answers." For example, AI once suggested adding "AI that automatically tells an animal’s breed," but I thought, "In rescue work, breed doesn’t matter—health does." So I put that feature on hold and first made an "injury note template" (to help non-experts write down an animal’s injuries quickly).

2. Technical Feasibility Verification: AI Helps with "Trying Things Out," Humans Control the "Important Parts"

After figuring out what the product needs, the next step is to check if "the tech can actually be built." Since I’m working on this project alone, I needed to quickly test which features "can be made and are useful" without spending too much time. AI’s job here was to "make it easier to fix mistakes," but the key tech choices were still mine.

In practice, I did two things:

First, build a "simple working version": I used React + Node.js to make an MVP (Minimum Viable Product)—a basic version with three key features: reporting stray animal info (with location tags), a volunteer sign-up page, and updating rescue progress. I didn’t use AI here because basic features have simple, well-known tech solutions, and making choices myself was faster.
Then, use AI to find "ways to make it better": I put the MVP’s steps (like filling out a report form or checking rescue progress) into AI and asked it to act like a "new user." It found two problems: first, choosing a location meant switching to a map app (which was a hassle), and second, rescue status words were too hard to understand (like "pending transfer"). Using this feedback, I made address selection easier (letting people type in addresses or use auto-complete) and changed status words to simpler ones (like "waiting to go to a rescue station").

Also, for the key feature of "matching volunteers by location," AI helped me compare two tech options: using a third-party map tool (good because it’s ready to use, bad because it costs money) vs. saving location data locally (good because it’s free, bad because it’s not super accurate). Since the project is "non-commercial and cheap," I chose the free option—prioritizing "rough location matching" and planning to make it more accurate later if I get more resources.

3. UI Design and Experience Optimization: AI Makes "First Drafts," Humans Fix the "Small Things"

A charity product’s design doesn’t need to be "fancy," but it must be "warm and easy to use." For example, photos of stray animals should look real (not over-edited), and buttons should be clear enough for both old and young users. But as a developer without design training, I often struggled with making things look good and easy to use—this is when AI became a "fast draft helper."

Here’s how I worked with AI:

Set the style, AI makes drafts: First, I told AI I wanted a "warm, simple" look: "A stray animal rescue platform, main colors soft orange + white (no cold colors); rounded buttons to feel friendly." It quickly made 3 homepage layouts (different ways to show info lists and report buttons), so I didn’t have to start drawing from nothing (which saves time).
Fix small details myself: AI’s first draft had a "report button" that was too bright (a loud red, which felt pushy), so I changed it to a softer orange-red. Also, AI put "animal injury info" at the bottom of the page—but since injury info is super important for rescues, I moved it under the animal’s photos to show it first.
Use AI to help with different devices: For "responsive design" (making it work on phones and computers), AI automatically suggested layout changes for different screen sizes—like hiding side menus on phones (using bottom tabs instead) and adding "rescue count cards" on computers (to show how many animals have been rescued).

The current design is still a "test version," but compared to designing everything by hand, AI saved me at least 40% of the time—letting me focus on "testing how easy it is to use." For example, when I asked pet lovers to try it, they said that after adding "batch photo upload," we needed a "preview and delete" button. AI didn’t think of this, which made me realize: "How easy a product is to use" finally depends on "real users’ feedback"—AI can only give suggestions.

4. Summary and Future Outlook: AI is a "Tool," Philanthropy is the "Heart"

Looking back at how PawHaven was built, AI has really been a helpful "assistant": it helped me sort needs quickly, made it easier to fix tech mistakes, and made design simpler—so I could turn a personal project into a test version fast. But I know clearly that AI can’t replace the "heart of charity": caring about stray animals, respecting what users need, and knowing which features matter.

Right now, there are still many things to test for PawHaven:

Short-term: Make "rescue record keeping" better (letting users upload medical reports and supply lists) so everyone can see how things are going.
Mid-term: Try "AI that helps check injuries at first" (users upload animal photos, and AI says, "Possible injuries—check the legs first") to help non-experts write down key info fast.
Long-term: Make a "volunteer trust system" (matching reliable volunteers based on how often they help and feedback) to fix the problem of "people signing up but not showing up" in charity work.

But no matter how tech changes, one rule will stay the same: PawHaven’s main job is "connecting people"—linking those who want to help with animals that need it. AI just makes this connection faster and warmer.

5. Participation and Support: Inviting "Fellow Helpers" to Improve Together

Right now, PawHaven is still a "test version"—it hasn’t been launched widely, and there are no plans to make money from it. If you, like me, believe "tech can help charity work," you’re welcome to join in these ways:

For developers: The project code is open-source FrontEnd and BackEnd. If you have ideas to make the code better, please submit a PR. Developers who know about "location matching" and "multilingual support" are especially welcome.
For volunteers/rescue groups: You can test the test version and share feedback on "which features work and which don’t" in real rescue work—like whether you need a "temporary foster info page" or a "rescue supply connection" tool.
For regular users: You can star the project to follow updates. When the platform launches later, every time you "report an animal" or "share a rescue update," you’ll be helping stray animals.

Charity has never been "one person’s job," and tech isn’t just "cold code." I hope PawHaven can be a "starting point"—bringing more people to use their skills (tech, time, resources) to do more for stray animals. Even if it just helps one stray cat avoid one night of hunger or one injury, it’s worth it.