Hello, I used nwjs to create a NodeJS application to work with RPG Maker MZ projects. What it does is that it reads the project, creates a list of buttons to read plugins in that project and then allows the user to edit plugin parameters without having to click through a bunch of extra UI.

It is basically a time saver application with login features for my patreon users, though I have not gotten much feedback on that login feature as of now.

Here is the itchio link with video and github links

Here is the linux github link which I work on and then transfer the app updates to the windows github link

Here's the video of me using it as well:
https://www.youtube.com/watch?v=brUfrGdk-j4

I started building a construction management SaaS in November 2025. About eight months later, it’s being used to manage more than $12M in project value.

Looking back, the biggest lesson wasn’t learning another framework or database. It was learning that users don’t care how elegant your architecture is if the product doesn’t solve their problem.

They only care about outcomes everything else is secondary

The best example was scheduling.

I rebuilt our scheduling feature four times.

The first version made sense to me as the developer.

The second version was technically cleaner.

The third version covered more edge cases.

The fourth version was the one project managers actually wanted because it fit how they already planned projects in Microsoft Project and allowed them to upload their existing schedules instead of forcing a completely new workflow.

That experience completely changed how I think about building software.

A few lessons that have stayed with me:

1. Spend time designing your entities and relationships. A good domain model makes everything else much easier.
2. Keep business logic in services and let controllers stay thin.
3. Design APIs around business workflows, not database tables.
4. Add validation and database constraints early to prevent bugs before they happen.
5. Build observability into production from the beginning. Monitoring and error tracking save countless hours.
6. Listen to users early and often. The code you’re most proud of isn’t always the feature customers actually need.

One of my favorite parts of backend engineering has become domain modeling. Turning concepts like BOQs, procurement, scheduling, earned value, variation orders, and cash flow into entities and services is where everything starts to click.

Once the schema accurately reflects the business, implementing services, controllers, and API endpoints becomes much more straightforward.

Lastly properly document your work.

Also I’m doing a thing whereby I talk more about my projects and experiences, I find it hard to share sometimes so I decided this is a good place to start since we are all node devs.

Happy to answer any questions about the architecture and why I made certain decisions.

Found it here

Anthropic's batch API is great (50% off tokens! hell yeah!), but the DX kinda sucks. Hand-writing JSONL, tracking batch IDs, polling loops...all of which is, for me at least, really tedious.

So I built batch-kit, a CLI + library that makes it feel kinda like git:

batch add --dir ./reviews --prompt "summarize: {content}"
batch send
batch fetch --latest --output results.json

It handles the JSONL, polling, and state persistence (all the boilerplate!).

Why: Python has anthropic-batch-kit, TS didn't. Now it does. Now I'm marginally happier.

Install from npm: https://www.npmjs.com/package/@otisworks/batch-kit

It's minimal, but it works. I'm thinking about support for PDFs and other document types, config files, and (possibly?) progress bars next.

Try it, break it, and lemme know what sucks. :)

Solo project I've been building: npx licenseproof scan reads your lockfile (npm/pnpm/yarn, v2/v3, berry, all of them) and resolves the actual license of every package in the tree, including the ones with missing or mangled metadata. Categorizes everything (permissive / weak-copyleft / strong-copyleft / unknown), flags conflicts against your project's license, and explains each flag in plain English.

Example: proprietary app that innocently pulled in ffmpeg-static:

84 packages scanned — 1 conflict, 0 review, 0 unknown

CONFLICT (1):
  [email protected] — GPL-3.0-or-later
    via ffmpeg-static
    This package is under a strong-copyleft license (e.g. GPL/AGPL).
    Distributing it as part of a closed-source product can require releasing
    your own source code under the same terms. Flagged as CONFLICT for a
    proprietary project.

Fully offline (no telemetry, no network calls) free tier is the whole scanner. The limitation is it's informational categorization, not legal advice. What's missing? What would make you actually use this before shipping? CI mode exists (--fail-on conflict), JSON output exists, Python support is in progress. Thanks!

When in my beginner days, Python backend plus Svelte frontend meant two repos, two deploys, and an API layer just to wire them together. For my small and medium projects, like mine, that was always more hassle than the project itself. I just wanted one repo I could manage and ship as one thing. so back in August 2022 I started a project called fymo, to make one-repo Python+Svelte projects a normal thing to build.

