DEV Community: Hank Chiu

My Spec-Driven Development Experience: Building a Next.js and Nest.js Full-Stack Project

Hank Chiu — Tue, 23 Sep 2025 05:18:35 +0000

Original post: https://hankchiu.tw/writings/my-spec-driven-development-experience-building-a-next-js-and-nest-js-full-stack-project/

How I transformed copilot-proxy into a modern full-stack application Coxy using workflow-first development, AI-assisted coding, and systematic specifications

Recently I tried spec-driven development to build Coxy, a complete rewrite of my previous copilot-proxy project. The experience taught me valuable lessons about modern development workflows, AI integration, and sustainable architecture decisions. Here's why I made the switch, how I approached it, and what I learned along the way.

Why I Rewrote copilot-proxy

Technical Limitations of the Original Project

The original copilot-proxy was built with SolidStart, which seemed like a good choice initially but created several challenges:

Framework Maturity Issues: SolidStart is lightweight and performant, but its ecosystem isn't as mature as Next.js. I spent considerable time debugging build processes and working around framework limitations instead of focusing on features. The time investment in tooling troubleshooting outweighed the framework's benefits.

Monolithic Architecture Problems: I had combined frontend and backend implementations in a single codebase, which initially seemed efficient but quickly became messy. As the proxy management features grew more complex, maintaining clear separation between API logic and UI components became increasingly difficult. This architectural decision made testing, deployment, and scaling problematic.

Development Experience Friction: The build process was unpredictable, dependency management was complex, and the development workflow felt fragmented. These friction points slowed down iteration cycles and made the project less enjoyable to work on.

The Opportunity for Spec-Driven Development

Beyond addressing technical limitations, I wanted to experiment with spec-driven development methodology. This approach promised several advantages:

Clearer requirements definition before writing code
Better AI collaboration through structured prompts and specifications
More maintainable architecture with documented decision rationales
Systematic approach to feature development reducing scope creep

The rewrite presented a perfect opportunity to implement these methodologies from the ground up, rather than retrofitting them onto existing code.

My Spec-Driven Development Strategy

Workflow-First Philosophy: Avoiding Vendor Lock-in

My core strategy focused on development workflow optimization rather than tool selection. This philosophy aimed to avoid vendor lock-in with specific AI tools like Cursor or Claude Code, which can limit flexibility as new tools emerge.

Key principles I established:

I determine the workflow, tools adapt to serve the workflow
Documentation drives implementation, not the reverse
Tool-agnostic specifications enable switching between AI assistants
Modular architecture supports different development approaches

This approach meant investing time upfront in workflow design, knowing that I could optimize tool choices later without restructuring the entire development process.

Benefits of Workflow-First Development

The workflow-first approach delivered three key wins: cleaner architecture through upfront planning, faster debugging with systematic processes, and easy tool switching when better options emerged.

Implementation: From Architecture to Features

Nx Monorepo: Scalable Project Structure

I chose Nx as the foundation for Coxy's architecture, primarily to achieve clean separation between frontend and backend concerns that plagued the original copilot-proxy.

Strategic architecture decisions:

coxy/
├── apps/
│   ├── frontend/                # Next.js frontend
│   ├── backend/                 # Nest.js backend
│   └── frontend-e2e/            # End-to-end tests
├── libs/
│   ├── shared/              # Cross-platform utilities
│   ├── ui/                  # React component library
│   ├── logger/              # Centralized logging
│   └── types/               # TypeScript definitions
└── ...

Why this structure worked for Coxy:

Clear boundaries between proxy management UI and API logic
Shared libraries eliminated code duplication across apps
Independent deployments for frontend and backend services
Scalable foundation supporting future microservices architecture

Tooling Optimization: Biome Over ESLint/Prettier

I replaced ESLint and Prettier with Biome for better performance and simpler configuration. Biome reduced setup complexity by 70%, improved build times, and required fewer dependencies to manage. The migration was straightforward with immediate performance benefits.

Spec-Driven Development: USER_STORY.md Files

Following spec-driven development principles, I created comprehensive USER_STORY.md files for each Coxy feature. These documents became the foundation for all development activities.

Example for proxy configuration management:

 # User Story 1: OpenAI-Compatible Proxy Endpoint

