open source

• kagisearch/smallweb: Kagi Small Web

  Kagi Small Web. Contribute to kagisearch/smallweb development by creating an account on GitHub.

  Jan 24, 2026 / links / open source / kagi

• OpenCode | The open source AI coding agent

  OpenCode - The open source coding agent.

  Jan 16, 2026 / AI / Programming / Tools / links / agent / open source / code

• 36 Framework Fixtures in One Session: How Beads + Claude Code Changed Our Testing Game

  We built test fixtures for 36 web frameworks in a single session. Not days. Not a week of grinding through documentation. Hours.

  Here’s what happened and why it matters.

  The Problem

  api2spec is a CLI tool that parses source code to generate OpenAPI specifications. To test it properly, we needed real, working API projects for every supported framework—consistent endpoints, predictable responses, the whole deal.

  We started with 5 frameworks: Laravel, Axum, Flask, Gin, and Express. The goal was to cover all 36 supported frameworks with fixture projects we could use to validate our parsers.

  What We Actually Built

  36 fixture repositories across 15 programming languages. Each one includes:

  • Health check endpoints (GET /health, GET /health/ready)
  • Full User CRUD (GET/POST /users, GET/PUT/DELETE /users/:id)
  • Nested resources (GET /users/:id/posts)
  • Post endpoints with pagination (GET /posts?limit=&offset=)
  • Consistent JSON response structures

  The language coverage tells the story:

  • Go: Chi, Echo, Fiber, Gin
  • Rust: Actix, Axum, Rocket
  • TypeScript/JS: Elysia, Express, Fastify, Hono, Koa, NestJS
  • Python: Django REST Framework, FastAPI, Flask
  • Java: Micronaut, Spring
  • Kotlin: Ktor
  • Scala: Play, Tapir
  • PHP: Laravel, Slim, Symfony
  • Ruby: Rails, Sinatra
  • C#/.NET: ASP.NET, FastEndpoints, Nancy
  • C++: Crow, Drogon, Oat++
  • Swift: Vapor
  • Haskell: Servant
  • Elixir: Phoenix
  • Gleam: Gleam (Wisp)

  For languages without local runtimes on my machine—Haskell, Elixir, Gleam, Scala, Java, Kotlin—we created Docker Compose configurations with both an app service and a dev service for interactive development.

  How Beads Made This Possible

  We used beads (a lightweight git-native issue tracker) to manage the work. The structure was simple:

  • 40 total issues created
  • 36 closed in one session
  • 5 Docker setup tasks marked as P2 priority (these blocked dependent fixtures)
  • 31 fixture tasks at P3 priority
  • 4 remaining for future work

  The dependency tracking was key. Docker environments had to be ready before their fixtures could be worked on, and beads handled that automatically.

  When I’d finish a Docker setup task, the blocked fixture tasks became available.

  Claude Code agents worked through the fixture implementations in parallel where possible.

  The combination of clear task definitions, dependency management, and AI-assisted coding meant we weren’t context-switching between “what do I need to do next?” and “how do I implement this?”

  The Numbers

  Metric	Value
  Total Issues	40
  Closed	36
  Avg Lead Time	0.9 hours
  New GitHub Repos	31
  Languages Covered	15

  That average lead time of under an hour per framework includes everything: creating the repo, implementing the endpoints, testing, and pushing.

  What’s Left

  Four tasks queued for follow-up sessions:

  1. Drift detection - Compare generated specs against expected output
  2. Configurable report formats - JSON, HTML, and log output options
  3. CLAUDE.md files - Development instructions for each fixture
  4. Claude agents - Framework-specific coding assistants

  The Takeaway

  Doing this today, was like having a super power. “I need to test across 36 frameworks” and actually having those test fixtures ready, but with agents and Opus 4.5 and beads, BAM done!

  Beads gave us the structure to track dependencies and progress.

  Claude Code agents handled the repetitive-but-different implementation work across languages and frameworks.

  The combination let us focus on the interesting problems instead of the mechanical ones.

  All 36 repos are live at github.com/api2spec with the api2spec-fixture-* naming convention.

  Have you tried this approach yet?

  Jan 13, 2026 / DevOps / Open-source / Testing / Ai-tools / Claude-code

  Enjoyed this?

• Home - Tyk API Management

  The API management platform built for self-hosted control AI and agentic workloads distributed, low-latency scale Tyk gives you full control to secure, govern, and scale the APIs that move your data, models, and decisions,across any cloud, hybrid, or on-prem environment. Start for free Get a demo Powering the world’s best companies Your vision, powered by Tyk Your APIs. Your infrastructure. Your […]

  Jan 8, 2026 / AI / links / platform / self-hosted / open source / api / gateway

• api2spec work will continue this weekend. We will add support for more frameworks and languages. Finding gaps in the implementation as we build fixtures for each framework. If you have a framework you’d like to see supported, please let me know.

  Jan 7, 2026 / Open-source / Api2spec / Development

