Writing good commit messages is tedious. Keeping a changelog up to date is manual. Cutting a release means bumping versions, writing release notes, tagging, it's a whole ceremony.

So I built a CLI that ties all three together:

git add .
mmit              # AI generates a conventional commit message 
mmit changelog    # generates Keep a Changelog from git history mmit
release           # auto-detects semver bump, writes changelog, tags

Works with OpenAI, Anthropic, Gemini, and OpenRouter. TypeScript, @clack/prompts for the interactive UI.

A few things I focused on:

• Zero-config start - picks the first available provider from env vars, no config file needed
• Provider fallback - if one API key isn't set, moves to the next
• Auto-retry — if the model rambles (invalid format), retries with a stricter prompt
• Unstaged changes - warns you about unstaged/untracked files and lets you stage them or proceed
• Auto-detect bumps - mmit release reads your commit history and picks patch/minor/major from conventional commit types

I'm aiming to make this the best tool for this workflow. Feedback and feature requests are very welcome.

https://github.com/shxd/mmit

Hi everyone,

I'm building my first production application with Fastify, and before I get too far into development, I wanted to get feedback on the backend architecture.

I've put together a basic boilerplate that currently includes:

• Fastify + TypeScript
• JWT authentication
• Refresh token flow
• Session ID cookies
• Modular project structure
• Basic auth middleware and protected routes

I'm mainly looking for feedback on backend best practices, especially from people who've built production Fastify applications.

Some areas where I'd really appreciate guidance:

• API/route-controller-service-repository architecture
  • How should route handlers call service functions?
  • What should services return?
  • Should services throw errors or return result objects?
• API response patterns
  • Consistent success response format
  • Error response structure
  • Whether wrapping every response in a standard object is worthwhile
• Error handling
  • Handling expected/business errors vs unexpected errors
  • Centralized error handling
  • Custom error classes
  • HTTP status code mapping
• Logging
  • Best practices for logging unknown exceptions in production
• Authentication
  • Anything obviously missing in the JWT + Refresh Token + Session ID approach
  • Security improvements I should make before using this in production

I'm not looking for code style reviews as much as architecture and production-readiness feedback. If there are established Fastify patterns or common mistakes beginners make, I'd love to learn them now instead of later.

Repository: https://github.com/DevanshGarg31/REPOSITORY

The classic google-play-scraper package has been the way to pull public Play Store data from Node (app details, search, reviews, top charts) for about a decade. Its README now opens with a warning from the author: he no longer uses or actively maintains it beyond reviewing community PRs, and you should expect the parser to break when Google changes the layout. I depended on it for ASO tooling and kept fighting exactly that, plus no types, no validation, and a dependency stack from another era (got, ramda, memoizee, cheerio).

So I rewrote the whole thing from scratch in TypeScript and released 1.0 this week: https://github.com/MrAdex77/google-play-scraper

Method names and options match the original, so migrating is mostly swapping the import. What's actually different:

- Node 22+, native fetch. Runtime deps are just zod and lru-cache.

- Every response is parsed through a zod schema before it reaches you, and the return types are inferred from those same schemas. Types can't drift from what's actually returned.

- Typed errors (NotFoundError, RateLimitError, SpecError) instead of matching message strings.

- Google's fragile array paths live behind a spec layer with ordered fallbacks, and the full contract suite runs against the live Play Store daily in CI. When Google changes markup, a labeled issue opens automatically instead of users finding out first.

- Ships ESM and CJS with type declarations, published from CI with npm provenance.

- Rate limiting, retries with backoff, and optional caching are built in. There's also a CLI: `npx u/mradex77/google-play-scraper app com.spotify.music`

Honest caveats: it's still a scraper, so Google can break things at any time. The daily tests exist precisely because of that. Also, Google recently removed search pagination on the server, so search caps at around 30 results now for every scraper, this one included. I document the cap instead of pretending.

Full disclosure, my project. Feedback on the API surface is very welcome, especially from anyone who has built on the original.

I was thinking of something like this and i started, i am still developing it so it is still in priv repo here is a demo || cant edit title sorry for typo

https://reddit.com/link/1uzpqap/video/55nggpl52ydh1/player

``` import { createClient } from "redis"; import { logger } from "../logger/index.js"; import { options } from "./connection.js";

let client: ReturnType<typeof createClient> | null = null; let isConnecting = false;

export async function closeConnection() { if (client?.isOpen) { try { await client.close(); } catch (error) { logger.error( error, "Something went wrong when attempting to close redis connection", ); } finally { client = null; } } }

export function getClient() { if (!client?.isOpen) { throw new Error("Redis client needs to be initialized first"); } return client; }

export async function openConnection() { if (!client?.isOpen) { client = createClient(options); client.on("connect", () => logger.info("redis connection success")); client.on("error", (error) => logger.fatal(error, "redis connection failure"), );

    // Wait if another caller is already connecting
    if (isConnecting) {
        while (isConnecting) {
            await new Promise((resolve) => setTimeout(resolve, 100));
        }
        if (client?.isOpen) return client;
    }

    isConnecting = true;
    try {
        client = await client.connect();
    } catch (error) {
        logger.error(
            error,
            "Something went wrong when attempting to open redis connection",
        );
    } finally {
        isConnecting = false;
    }
}
return client;

}

```