As a developer using OpenAI-compatible tools, I want to send requests to a proxy server that forwards them to GitHub Copilot so that I can use GitHub Copilot through existing OpenAI-compatible interfaces.

 ## Acceptance Criteria (EARS):

 - **Given** a valid OpenAI-compatible request, **when** sent to `/chat/completions`, **then** forward to GitHub Copilot API.
 - **Given** an invalid API key, **when** making a request, **then** return `401 Unauthorized`.
 - **Given** a malformed request, **when** sent to the proxy, **then** return `400 Bad Request` with validation errors.
 - **Where** the system acts as a transparent proxy between OpenAI clients and GitHub Copilot.

 ---

 # User Story 2: Admin Dashboard

 As a system administrator, I want an admin interface to monitor and configure the proxy so that I can manage API usage, view logs, and configure settings.

 ## Acceptance Criteria (EARS):

 - **Given** admin credentials, **when** accessing `/admin`, **then** display dashboard with usage statistics.
 - **Given** proxy requests, **when** they occur, **then** log them for admin review.
 - **Given** configuration changes, **when** submitted through admin panel, **then** update proxy behavior.
 - **Where** admin access is protected by authentication.

Project-Wide System Prompt: Development Constraints

I created a comprehensive system prompt that served as both a constraint and development guideline for AI assistance throughout the project:

# Nx Project Refactoring System Prompt

## 1. Persona
You are a senior software architect and Nx expert with extensive experience in monorepo management, dependency optimization, and large-scale refactoring. You have deep knowledge of:
- Nx workspace architecture and best practices
- TypeScript/JavaScript ecosystem and tooling
- Micro-frontend and library design patterns
- Build optimization and dependency graph management
- Code migration strategies for monorepos

## 2. Task Statement
Analyze and refactor code within an Nx workspace to improve maintainability, performance, and adherence to Nx best practices while preserving functionality and minimizing breaking changes.

## 3. Context
You are working within an Nx monorepo that may contain:
- Multiple applications (React, Angular, Node.js, etc.)
- Shared libraries and utilities
- Complex inter-project dependencies
- Existing build configurations and tooling
- Team conventions and coding standards
- CI/CD pipelines that depend on the current structure

This system prompt ensured consistency across different AI tools and development sessions.

AI-Enhanced Development Workflow

Structured LLM Prompt Guidelines

I developed a systematic approach to creating feature-specific prompts using "Structured LLM Prompt Guidelines." This meta-process involved:

Prompt creation workflow:

Analyze USER_STORY.md to extract key requirements
Feed Structured LLM Prompt Guidelines to Claude for refinement
Generate feature-specific prompts tailored to proxy management needs
Test prompts across different AI tools for consistency

Example Structured LLM Prompt Guidelines (partial):

# Structured LLM Prompt Guidelines

## 1. Persona
Specify the role, expertise, or point of view you want the model to adopt.

_Example:_
> You are a senior frontend developer experienced in React and TypeScript.

## 2. Task Statement
Clearly define the main objective or requirement of your prompt.

_Example:_
> Implement a reusable modal dialog component for a web application.

## 3. Context
Provide relevant background information, project details, or the scope of application to ensure the model understands nuances and boundaries.

_Example:_
> The component will be used across multiple pages in a SaaS dashboard built with React, styled using Tailwind CSS, and should support ARIA accessibility attributes.

Example feature prompt for chatting feature (partial):

# AI Chat Feature Implementation Prompt

## 1. Persona
You are a senior React/Next.js developer specializing in real-time chat interfaces and conversational UX design. You have extensive experience building intuitive messaging systems with optimistic UI updates and seamless user experiences.

## 2. Task Statement
Implement the AI chatting feature with a centered input box on the main page that transitions to a dedicated chat session page after the first message is sent, supporting continuous conversation flow with follow-up messages.

## 3. Context
This is part of a larger AI chatbot SaaS application built with Next.js 15, TypeScript, and Tailwind CSS. The chat feature should provide a smooth, intuitive experience where users start with a prominent input box and seamlessly transition into a full conversation interface. The system integrates with an external AI API and uses Clerk for authentication. Users should feel like they're having a natural conversation with instant feedback and proper message handling.

Multi-Tool AI Implementation Strategy

I used Rovo Dev and Gemini CLI as primary implementation tools, chosen for their modern LLM models and generous free quotas.

Development workflow:

Plan Review: AI generates implementation plan based on USER_STORY.md
Architecture Validation: Manual review ensures alignment with Nx structure
Iterative Implementation: Code generation with frequent human oversight
Bug Resolution: Systematic debugging using AI assistance

Why this multi-tool approach worked:

Cross-validation reduced AI hallucinations in complex scenarios
Tool-specific strengths: Rovo Dev excelled at backend logic, Gemini CLI at frontend components
Flexibility: Could switch tools based on feature requirements
Learning opportunity: Compared AI tool capabilities across different use cases

Documentation Synchronization Strategy

A crucial aspect of the workflow was keeping specifications synchronized with implementation:

Periodic documentation updates:

Manual analysis where AI reviewed current code against specifications
Automatic detection of specification-implementation gaps
Document updates reflecting architectural decisions and lessons learned
Prompt refinement based on implementation experience

This process ensured that specifications remained valuable throughout the development lifecycle.

Lessons Learned: What Worked and What Didn't

What Worked Well

Top-down understanding transformed my development approach. Spec-driven development forced systematic thinking about requirements and architecture before implementation, leading to better decisions and more cohesive features.

AI revealed unknown unknowns during planning. When creating proxy management specifications, AI identified edge cases, security considerations, and performance optimizations I hadn't considered, leading to more robust implementations.

Structured specifications accelerated development. Comprehensive USER_STORY.md files enabled AI tools to generate higher-quality initial code. Time invested in specifications paid dividends through faster iteration and fewer bugs.

Challenges That Required Adaptation

Tool switching created mental overhead. Managing different AI tools required energy that could have been spent on development. I learned to batch similar tasks within single tools.

Documentation became a project itself. Organizing specifications and prompts required dedicated time and systematic approaches. Templates and naming conventions helped manage this complexity.

Costs accumulated quickly. AI tool quotas sometimes were exhausted faster than expected. The convenience came with real monetary costs that needed project planning consideration.

Next Steps: SpecKit and Beyond

GitHub SpecKit offers exciting opportunities to formalize my spec-driven approach. I plan to explore SpecKit integration for native GitHub workflow management, automated documentation generation, and standardized specification formats.

For future projects, I'll focus on systematic prompt management with version-controlled prompt libraries, performance tracking, and automated testing. The goal is creating repeatable processes that scale across different projects and team members.

Conclusion: Growing with AI, Not Surrendering to It

Building Coxy with spec-driven development taught me that AI collaboration works best when humans maintain architectural ownership while leveraging AI for implementation speed. Rather than giving complete control to AI tools, the spec-driven approach helped me grow alongside AI capabilities.

The key insight: systematic approaches scale better than ad-hoc AI usage. Structured prompts, comprehensive specifications, and organized workflows produce more consistent results than spontaneous AI interactions. Documentation remains critical while AI generates code quickly, human-created specifications ensure that code serves actual business requirements.

The transformation from copilot-proxy to Coxy represents more than a technology upgrade. It demonstrates how thoughtful AI integration with systematic development practices can elevate both project outcomes and developer capabilities.

Auto-generate Commit Messages with LLMs in Your Terminal

Hank Chiu — Thu, 10 Jul 2025 05:06:19 +0000

Original post: https://hankchiu.tw/writings/auto-generate-commit-messages-with-ll-ms-in-your-terminal/

Writing commit messages can be a drag. While IDEs like Cursor can automate this, what if you live in your terminal and want a fast, controllable way to generate conventional commits?

This guide is for you. It's as simple as piping git diff to a command-line LLM client to create well-formatted commit messages without leaving the terminal.

Quick Summary

Use a non-interactive LLM client: We need a tool that takes input from a pipe, sends it to the model, and prints the result to standard output.
Craft a system prompt: Instruct the LLM to generate a message in the Conventional Commits format.
Create a Git alias: Make the entire process accessible through a simple command like git ca.

The System Prompt

First, let's define our instructions for the LLM. This prompt ensures the output is consistently formatted as a Conventional Commit:

Write a commit message in the Conventional Commits format. Use the structure:
    <type>(<optional scope>): <short description>

    <optional body>

    <optional footer>

Example types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
Optionally, include a body for more details in bullet points.
Optionally, in the footer, use BREAKING CHANGE: followed by a detailed explanation of the breaking change.

Just return the commit message, do not include any other text.