I got stuck early, compiling Svelte from Python and making the two sides talk to each other was beyond me then, so it sat there for a while, like my other side projects did. between years, i came back and forth, but this time it stuck, and I finished it.

fymo renders real Svelte 5 components from Python stuff like; esbuild compiles them at build time, one long-lived Node process does the SSR, and the browser hydrates them like any Svelte app.

and the there are controllers return dicts, components get them as props. Functions (Python funcs) under app/remote/ become typed functions you import in Svelte, so there's no fetch code to write. fymo new gives you a running app with sign in. fymo generate resource posts gives you a routed page, CRUD endpoints, and a passing test file. and fymo destroy takes it back out, unless you edited the files, then it refuses.

Anything misconfigured fails at boot with the fix right there in the error message. Nothing falls back silently. that's most of the design philosophy really.

But limitations, honestly: you need Node installed (build and runtime), it's WSGI not asyncio, no ORM, one maintainer, and it's v0.20 so things still break between versions, loudly though.

Repo: https://github.com/Bishwas-py/fymo pip install fymo

Hey, just wanted to share my libnode build repository https://github.com/I-A-S/libnode-builds

If anyone else here is working with libnode and want prebuilt binary+header archives, this repo builds and publishes the following targets.

1) win-x64 (debug and release variants)
2) win-arm64 (debug and release variants)
3) linux-x64 (debug and release variants)
4) linux-arm64 (debug and release variants)
5) darwin-x64 (debug and release variants)
6) darwin-arm64 (debug and release variants)

and a separate zip file containing headers.

Cheers!

FULL WEBSITE LINK

e18e (Ecosystem Performance) is an initiative to connect the folks and projects working to improve the performance of JS packages.

We'd also like to provide visibility to the efforts of countless open source developers working to cleanup, levelup, and speedup our dependencies.

We invite you to get involved in the different projects linked from these pages, and to connect with other like-minded folks.

Join us at the e18e Discord server and collaborate with our community!

I’ve been in contact with a lot of web agencies and web developers, and I personally haven’t found many people who run their agency in a more efficient way than I do. A lot of them have too many meetings, wait too long for client approval, don’t know how to price projects, and spend way too much time on each client instead of finishing the work and moving on to the next one.

I’ve been running my agency for four years, and after a lot of trial and error, I’ve managed to make the process as efficient as possible. I wanted to share some of the steps because I think they could be valuable for anyone just starting out.

Running a web agency alone or with a partner isn’t easy because there are a lot of things to take care of. When it comes to client acquisition, I recommend focusing on either cold calling or email automation. Which one you choose depends on whether you run the agency alone or with someone else.

If you have a partner, one person can handle sales while the other focuses on building websites, connecting domains, setting up emails, and taking care of the technical work. If you’re running the agency alone, or neither of you enjoys cold calling, I highly recommend email automation.

That’s what I’ve been doing for years. It’s powerful because you can send emails at scale, set up automatic follow ups, and wait for businesses interested in a new website to reply. While you’re working on one client, another opportunity can come in without you having to stop everything and search manually.

I don’t do regular email automation where I target businesses with no website. I do the opposite and target businesses that already have one.

I use a tool called Swokei to find businesses with websites, add them to campaigns, analyze each site, score it, and generate personalized outreach emails based on problems it finds with the design, layout, speed, SEO, and mobile optimization.I schedule the campaign, set up follow ups, and wait. 

I think this approach is much better for a few reasons. You’re targeting someone who already understands the value of having a website. You’re also not just asking whether they need a redesign. You’re pointing out real problems with their current site, which makes it clear that you actually took the time to look at it. Selling also becomes easier because they’ve already paid for a website before and understand the process.

Inside Swokei, you can choose the goal of the campaign. You can offer a free draft, try to book a meeting, or simply start a conversation. I always choose the free draft because that has worked best for me.

Once you’ve figured out how to get clients, the next part is building the website. I recommend using AI because it makes the process much faster. For anyone who still thinks AI can’t build great websites, I think they’re mistaken. You can use Claude, Base44, Lovable, or any other tool that works for you.

When someone replies interested, I call them and say, “Hey, I saw that you replied to my email. I’ve already built you a free draft of your website. Do you want to take a look?”

Then I invite them to a Google Meet.

At that point, it becomes much harder for them to reject the meeting because they already replied interested and now know you’ve built something for them. During the meeting, I present the website, explain why it’s better than their current one, stack the value, answer their questions, and try to close the deal.

