I've been working with Nuxt + SQL for a while, and one thing that kept annoying me during development was figuring out what SQL queries an API request actually executed.

For example, when an endpoint feels slow, I want to quickly answer:

• How many SQL queries did this request execute?
• Which queries were executed?
• How long did each query take?
• Which API endpoint triggered them?
• Am I accidentally doing 20 queries when I expected 2?

Normally, I'd end up adding logging around the database client and digging through the terminal.

So I built nuxt-sql-inspector to make this easier.

It adds a development-only SQL inspector to Nuxt at:

/__sql_queries

You can see the API request and the SQL queries it triggered, along with query timing and other useful information.

It currently supports several common SQL drivers, including PostgreSQL, postgres.js, mysql2, SQLite, and Nitro db0, and can be used with ORMs such as Drizzle and Prisma depending on the underlying driver.

The goal is pretty simple:

API request → SQL queries → timings

without having to dig through console logs.

GitHub: https://github.com/drowhann/nuxt-sql-inspector

It's still a relatively small project, so I'm particularly interested in feedback from people using Nuxt + Drizzle/Prisma/Postgres.

What would you want to see in a SQL inspector like this?

🚀 Shipped ScrollStack — headless infinite scrolling for Web

📦 1.92 KB gzipped, zero runtime deps

⚛️ React, Vue & Svelte adapters

🔁 Cursor, offset, Virtual list & page pagination → one function

🧠 Stale responses can't resurrect dead state

You bring the markup 👇

https://scrollstack.js.org

For over two decades, agency hosting economics were beautifully predictable. You bought a reseller web server or dedicated cPanel account for $50 a month, crammed 30 client WordPress sites onto it, and charged each client a flat $25 monthly maintenance fee. Your margins were clear, your server bills were static, and billing surprises were virtually non-existent. Read the comple te article here > Serverless Bill Shock: Track Vercel & Supabase Client Costs | InstaRenewal

Then came the modern web stack.

Driven by the demand for lightning-fast digital experiences, agencies aggressively migrated to decoupled architectures: Next.js, Nuxt, Vercel, Supabase, Cloudflare Workers, and serverless databases like Neon. While the performance gains of this modern paradigm are undeniable, it introduced a chaotic operational reality: micro-subscription fragmentation and variable utility billing.

I got tired of switching between Figma and my Nuxt app just to try out small UI changes, so I built Airship.

It wraps your dev server and adds a Figma-like canvas to your running app. Select an element, describe the change, and Claude Code applies it directly to your source.

You get streaming diffs, inline undo, and desktop/mobile frames so you can see changes across screens as you iterate.

It runs as a lightweight proxy with no plugins or build changes.

It uses your existing Claude Code subscription. Codex and OpenCode are supported too.

Fully open source and MIT licensed.

Fork it, star it, and make it your own :)

I'm a Nuxt dev and my clients almost always end up asking for a CMS. My default answer used to be Strapi, but it's a whole separate service: its own hosting, its own deploys, and the monthly cost for the client goes up fast for what is usually a handful of collections.

At some point I thought: Nuxt already ships a server (Nitro), surely someone has built a CMS that just runs inside it? To my surprise, no. So I built it.

How it works:

- You define content types in code (a `cms.config.ts` file): collections, singles, relations, blocks, translatable fields. Schema, migrations and TypeScript types are generated from it.
- Editors get an admin panel at `/cms` with drafts, validation and a media library.
- You query content through a read-only GraphQL API, typed end to end with gql.tada.
- SQLite by default (zero setup), one config line to switch to Postgres or Turso.
- Media on any S3-compatible storage, or a local mode that just reads from your `public/` folder.

You deploy one thing: your Nuxt app. No second service, nothing extra to pay for.

I tried to cover Strapi's core features, so for most projects (I'd say 90% of my client work) switching is painless. It's still a beta though, and some corners are rough: auth is currently a single admin whose credentials live in env variables (I know, I know), multi-user and RBAC are on the roadmap. But I think it can already be genuinely useful.

It's MIT licensed: https://github.com/xleddyl/nuxt-cms

Feedback and issues very welcome!

I built a full-stack Appointment Tracking System to practice building and connecting a frontend, backend, database, and authentication system.

The project includes:

• User registration and login
• JWT authentication
• Appointment and service management
• Admin and user dashboards
• Protected routes
• Responsive UI

Tech stack: Nuxt.js, Vue.js, TypeScript, Node.js, Express.js, MongoDB, and JWT.

GitHub: https://github.com/Mariam-amhan/appointment-tracking-system

Any feedback on the project structure or implementation would be appreciated.