LLM Clients for the Terminal

Several command-line tools can handle this task. Here are a few examples of how to use them, piping your staged changes directly to the model.

LLM CLI

git diff --cached | llm -s '<your-system-prompt>'

Gemini CLI

git diff --cached | gemini -p '<your-system-prompt>'

aichat

git diff --cached | aichat --prompt '<your-system-prompt>'

Claude CLI

git diff --cached | claude -p '<your-system-prompt>'

Create a Git Alias

To make this truly seamless, add an alias to your .gitconfig. This example uses llm to commit all staged changes and then displays the latest log entry.

Place your full system prompt directly into the alias or save it to a file and reference it.

# In your ~/.gitconfig file

[alias]
  ca = "!(git commit -m \"$(git diff --cached | llm -s 'Write a commit message in the Conventional Commits format...')\" && git log --stat -1)"

Now, instead of git commit, simply run:

git ca

Your staged changes will be sent to the LLM, the generated message will be used for the commit, and you'll see the result instantly. It's a quick, powerful way to keep your workflow moving, all from the comfort of your terminal.

Free Claude Sonnet 4 for Local Development: Setting Up Aider with Cody

Hank Chiu — Mon, 16 Jun 2025 16:18:54 +0000

Original post: https://hankchiu.tw/writings/free-claude-sonnet-4-for-local-development-setting-up-aider-with-cody/

Looking to experiment with cutting-edge AI models for coding without breaking the bank? While premium tools like Cursor and Windsurf offer polished experiences, they come with subscription costs that can add up. If you're curious about modern language models but want a budget-friendly way to explore their capabilities, combining Aider with Cody offers an interesting alternative worth considering.

This approach isn't perfect – it comes with limitations and requires more setup than plug-and-play solutions. But for developers who enjoy tinkering and want to experience models like Claude Sonnet 4 without monthly fees, it's a compelling option to explore.

What You're Working With

Aider is an open-source command-line tool designed for AI-assisted coding. Unlike IDE-integrated solutions, it works directly with git repositories, making commits based on natural language instructions. It supports various editors and focuses on making actual code changes rather than just providing suggestions.

Cody is Sourcegraph's AI assistant that powers chat, code completion, and automated code edits. Its free plan includes 200 messages per month with premium models like Claude Sonnet 4. These limits mean this setup works best for occasional experimentation, learning, or small projects rather than heavy daily development. If you're planning to use AI assistance extensively, you'll likely hit these caps quickly. However, for exploring what modern language models can do or handling specific coding challenges, these quotas can be quite useful.

Setting Up Aider with Cody's Cloud Endpoint

The integration process involves connecting Aider directly to Sourcegraph's cloud API rather than running a local Cody CLI instance.

Step 1: Install Aider

Follow the official document, e.g.

python -m pip install aider-install
aider-install

Step 2: Generate Your Access Token
Visit Sourcegraph's token settings page at https://sourcegraph.com/users/<your-username>/settings/tokens and create a new access token. This token authenticates your requests to Sourcegraph's LLM API.

Step 3: Configure Your Project
In your project directory, create two configuration files that tell Aider how to communicate with Sourcegraph's endpoint:

# .aider.conf.yml
openai-api-base: https://sourcegraph.com/.api/llm
openai-api-key: sgp_xxxxx # put your actual access token here
model: openai/anthropic::2024-10-22::claude-sonnet-4-latest

# .aider.model.settings.yml
- name: openai/anthropic::2024-10-22::claude-sonnet-4-latest
  use_system_prompt: false
  extra_params:
      extra_headers:
        X-Requested-With: aider 0.0.0
      max_tokens: 64000

The first file handles basic authentication and model selection, while the second configures specific parameters for optimal performance with Claude Sonnet 4, including the maximum token limit and required headers.

Step 4: Launch and Code
With your configuration in place, simply run aider from your project directory. Aider will automatically use your settings to connect to Sourcegraph's API and give you access to Claude Sonnet 4 within your free usage limits.

Is This Right for You?

This setup works best for developers curious about modern AI models without subscription commitments – students, hobbyists, or those working on side projects. The quota limitations make it unsuitable for heavy daily use, but as an accessible entry point into AI-assisted development, it offers genuine learning value.