These meetings usually go well because the client isn’t trying to imagine what the website might look like. They can already see a better version of their current site. They also took the time to join the meeting, so taking the next step becomes much easier.

I either take payment during the meeting or send them a contract to sign. Any changes and updates come after that, once we already have a deal in place.

Pricing depends on the business. I charge anywhere from $500 to $3,000 depending on the company, the size of the project, and how much value the website can bring them. I also charge a monthly retainer of around $50 for hosting, maintenance, support, SEO, and future changes.

That’s basically the entire process. Smaller steps, faster delivery, less wasted time, and more money made.

Found this gem here

The hard part of a pub quiz is remembering what you've already asked. A decent weekly quiz takes someone two or three hours to write, and the moment a regular says "you asked this in March" the room turns on you.

So I built QuizBeast. You pick your rounds (bank topics, a written-to-order guest round on any subject, music intros), it builds the whole thing in about two minutes, print-ready with answer sheets. It logs every question your venue has used and won't serve a repeat within your chosen window (default six months).

The bit that took the most work was trust. The question bank is 175,000 questions and some of the source material was wrong, so every answer gets fact-checked before you see it, and the whole quiz gets cross-checked so one question can't give away another's answer. During testing, a guest round on "Famous Richards" served a question about Freddie Mercury, who has never been a Richard. It looked plausible and it was nonsense. Errors of that shape are why the checking pipeline exists, and why it runs on every path that can produce a question.

Stack: Next.js on Vercel, Postgres on Neon, Clerk for auth, Lemon Squeezy for payments, Claude for the fact-checking and written-to-order rounds.

Free tier is one full quiz a month, no card. If you run a quiz night, or your local's quizmaster looks knackered, I'd genuinely like to know what's missing: [quizbeast.net](http://quizbeast.net)

There is a new approach I started using in my web agency that completely changed my results. For years, I did what most people tell web designers to do. Go on Google Maps, find businesses without websites, and contact them.

What I started doing differently was targeting businesses that already had websites.

The reason is simple. If a business already has a website, it means they understand the value of having one. You do not need to convince them why a website matters because they have already paid for one before. The market for businesses with outdated, broken, slow, or poorly designed websites is also massive, and selling becomes much easier because they are already familiar with the process.

My biggest issue was figuring out how to send mass outreach to these businesses without sounding generic. I did not want to send thousands of emails saying, “Hey, your website needs a redesign,” and just assume that every business needed one. I wanted to send emails at scale while still telling each company exactly what was wrong with their website.

A little over a year ago, I watched a YouTube video from Nick Saraev where he built a workflow that analyzed business websites and turned issues with design, SEO, layout, speed, and mobile optimization into personalized outreach emails. Each company received a professional email that made it clear someone had actually taken a look at their website.

The idea was great, but building and maintaining the workflow took a lot of time. I still had to find the leads myself, the messages were not always consistent, and the automation kept breaking.

But it worked.

I was getting more clients than ever before, at one point around 10 websites a week, while my business partner focused on building the websites as quickly as possible.

I started searching online for a tool that could do everything in one place, and a few months later I found Swokei. It did exactly what I was looking for.

It lets you find businesses with websites, add them to campaigns, analyze and score each website, and set a quality threshold so websites that do not need fixing are automatically skipped. It then turns problems with design, layout, speed, mobile optimization, and SEO into personalized outreach emails.

You can also set up follow ups, manage replies through your own inbox, and organize leads inside the CRM without moving between five different tools.

I switched over and scaled even harder.

Sometimes the fastest way to grow your agency is not building every workflow from scratch. It is finding the right tools and using your time to focus on sales, clients, and growing the business.

Today I decided to learn Node.js

As someone who have been building backend api's using Python's FastAPI, I feel really weird by learning another tool.

What pushed me to learn this was because I am following a project list by Roadmap.sh, specifically the Broadcast Server project which requires me to use WebSockets.

And after doing some research, I realized that Node.js is the one most suitable for building my learning project than FastAPI.

So here I am. I'm about to go over the "Learn Node.js" free course at Scrimba, and also checking the roadmaps, provided by Roadmap.sh. I am also planning to go over the Odin Project though that's only if I still need more grasp over this Node.js stuff.

Are there anythings that I am missing? Do you guys have any video recommendations or playlist that I can consider? It would matter a lot, thanks!

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?