Nevin-Bali100

Posted on Aug 29

Building DevDocAI — A Production Multi-Agent LangGraph System | Part 5 - Backend Closed Out, GitHub OAuth Working End-to-End

#python #langchain #fastapi #git

Series: Building DevDocAI — A Production Multi-Agent LangGraph System

Part 5 — Backend Closed Out, GitHub OAuth Working End-to-End

Quick Update

Short post this time — but a meaningful checkpoint.

Since Part 4, two things happened:

The backend is now fully complete — all 13 endpoints, tested and working.
GitHub OAuth is wired frontend → backend → GitHub → back again, and I watched it work end-to-end for the first time.

That second one felt bigger than it sounds. Let me walk through both.

Backend — The Final Two Endpoints

Part 4 left two gaps: no way to browse a user's actual GitHub repos, and no way to trigger the pipeline outside of a PR merge webhook. Both are closed now.

GET /github/repos
Pulls the user's repos directly from GitHub — not from our DB. New MCP tool, list_user_repos, wraps PyGithub's user.get_repos() and returns the fields the frontend actually needs: name, default branch, visibility, language.

POST /repos/{repo_id}/run
The manual trigger. Connect a repo → hit this → the full LangGraph pipeline starts immediately instead of waiting for a PR to merge. Same run_pipeline() the webhook uses, just a different entry point and trigger="manual" instead of "pr_merge".

Full endpoint list now:

POST  /auth/register
POST  /auth/login
GET   /auth/github
POST  /auth/github/callback
GET   /auth/me
POST  /webhooks/github
GET   /repos
GET   /github/repos
POST  /repos/connect
POST  /repos/{repo_id}/run
GET   /pipeline/{thread_id}/state
POST  /pipeline/review
POST  /chat/ask

Backend's done. Every agent, every checkpoint, every route the frontend needs — all there.

GitHub OAuth — Where It Actually Broke

This is the part worth writing down, because the bug was sneaky.

The flow is: frontend asks the backend for a GitHub authorize URL, backend builds it using GITHUB_REDIRECT_URI from .env, GitHub redirects back to that exact URI with a code, frontend catches it and exchanges it for a session.

I updated GITHUB_REDIRECT_URI in .env from the backend's own callback route to the frontend's:

# before
GITHUB_REDIRECT_URI=http://localhost:8000/auth/github/callback

# after
GITHUB_REDIRECT_URI=http://localhost:3000/auth/callback

Updated the GitHub OAuth App's redirect URI to match. Tested without restarting the server. GitHub threw:

Be careful! The redirect_uri is not associated with this application.

The URL in the browser still showed localhost:8000. .env was correct. GitHub App settings were correct. So why was the old value still being used?

@lru_cache() on get_settings(). The settings object gets built once and cached for the life of the process — editing .env while the server is still running (even with --reload, which only watches code files, not env vars) does nothing. A full stop and restart was needed to actually rebuild the cached Settings instance.

Small gotcha, easy fix, but worth remembering: env var changes need a hard restart, not a hot reload.

Seeing It Work

After the restart, the full loop:

/login → "Continue with GitHub"
      → GitHub authorize screen
      → redirects to localhost:3000/auth/callback?code=xxx
      → frontend exchanges code with backend
      → JWT stored
      → /dashboard

And it just worked. Landed on the dashboard, GitHub username in the top corner, no errors in either console.

There's something different about a full auth loop working versus a single endpoint returning 200 in Swagger. This is the first time a real browser, a real GitHub account, and the actual frontend all talked to each other correctly. It's the first "this feels like a product" moment in the project.

Where Things Stand

Piece	Status
Backend (13 endpoints)	Complete
GitHub OAuth, frontend to backend	Working, tested live
Frontend pages (landing, auth, dashboard, review, chat)	Built
Dashboard / review / chat wired to real data	Next
Phase 7 — Docker, ECR, ECS, CI/CD	Untouched

The dashboard is currently rendering against sample repos. Next step is swapping that for GET /repos and GET /github/repos, and making "Connect repository" actually call POST /repos/connect followed by POST /repos/{id}/run.

That's Part 6.

GitHub

Nevin100 / DevdocxAI

DevDocxAI is a production-grade multi-agent AI system that automatically generates, maintains, and updates engineering documentation by deeply understanding you…DevDocAI is a production-grade multi-agent AI system that automatically generates, maintains, and updates doc. by understanding deeply.

DevDocxAI 🤖📄

DevDocxAi is a production-grade multi-agent LangGraph system that automatically generates and updates engineering documentation from your GitHub codebase.

🚨 The Problem

Every engineering team has the same dirty secret — the docs are lying.

Not intentionally. Code moves fast, documentation doesn't.

New dev joins → 2 weeks reading outdated wikis
Senior engineers constantly interrupted with "what does this do?"
PR gets merged → docs never updated
Generic RAG chatbots don't understand code structure

DevDocAI fixes this.

✨ What It Does

🔍 Connects to your GitHub repo via OAuth
🌳 Parses your codebase at the AST level — understands functions, classes, modules
📝 Auto-generates structured documentation per module and function
🔄 Updates docs on every PR merge via GitHub webhooks
👀 Human-in-the-Loop review — you approve before anything goes live
💬 Onboarding chatbot — new devs ask questions, get answers from live code

🤖 Agent Pipeline

START
  ↓
codebase_parser

…

View on GitHub

Building in public — one working loop at a time.

Tags: python nextjs oauth fastapi langgraph webdev opensource

DEV Community