Consider it a stepping stone to understand how AI can enhance your coding. Once you've explored the capabilities within these constraints, you can make informed decisions about investing in more comprehensive solutions.

The Paradigm Shift in Web Development for AI-Era: From Client-Side to Server-Side Rendering

Hank Chiu — Wed, 04 Jun 2025 03:21:11 +0000

Original post: https://hankchiu.tw/writings/the-paradigm-shift-of-web-frameworks-in-ai-era-from-client-side-to-server-side-rendering/

The following article, written with AI assistance, explores this topic.
My initial ideas were:

A brief history of the rise of Single-Page Applications (SPAs).
Engineering challenges of client-side rendering for AI-native applications.
How server-side rendering can address these challenges.
Practical tools and libraries for further exploration.

Enjoy the read!

The web development landscape is experiencing a fundamental transformation. As artificial intelligence becomes deeply integrated into web applications, we're witnessing a significant shift away from the client-side rendering dominance that defined the 2010s.

The Rise and Reign of Single Page Applications

The SPA Revolution (2010-2020)

The Single Page Application era began with frameworks like Angular (2010), React (2013), and Vue.js (2014) promising desktop-like experiences in the browser. SPAs offered fluid user experiences with no page refreshes, rich interactivity, and clean separation between frontend and backend.

By the mid-2010s, client-side rendering became the default choice. Several factors drove this adoption:

Improved JavaScript engines made client-side computation viable
CDN proliferation made delivering JavaScript bundles cost-effective
Mobile hardware improvements provided sufficient processing power
Broadband adoption reduced concerns about initial load times

The result was a generation of developers who learned web development through React, Angular, and Vue. Client-side rendering became the cultural norm.

Engineering Challenges in the AI Era

Real-Time Processing Challenges

Modern AI applications demand capabilities that traditional SPAs struggle to deliver:

Network Overhead and Latency
AI applications require constant communication with servers for model updates, training data, or hybrid processing. This creates more network requests than traditional SPAs, ironically reducing the performance benefits that CSR was meant to provide. Real-time AI features like live translation, content generation, or computer vision processing suffer from network round-trip delays.

Synchronization Complexity
AI applications frequently need to maintain state consistency across multiple AI services (embeddings, completions, fine-tuned models). Managing this distributed state on the client introduces significant complexity and potential for data inconsistencies, especially when handling real-time collaborative AI features.

Processing Bottlenecks
Client devices, particularly mobile phones and budget laptops, lack the computational power for real-time AI processing. While servers can leverage specialized GPUs and TPUs, client-side AI inference creates noticeable delays and poor user experiences for time-sensitive applications.

Development and Maintenance Overhead

Fragmentation Across Devices
Different devices have varying AI capabilities (Neural Processing Units, GPU acceleration, WebGL support). Creating consistent AI experiences across this fragmented landscape requires substantial engineering effort. Developers must handle graceful degradation, feature detection, and multiple code paths for different device capabilities.

Version Management Complexity
AI models evolve rapidly with frequent updates and improvements. Managing model versions, backward compatibility, and deployment across diverse client devices becomes exponentially more complex than traditional web application updates. Each client potentially runs different model versions, creating support nightmares.

Resource Management
Client-side AI applications must carefully manage memory usage, processing threads, and battery consumption. This adds significant complexity to the development process, requiring specialized knowledge of device capabilities and performance optimization techniques that most web developers lack.

Server-Side Rendering: The AI-Era Solution

Why SSR Makes Sense for AI Applications

Server-side rendering addresses the fundamental misalignment between AI computational requirements and client device capabilities:

Specialized Hardware
Servers utilize GPUs, TPUs, and specialized AI hardware that provide orders of magnitude better performance than client devices for AI workloads.

Consistent Performance
Server-side AI processing provides predictable performance regardless of client device capabilities, ensuring all users receive the same high-quality experience.

Simplified Architecture
Centralized model deployment simplifies updates, A/B testing, and maintenance of AI capabilities while reducing client-side complexity.

Technical Benefits

Reduced Initial Load Times: Users receive pre-rendered HTML with AI-generated content already in place
Enhanced Security: AI models and processing remain on the server, preventing model extraction
Better SEO and Accessibility: AI-generated content is immediately available to search engines and screen readers
Resource Efficiency: Server infrastructure allows efficient resource sharing across users

Practical Tools for AI-Era SSR

