Chingu AI: Building an AI Chat App with Spring Boot & GitHub Copilot

Mochi — Mon, 01 Jun 2026 20:46:41 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Chingu AI is a full-stack AI chat application built with Spring Boot 3, secured with Google OAuth2, and powered by the Groq API for fast LLM inference.

The name "Chingu" (친구) means "Friend" in Korean — and that's exactly what I wanted to build: a coding companion that feels like a peer, not a rigid tool.

Tech Stack:

Backend: Java 17, Spring Boot 3, Spring Security, Spring Data JPA
Frontend: Thymeleaf, Bootstrap 5, custom dark/purple cyberpunk UI
Database: SQL Server (message history persistence)
AI Engine: Groq API
Auth: Google OAuth2 SSO + Form Login

Demo

👉 GitHub Repository: beyzanur314/ChinguAi

The Comeback Story

This project had been sitting at "almost done" for weeks. It worked — technically. But it had real problems that made it unusable for others.

Where I started:

Basic Spring Boot project with no authentication
No AI integration
No message history

The problems I hit (and fixed):

1. The OAuth2 Infinite Loop 🔄

After integrating Google OAuth2, authenticated users kept getting bounced back to the login screen with a 401 Unauthorized error. The fix was buried in Spring Security's filter chain — I needed to explicitly permit /login/oauth2/code/** for the token exchange callback.

2. The Ambiguous Mapping Crash 💥

Spring Boot refused to start due to an IllegalStateException: Ambiguous mapping — two controller beans were competing for the same GET /chingu/ui route. I resolved this by unifying them into a single polymorphic endpoint using @AuthenticationPrincipal Object principal to handle both UserDetails and OAuth2User dynamically.

3. The Secret Leak Incident 🔐

During a Git push, GitHub's Push Protection hard-blocked my commit — my Groq API keys and Google client secrets were exposed in application.properties. Instead of bypassing the warning, I cleaned the Git history, invalidated the leaked credentials on Groq Console, and moved all secrets to environment variables.

4. Groq 401 Unauthorized

Even after the secret leak fix, I hit Groq API 401 errors because the environment variables weren't being picked up correctly at runtime. Debugging this taught me a lot about how Spring Boot loads external configuration.

My Experience with GitHub Copilot

GitHub Copilot completely changed how I debugged this project inside IntelliJ IDEA.

Security Refactoring: When I was lost in Spring Security's fluent DSL, Copilot scaffolded the correct SecurityFilterChain bean structure — including the exact syntax for chaining formLogin and oauth2Login together.

Thymeleaf Templates: Writing th:action paths and dynamic conditional headers with OAuth2 user attributes is surprisingly tricky. Copilot accurately predicted token pathways like oauth2User.getAttribute('picture') for rendering user avatars.

Stack Trace Debugging: When Spring threw 50+ line stack traces about ambiguous mappings, Copilot pinpointed the exact controller lines causing the conflict — saving me hours of manual tracing.

Secret Management: Copilot proactively suggested moving hardcoded credentials to environment variables before the leak happened. I should have listened earlier.

Lessons Learned

OAuth2 requires exact configuration — one wrong redirect URI breaks everything
Environment variables > hardcoded secrets, always
GitHub Copilot is most powerful when you give it the full error context
Spring Security's filter chain order matters more than you think
"Almost done" is not the same as "done" — finishing is a skill

What's Next

Cloud deployment (Azure/Railway)
Voice input/output
User profiles and settings
Rate limiting

Built with Java, Spring Boot, Groq API, and GitHub Copilot ☕🤖

DEV Community: Mochi