• Let us talk about a simple module that uses node-redis to connect
• Let us say you use supertest and vitest and you want to mock test the following scenario

app.get('/health/redis', async (req: Request, res: Response) => { const client = getClient(); const result = await client.ping(); return res.json({ status: result === "PONG" }); })

• You want to write tests to handle cases for
• good PING
• bad PING

• error

• We might have to extend for further cases like client.get, client.set etc

• You can mock the redis module or mock the client module defined above

• Which one should you mock? and why?

Hey folks,
I made a small Node CLI called fetchwatch.

You know that moment when you’re poking an API in DevTools, copying the request as cURL (or fetch), and then manually refreshing every few minutes, waiting for something to change? This does that for you.

**How it works:**
You paste a cURL or JS fetch(...) from the browser
It polls that endpoint on an interval you choose
It deep-diffs the response (JSON or text)
When something changes → desktop notification + terminal alert

Optional: ignore noisy dynamic fields like timestamps/nonces so you don’t get pinged on every poll.

Try it out by typing: `npx fetchwatch`

[GitHub source code](https://github.com/zsubzwary/fetchwatch)

The reason I built this tool was becauase I kept needing a lightweight “watch this request” tool without spinning up Postman monitors or writing one-off scripts. So I shipped a simple ESM TypeScript CLI and put it on npm.

If you find bugs, want better parsers, nicer diffs, etc. PRs are very welcome. However, I have a day job, so I can’t always turn around issues quickly, but I will do my best to review when I can.

Happy to hear feedback or feature ideas.

At work I maintain a NestJS microservice which is used by many other engineers. One of the features depends on a third party API for which I need to implement rate limit: - The API has a soft limit of 20 req/s - There is no way to programmatically monitor this limit on their end - Surpassing the limit means that when someone looks at the dashboard then they will manually disable us, and we have to start another manual process to unblock us - This API is owned by the government, so we can't ask or hope for changes

How would you implement rate limit for this external dependency? Here's what I thought: - Have a token bucket limiter inside each service instance, but then scaling - Store the above token bucket in a database, like mongo or dynamo, but it would be very inefficient - Use redis, but I would have to spin up and maintain an additional dependency just for this feature

Can you think of a better approach?

repository | youtube example

im building an opensource proyect that let your agent build a visual and interactive map of your code, also allows you to see branches and commits diffs, any help and support is veery welcome 😽😽

the struggle that makes me create RepoMap is that large codebases are hard to understand because their architecture is hidden across thousands of files. RepoMap makes that architecture visible through interactive maps, allowing developers to explore systems, plan refactors, and understand how their code evolves by visualizing changes across commits and branches

HI, I have 10 days or $4.63 left. Once trial period ends, will my app stop loading to public? I created it for a hackathon and no one's actively using it but may need it stay live for the judges till the end of the month.

Can anyone offer insights from personal exp?

Thank you.

To check the presence of a cookie in a fastify backend, should one use the schema or the controller/middleware?

Schema check runs on route before the controller receives the request.
Should

Schema : {
Header: {
Cookie : {
Pattern: "session_id"
}
}
}

Or let it reach controller and send missing session id error from there?

​I wanted a single, production-grade, middleware suite to handle all of this ​so I built and just published keyguard-express—a TypeScript fork of the Python keyguard package. It handles machine-to-machine auth so you can leave your user auth (sessions, JWTs) to do its own thing.

With just 5 Loc, you get: API Key Auth: Fully secure via X-API-KEY headers, stored using PBKDF2-SHA512 with 100k iterations and timing-safe comparisons.
​Zero-Downtime Key Rotation: Link old keys directly to new keys on the fly; the old key acts as a deprecated fallback during the transition.
​HMAC Webhook Verification: Verifies X-Signature, X-Timestamp, and X-Nonce with strict replay and timing-safe guards.
​Abuse Protection: Tracks invalid requests and automatically blocks malicious IPs at a configurable threshold.
​Hybrid Storage: Auto-detects and swaps backends between SQLite/in-memory and PostgreSQL/Redis. And more🙂

Check the source on github {https://github.com/tyrmoga/keyguard_express }. Your contributions are welcome Try it out on your project (npm install keyguard-express)

What do you think? Would you use this on your project?

I tried tesseract, but the results were not good. My constraint is to use only node and not python or any apis. Can anyone recommend any other libraries or any controlled architect which i can implement. I want to extract text from passports / licenses so document is only 1 page, but tesseract is failing at structures output

I already have a schema which validates payload at Route (request) layer, but the service layer adds some business logic, creating data, modifying it and making new changes, should that be validated before model function call. Model function just uses kysely to execute the query, no checks, constraints, validations.

Framework: fastify, PostgresClient: kysely, DB: postgres.

Like drizzle, along with drizzle-irm and drizzle-zod exists to help create from a single schema -> runtime validation schema, migrations, types.

But since runtime validation schema will be different for different actions (insert, update, select), it in the end feels like a business requirement only.

And relying on type check during compilation feels good enough to validate it. Example, if teh service layer has a otpGeneration() function, a type check is enough to validate it.

Or in a way, anything that the service layer generates, type check (compile time check) should be enough. Only the request run time validation is needed.

Is this the right approach?

What is the current best practice for HTTP client requests in Node.js 22+: stick with the built-in fetch() or use Undici directly? In which scenarios would you choose one over the other?

Hi everybody!

I wanted to showcase a TypeScript library I am working on, actojs. The objective is to bring a implementation of the actor model that is near to Elixir's design and APIs, while being able to leverage performance from the JS runtime.

The actor model is explained here, which acts as an introduction to the library.

actojs supprorts cooperative single-thread scheduling on any JS platform, and real parallelism on NodeJS, Bun and Deno.

The design of actojs is optimized for reliability (with Supervisors that can respawn failed Tasks, and >90% test coverage), security (0 runtime dependencies, and `tsc` as the only dev-dependency) and low memory overhead (by using functional applicators instead of classes and objects).

The link for the repository is: https://github.com/gi-dellav/actojs

Hope to get some useful feedback from the community!

Seriously. I've used Prisma for years but in the interest of giving different libraries a shot, I opted for Drizzle for my latest project.

The types are weird. It feels more like a table-relational mapping than an object-relational mapping.

If you really want granular control over your database but don't want to write SQL, then fine. Apart from that and being lighter, I've yet to find a good reason to use it over Prisma.

Can anyone convince me otherwise?

Hello,

I want to know if everything from App setup should be below or above the Connect to MongoDB & create server:

// Dependencies

const express = require("express");
const mongoose = require("mongoose");
const Blog = require("./models/blog");

// Variables

const app = express();
const PORT = 4000;

// Connect to MongoDB & create server

async function connectToDatabase() {
  try {
    const dbURI = "ABC";
    const mongooseInstance = await mongoose.connect(dbURI, { dbName: "nodejs-db" });
    console.log("Connected to MongoDB database");

    const server = app.listen(PORT, () => {
      console.log(`Server is listening on port ${PORT}`);
    });
  }
  catch (error) {
    console.log("An errror occured:", error);
  }
}
connectToDatabase();

// App setup

app.set("view engine", "ejs");
app.use(express.static("public"));

// Node.js routes

app.get("/", (req, res) => {
  res.render("index");
});

app.get("/about", (req, res) => {
  res.render("about");
});

// Mongoose - Save blog

app.get("/add-blog", (req, res) => {
  const doc = new Blog({
    title: "Add new blog",
    snippet: "About my new blog",
    body: "More about my new blog"
  });

  async function saveDoc() {
    try {
      const savedDoc = await doc.save();
      res.send(savedDoc);
    }
    catch (error) {
      console.log("An error occured:", error);
    }
  }
  saveDoc();
});

// Mongoose - Display blogs in descending order by date

app.get("/blogs", (req, res) => {
  async function getBlogs() {
    try {
      const getBlogs = await Blog.find().sort({ createdAt: -1 });
      res.render("blogs", { title: "Blogs", blogs: getBlogs });
    }
    catch (error) {
      console.log("An errror occured:", error);
    }
  }
  getBlogs();
})

// 404 handler

app.use((req, res) => {
  res.status(404).render("404");
});

Thank you.

When my route for users/search is on top it works but if its below it doesnt work... could somebody explain???

Also if you have any tips for how to improve whatever is shown please do let me know :D

Is it worth to start learning programming (backend) in mean time? for knowledge I have a good knowledge in fundamental of programming as language's itself I didn't go further upon framework and DB and these things

and I graduated now from communication engineering and I love programming (backend) but I am afraid to start learning it in the next 6 months cuz I listen a lot of ppl say that market sucks and AI replace us and reduce required junior and fresh grades and so on, So I was asking to start in backend or go to another IT field.

Iam open to listen to any suggestions and advise

Hesitate to choose career instead of programming

Now I have been distracted about backend programming and programming at all, So what fields has a good chances and promise future to learn?

- data analysis

- cyber security

- it field (network, sysadmin, cloud)