Next.js: Server Actions and Streaming

Next.js leads the SSR renaissance with powerful AI features:

// Server Action for AI processing
'use server'
export async function generateResponse(formData) {
  const message = formData.get('message')
  const response = await openai.chat.completions.create({
    model: "gpt-4",
    messages: [{ role: "user", content: message }]
  })
  return response.choices[0].message.content
}

Key Features:

Server Actions for seamless AI processing
Edge Runtime support for global distribution
Built-in streaming for real-time AI responses

SvelteKit: Performance-First Approach

// Pre-process AI data before rendering
export async function load({ params }) {
  const userPreferences = await getUserPreferences(params.userId)
  const aiRecommendations = await generateRecommendations(userPreferences)

  return { recommendations: aiRecommendations }
}

Benefits:

Minimal JavaScript footprint
Server-side load functions for AI pre-processing
Excellent performance characteristics

Specialized AI Tools

Vercel AI SDK

import { streamText } from 'ai'
import { openai } from '@ai-sdk/openai'

export async function POST(req) {
  const { messages } = await req.json()
  const result = await streamText({
    model: openai('gpt-4'),
    messages,
  })
  return result.toAIStreamResponse()
}

Infrastructure Options:

Vercel Edge Functions: Global AI processing distribution
Cloudflare Workers: Low-latency AI inference at the edge
AWS Lambda: Serverless AI processing with AWS integration

Caching Strategies

Redis: Cache AI responses and user sessions
CDN Caching: Static AI-generated content with proper headers
Edge Caching: Distribute AI-processed content globally

The Hybrid Future

The future involves sophisticated hybrid approaches:

Smart Rendering Decisions
Frameworks will automatically decide where to render based on content type, device capabilities, network conditions, and AI processing requirements.

Progressive AI Enhancement
Applications will layer AI capabilities progressively, ensuring core functionality works universally while enhancing experiences where possible.

Conclusion

The shift toward server-side rendering represents a maturation of web development practices in response to AI requirements. As AI becomes central to web applications, computational realities demand server-centric architectures.

This evolution incorporates lessons from the SPA era while addressing AI-native application challenges. The tools and frameworks are ready—the question is how quickly development teams will adapt to leverage AI-era server-side rendering benefits.

Copilot Proxy: Your Free LLM API for Local Development

Hank Chiu — Tue, 13 May 2025 03:48:49 +0000

Original post: https://hankchiu.tw/writings/copilot-proxy-your-free-llm-api-for-local-development

Developing applications powered by Large Language Models (LLMs) can be costly, especially during the development phase. Each API call to services like OpenAI or Anthropic consumes tokens, and these costs can accumulate rapidly during iterative development and debugging.

I developed Copilot Proxy to address this issue. It's a local API proxy that routes your LLM requests to GitHub Copilot, maximizing your free quota usage and minimizing your API costs.

Existing Alternatives and Their Limitations

Some developers turn to local solutions like Ollama, which allows running open-source models such as LLaMA and Mistral locally. While this approach offers privacy and cost benefits, it comes with certain limitations:

Hardware Requirements: Running these models efficiently requires above-average hardware, such as modern Apple Silicon or high-end GPUs.
Model Availability: Ollama primarily supports open-source models. Mainstream models like GPT-4, Claude, or Gemini are not available through this platform.
Performance Variability: The performance and quality of open-source models can be inconsistent compared to their proprietary counterparts.
Management Overhead: Handling model downloads and dependencies can be cumbersome.

Copilot Proxy's Features

Seamless API Proxying: Transparently routes your OpenAI-compatible API requests to https://api.githubcopilot.com, allowing you to use GitHub Copilot as a drop-in replacement for expensive LLM APIs during development.
Supported Endpoints: Handles key endpoints such as /chat/completions for conversational AI and /models for model discovery, ensuring compatibility with most OpenAI-based tools and SDKs.
Intuitive Admin UI:
- GitHub Authentication: Securely log in with your GitHub account to generate and manage Copilot tokens directly from the interface.
- Manual Token Management: Easily add, remove, or update tokens as needed, giving you full control over your Copilot access.
- Multi-Token Support: Manage several tokens at once, allowing you to distribute requests across them and make the most of your available free quota.
- Usage Analytics: Visualize chat message and code completion statistics to monitor your development activity and optimize token utilization.