• Introducing api2spec: Generate OpenAPI Specs from Source Code

  You’ve written a beautiful REST API. Routes are clean, handlers are tested and the types are solid. But where’s your OpenAPI spec? It’s probably outdated, incomplete, or doesn’t exist at all.

  If you’re “lucky”, you’ve been maintaining one by hand. The alternatives aren’t great either, runtime generation requires starting your app and hitting every endpoint or annotation-heavy approaches clutter your code. At this point we should all know, with manual maintenance it’ll inevitably drift from reality.

  What if you could just point a tool at your source code and get an OpenAPI spec?

  Enter api2spec

  # Install
  go install github.com/api2spec/api2spec@latest
  
  # Initialize config (auto-detects your framework)
  api2spec init
  
  # Generate your spec
  api2spec generate
  

  That’s it. No decorators to add. No server to start. No endpoints to crawl.

  What We Support

  Here’s where it gets interesting. We didn’t build this for one framework—we built a plugin architecture that supports 30+ frameworks across 16 programming languages:

  • Go: Chi, Gin, Echo, Fiber, Gorilla Mux, stdlib
  • TypeScript/JavaScript: Express, Fastify, Koa, Hono, Elysia, NestJS
  • Python: FastAPI, Flask, Django REST Framework
  • Rust: Axum, Actix, Rocket
  • PHP: Laravel, Symfony, Slim
  • Ruby: Rails, Sinatra
  • JVM: Spring Boot, Ktor, Micronaut, Play
  • And more: Elixir Phoenix, ASP.NET Core, Gleam, Vapor, Servant…

  How It Works

  The secret sauce is tree-sitter, an incremental parsing library that can parse source code into concrete syntax trees.

  Why tree-sitter instead of language-specific AST libraries?

  1. One approach, many languages. We use the same pattern-matching approach whether we’re parsing Go, Rust, TypeScript, or PHP.
  2. Speed. Tree-sitter is designed for real-time parsing in editors. It’s fast enough to parse entire codebases in seconds.
  3. Robustness. It handles malformed or incomplete code gracefully, which is important when you’re analyzing real codebases.
  4. No runtime required. Your code never runs. We can analyze code even if dependencies aren’t installed or the project won’t compile.

  For each framework, we have a plugin that knows how to detect if the framework is in use, find route definitions using tree-sitter queries, and extract schemas from type definitions.

  ---

  Let’s Be Honest: Limitations

  Here’s where I need to be upfront. Static analysis has fundamental limitations.

  When you generate OpenAPI specs at runtime (like FastAPI does natively), you have perfect information. The actual response types. The real validation rules. The middleware that transforms requests.

  We’re working with source code. We can see structure, but not behavior.

  What this means in practice:

  • Route detection isn’t perfect. Dynamic routing or routes defined in unusual patterns might be missed.
  • Schema extraction varies by language. Go structs with JSON tags? Great. TypeScript interfaces? We can’t extract literal union types as enums yet.
  • We can’t follow runtime logic. If your route path comes from a database, we won’t find it.
  • Response types are inferred, not proven.

  This is not a replacement for runtime-generated specs. But maybe so in the future and for many teams, it’s a massive improvement over having no spec at all.

  Built in a Weekend

  The core of this tool was built in three days.

  • Day one: Plugin architecture, Go framework support, CLI scaffolding
  • Day two: TypeScript/JavaScript parsers, schema extraction from Zod
  • Day three: Python, Rust, PHP support, fixture testing, edge case fixes

  Is it production-ready? Maybe?

  Is it useful? Absolutely.

  For the fixture repositories we’ve created realistic APIs in Express, Gin, Flask, Axum, and Laravel. api2spec correctly extracts 20-30 routes and generates meaningful schemas. Not perfect. But genuinely useful.

  How You Can Help

  This project improves through real-world testing. Every fixture we create exposes edge cases. Every framework has idioms we haven’t seen yet.

  • Create a fixture repository. Build a small API in your framework of choice. Run api2spec against it. File issues for what doesn’t work.
  • Contribute plugins. The plugin interface is straightforward. If you know a framework well, you can make api2spec better at parsing it.
  • Documentation. Found an edge case? Document it. Figured out a workaround? Share it.

  The goal is usefulness, and useful tools get better when people use them.

  ---

  Getting Started

  go install github.com/api2spec/api2spec@latest
  cd your-api-project
  api2spec init
  api2spec generate
  cat openapi.yaml
  

  If it works well, great! If it doesn’t, file an issue. Either way, you’ve helped.

  api2spec is open source under the FSL-1.1-MIT license. Star us on GitHub if you find it useful.

  Built with love, tree-sitter, and too much tea. ☕

  Jan 5, 2026 / DevOps / Programming / Openapi / Golang / Open-source

  Enjoyed this?