Ideal Use Cases

Developing with frameworks like LangChain or LlamaIndex to prototype and test LLM-powered workflows without incurring API costs.
Using the LLM CLI for your daily tasks, such as generating commit messages or summarizing code changes.
Chatting with GitHub Copilot through Open WebUI outside VSCode.

Not a Replacement for Production APIs

While Copilot Proxy is excellent for development purposes, it's not intended for production use. Copilot doesn't support features like function calls, tools, or streaming outputs that are available in full-fledged APIs. However, for local testing and development cycles, it serves as a cost-effective solution.

Try It Out

If you're building LLM-powered applications and want to optimize your development process without incurring high costs, give Copilot Proxy a try.

Lazy load AngularJS app from modern Angular project

Hank Chiu — Wed, 22 Jan 2025 14:31:54 +0000

Background

AngularJS was deprecated in 2018 and the Angular team has been working on Angular 2+ since 2016 (currently Angular v19!). AngularJS is still widely used in many projects and it is not easy to migrate to Angular 2+ in a short time.
I proposed a technique in this post to demonstrate lazy-loading AngularJS apps from modern Angular projects without changing the existing AngularJS code too much.

Rationale

While Angular officially provides @angular/upgrade, it suggests a progressive migration approach. However, a medium to large project often leaves an intermediate state in business logic scattered between AngularJS and Angular 2+. It is not easy to maintain and test the code in such a state.
Lazy-loading is a technique to connect the whole legacy logic as is, and gradually migrate the code to Angular 2+ later.

Show me the code

If you are in a hurry, you can check the code in this repository: https://github.com/hankchiutw/ng1-migration-example

How it works in a nutshell

The key is to bootstrap the AngularJS app manually by angular.bootstrap, instead of using ng-app in the template.

Step 1: Wrap main AngularJS code in controllers and directives

Your Angular project will render the AngularJS directive. Here is a minimal example of AngularJS code:

const ng1Module = angular.module('myApp', []);
angular.module('myApp').directive('myAppRoot', () => ({
  controller: MainController,
  template: `my AngularJS app`,
}));

Tips: You can set loader option in angular.json to separate the template as a html file.

// angular.json
  "builder": "@angular-devkit/build-angular:application",
  "options": {
    "loader": {
      ".html": "text"
    },

import template from './ng1-app.html';

angular.module('myApp').directive('myAppRoot', () => ({
  controller: MainController,
  template,
}));

Step 2: Bootstrap AngularJS app in Angular project

A reasonable place to bootstrap AngularJS app is in ngOnInit of Angular component. The key is to ensure the AngularJS module is loaded before bootstrapping the AngularJS app. Here is an example:

import { ng1Module } from './ng1-app/ng1-app';

ngOnInit() {
  angular.bootstrap(this.elRef.nativeElement, [ng1Module.name]);
}

If your AngularJS code is really fat, you can use import() to load the AngularJS code dynamically. Here is an example:

ngOnInit() {
  import('./ng1-app/ng1-app').then(({ ng1Module }) => {
    angular.bootstrap(this.elRef.nativeElement, [ng1Module.name]);
  });
}

Conclusion

Lazy-loading gives you the flexibility of choosing different migration strategies. You can migrate the whole AngularJS app to Angular 2+ at once, or migrate feature by feature. It is a good way to keep the project maintainable and testable during the migration process.

Practically, your AngularJS app may have more complex logic and dependencies. You may need to adjust the code to fit your project. However, the basic idea is the same. I hope this post can help you to migrate your AngularJS project to Angular 2+ more smoothly.
If you have any specific use cases want to discuss(e.g. use AngularJS and Angular routing together), feel free to leave a comment below. I am happy to discuss with you. Thank you for reading!

Copy as Link: A simple Chrome extension that copies the selected text as a link to the current page's URL

Hank Chiu — Mon, 04 Nov 2024 15:31:08 +0000

Show empathy for your readers(or yourself) by always sharing a link with a readable title, instead of a plain https://....

That's why I created Copy as Link.

Whether you're:

Collecting research materials
Sharing interesting quotes with colleagues
Building a knowledge base
Creating documentation with references

This extension seamlessly integrates into your browsing experience, making link creation as natural as highlighting text.

The implementation is straightforward, built with Plasmo and React. Feel free to check out the source code if you're interested.

You may not need ngOnChanges

Hank Chiu — Tue, 19 Jan 2021 00:29:52 +0000

"ngOnChanges" is a lifecycle hook for an Angular component to know when the @Input props are changed. The main drawback of using ngOnChanges is that you have to write much more code to watch a single prop.

Angular team also provides another way to intercept the property changes by setter. If you use the setter technique naively you would find it tediously to write the getter/setter pair and the redundant private variable.

In this article, I would like to share how I improve the setter technique into an npm module - subjectize.

Usage

Say we are building a counter component and would like to do something whenever the count changes. We could have 3 versions of implementation like below(excerpt):

1) By ngOnChanges

class CounterComponent implements OnChanges {
  @Input()
  count: number;

  ngOnChanges(changes: SimpleChanges) {
    if (changes.count) {
      // do something
    }
  }
}

2) By naive setter

class CounterComponent {
  @Input()
  get count(): number {
    return this._count;
  }

  set count(value) {
    this._count = value;
    // do something
  }

  private _count: number;
}

3) By Subjectize

class CounterComponent implements OnInit {
  @Input()
  count: number;

  @Subjectize("count")
  count$ = new ReplaySubject(1);

  ngOnInit() {
    this.count$.subscribe(() => {
      // do something
    });
  }
}

They may look fair in such a simple scenario, but things go differently when you have a few Input props to watch. For ngOnChanges, you got lots if logics. For naive setter, you got many boring private variables.

The Subjectize is also a mentally-direct approach: declare a RxJS Subject and subscribe to the Subject for changes, that's it.

The magics

The Subjectize is a TypeScript property decorator. Under the hood, it creates an internal getter/setter for the specified Input prop, just like the naive setter implementation. The Subjectize itself only depends on RxJS, hence you can use it on any ES6 class without Angular. You could also use it for simple state management.

Without saying, there are more things to do to keep the reliabilities. If you are interested, see the source code.

Conclusion

JavaScript getter/setter can be used to watch Input props and subjectize helps you to do that. If you just got fed up with ngOnChanges, give subjectize a try!

How do I create my first Chrome extension using TypeScript - PART 1

Hank Chiu — Mon, 20 Jul 2020 22:36:51 +0000

In this post, I would like to share my journey of creating AnyColor - A Chrome extension that makes you pick up any pixel color from a web page.

Origin

To be honest, there are already many color picker/eyedropper extensions on the Chrome Web Store. Why do I need to create another one?
It's simple: none of them meet my simple requirement - the ability to pick up any color quickly when browsing.
To name a few extensions I have tried:

Eye Dropper Almost what I need but somehow slow and I don't need the color palette. The UX design could be better.
ColorPick Eyedropper Similar to the above, not so quick to invoke the picker.
ColorZilla This is a color picker for DOM elements. No way to pick colors from images on a web page.

Although thousands of users use these extensions, they are just not what I want.

Idea

I realized the main problem of these extensions is UX design and performance.
As a front-end developer, eyedropper from chrome-devtool came into my mind. The neat UX design is already there, all I have to do is to implement it as a Chrome extension, instead of calling devtool on each web page.

Implementation

This is my first time developing a Chrome extension. The official developer guide is clear but the API is not so modern comparing to other google's products. In a word, I implemented using TypeScript, Web Component, and HTML5 Canvas.
I decide to leave the technical details in another post. The source code is public here hankchiutw/any-color.

Conclusion

Publishing tools for developers is fun and interesting. Give it a try (AnyColor) and any feedback is appreciated!
I also wonder how do you use a color picker/eyedropper extensions in your workflow? Share below!

A simple technique to promisify Chrome extension API

Hank Chiu — Sat, 18 Jul 2020 11:23:40 +0000

Update:
Now you can use toPromise from crx-esm!

One of my pain when developing a Chrome extension is looking at the callback-based APIs. There are some polyfill promisified all the APIs. (e.g. webextension-polyfill)

If you just want some light-weight solution, here you are.

The simple trick is to take advantage of the truth that the callback function is always the last argument, and you can create a simple helper function to promisify the chrome API:

function toPromise(api) {
  return (...args) => {
    return new Promise((resolve) => {
      api(...args, resolve);
    });
  };
}

and use it like:

toPromise(chrome.tabs.query)({}).then(...);

This just works for me most of the time.