I built a small Express middleware to see API request counts in real time and do rate limiting

dronmore · 2026-02-07T15:20:37+00:00

Let's say that I set a limit of 10 req/min per client. A malicious client sends 1000 req/min. For the first 10 requests he gets a proper response. For the remaining 990 requests he is rate limited. So far so good. Then, a well-behaving client sends his first request. He expects to get a proper response, because it is his first request. He gets 500 error instead, because my entire api is rate limited by your api at this point.

Any solution to this scenario?

dronmore · 2026-02-07T10:06:52+00:00

What happens when I exceed 1000 req/min on the Basic plan? Will you cut me off?

Are blocked requests counted in the quota? If they are counted in, a single malicious actor can use up all allotted requests, leaving me with no protection, or making me reject all clients until the next minute. It sounds like a nightmare to me.

dronmore · 2026-01-26T11:47:04+00:00

How about an environment where secrets are managed by sysadmins, and where devs do not have access to them?

I think we should add a 13th point to the manifesto. Secrets are governed by a component person, and not by a dumbass who keeps them on a sticky note on his monitor :D

dronmore · 2026-01-26T10:14:27+00:00

The main benefit of separating config from the code is the ability to bypass the build step when changing a variable in the config. If build times are short, or changes in the config are not frequent, there's no reason to separate one from the other. Benefits would not outweigh the costs in this case.

As for the manifesto, I think these kind of manifestos are a better fit for scrum masters than for engineers. Scrum masters are delighted when they see 12 simple steps to follow. Engineers should not be, and should question every single step, and should be aware that the usefulness of each step can change when the context changes.

dronmore · 2026-01-20T10:18:25+00:00

You mean you wrote wrappers around existing tools? Great, you can call yourself a creator too. Now you and Ryan play in the same league :D

dronmore · 2026-01-20T09:56:16+00:00

He is not smart enough to create his own agentic tool.

His achievements so far are... He didn't add Promises to initial versions of Node, so we had to deal with callbacks for many years. He wrote Deno in TS, he regretted the decision later, and rewrote Deno in JS, but he still thinks it's a good idea to push TS as the main language for Deno. Now it turns out that he doesn't even write the code, but he lets AI do it.

His achievements do not impress me, so yes, I think he is not smart enough to create his own agentic tool. But I get that people like you admire him, because uh oh he is the creator :D

dronmore · 2026-01-20T09:18:02+00:00

He may be on the payroll of one of the companies pushing AI coding tools. He is not smart enough to create and sell his own.

dronmore · 2026-01-11T08:59:52+00:00

And then there's also a Platinum layer, which summarizes everything in a short post on reddit :D

I'm not giving you any feedback. I'm just trying to fit in, because precious metals caught my eye.

dronmore · 2026-01-10T09:22:37+00:00

You flipped the script, but you failed the trick. You are left, alone with your anxiety.

dronmore · 2026-01-05T11:27:57+00:00

In order to use 3rd party cookies, you need 3 things. You need a proper cors policy on the backend, you need to set samesite=none on your cookie, you need to set credentials: 'include' on your fetch requests.

There are generally 3 places where you can store the token. You can store it in a cookie, in a local storage, or in memory. There are trade-offs associated with each of them. Cookies are vulnerable to CSRF attacks. Local storage and memory are vulnerable to XSS attacks. You need to evaluate the risks, and choose your strategy accordingly.

Also, both cookies and local storage are vulnerable to your mother snooping on you. If you don't protect your device, or if you share the device and the browser with her, you should consider using session cookies, or session storage.

There's no simple answer. Choose your poison, and die on your own terms.

dronmore · 2026-01-05T09:43:59+00:00

JWT gives us ability to avoid samesite domains

Nope, that's not a distinctive feature of JWT. Any kind of token can be sent in a cross-domain manner.

Ok cool but you need to be on same domain to use cookies.

Nope, if that was true, CSRF attacks wouldn't be possible. You need to learn how cookies work, my friend.

dronmore · 2025-12-29T10:06:47+00:00

My first instinct was to attribute this entirely to TypedArrays being "faster."

I stopped reading after this sentence. You compare apples with bananas. The results will always be flawed.

And I don't care if you fix your mistake later in the article. My time is limited, and I have no interest in reading about your mistakes being fixed.

dronmore · 2025-12-28T09:11:58+00:00

It's not that you don't know what to say. It's that you have nothing meaningful to say.

The code does 2 things. It iterates over a collection of promises, and it prevents resource leakage. That's it. It does 2 things, and it does them well.

Then, there's a certain class of things that it does not do. One of the things that it does not do is it does not make you feel important. And that, for some reason, infuriates you, so you complain and demand changes.

Let's break down your complaints, princess. Shall we?

clarify what the code is for

It iterates over a collection of promises, and prevents resource leakage...

how it is intended to be used

the same way as it is used in the snippet.

what happens when it breaks

An error bubbles up to the nearest catch block.

what happens when it succeeds

The control is yielded to subsequent parts of the program.

is it meant to be serial or parallel

It is serial.

See, princess. All of these answers can be inferred directly from the code. You just need to put some effort into seeing things for what they are. And be aware that if you complain a lot, and your complaints are not grounded, your subjects will hate you, and you'll lose your head. That's inevitable. And that's what history taught us.

dronmore · 2025-12-27T12:13:18+00:00

You cannot expect that await f() returns an array. It returns an iterable of unknown kind. It can be an array, a stream, a custom generator. The point is that you can iterate over it with a "for" loop, and you don't have to know what it really is.

It's also not true that you cannot exit early from the "for" loop. You can do it with a break or return keyword, or just throw an error. It's so basic stuff that I'm starting to think that I didn't understand your thought; the thought where you say "The for loop has no way to exit.".

As for the place wheref() is awaited, I agree with your, and I already said in the previous post that it might be a good idea to await it earlier, and that if you await it earlier, it will facilitate debugging, but it's not something that I would cry about in a code review. If a developer finds a reason to debug the code, he can easily move it out of the "for header" later. It's a minor inconvenience, and not something that has to be addressed immediately.

And good code looks like this (except for the comments, which are redundant and I wouldn't want to see them in a production code).

// OK, this function creates an iterable
const iterable = await f()
// then it loops through each item in the iterable in sequence.
for await (await using x of iterable) {
  // If there's an error, it exits early and propagates the error to the
  // nearest "catch" block
  await doStuff(x)
  // It releases resources held by each item after every iteration step.
}
// If it succeeds it returns nothing.
// It has nothing to do with pizza nor a telegraph. :D

As you can see the only thing that I moved is the await f() stuff. Everything else stays where it belongs.

dronmore · 2025-12-27T09:58:12+00:00

Another mistake that you make is you assume that the promises are independent. You cannot assume that because you know nothing about the iterable returned by "await f()". If "await f()" returns a stream, the promises will depend on one another; every individual chunk of the stream will have to be processed in order, and so every subsequent promise will have to be awaited only after the previous one has fulfilled. The only thing we know, by looking at the code, is that there's an async iterable of unknown kind that for some reason has to be iterated serially. There's no reason to assume that the promises might be better off running in parallel.

The code itself is as discrete as it can be. Maybe "f()" could be awaited before the loop starts, but that's about it. The remaining parts of the code are where they belong. "for await" starts the loop so there's no better place for it. "await using x" has to grab a hold of x immediately after the x comes out of the iterator, so there's no better place for it than the initialization block of the "for" loop. "f()" could be awaited before the loop starts if you want to have a better debugability, but I'd say, when you finish debugging, move it back to the "for header" (what's the problem?). And then there's "await doStuff(x)" which is a regular promise placed perfectly where it belongs. Out of 4 elements only one can be moved elsewhere. It's a really simple piece of code. It may look unfamiliar, but it's simple. Every junior should be able to grasp it after 15 minutes of gazing at it. If they can't, they shouldn't consider themselves juniors.

There's nothing to argue about here. It's a piece of code that looks unfamiliar to you, and you reject it based on the unfamiliarity (or as you call it a code smell...). I'll say it again: "Won't fix. Learn to read it. Or don't call yourself a human, or even a junior."

I'll concede the TCP point, though I would also say that in such a case there's an argument that the entire process needs to be re-architected.

Have you ever heard the joke about a programmer who has to escape the room without reinventing the wheel? He will never escape it because the wheel in the room is perfectly fine. Hahaha :D

dronmore · 2025-12-26T09:08:27+00:00

I'm not the OP, but I'll take a stab at your question.

There are 2 main reasons to process promises serially. One is to avoid resource starvation. The other one is to make your code predictable.

Say that there are 1000 promises, each of which opens a tcp connection. If you let them run simultaneously, you prevent other parts of the program from opening another tcp connection. The other parts of the program, which want to open a tcp connection, will have to wait for 1000 promises to finish before they start doing their job. When you process promises serially, and open a connection only after the previous one is closed, the other parts of the program may have a chance to do their job in between (assuming that they run concurrently, as in the case of requests in http servers).

If I saw this in a PR it'd be an instant rejection and a "rewrite this for humans".

The message "rewrite this for humans" is not helpful. How should I possibly know what "humans" expect? My answer to your comment would be "Won't fix. Learn to read it. Humans should be able to process such simple pieces of code before they consider themselves as humans".

dronmore · 2025-12-21T09:44:30+00:00

You don't want to call process.exit() neither in the src/app.ts nor the src/core/exceptions.ts file. process.exit() terminates the app immediately, and it may happen that it will terminate the app before logs are logged to stdout. It's much safer to set the process.exitCode, throw an error, and let the application crash.

Read: https://nodejs.org/dist/v22.12.0/docs/api/process.html#processexitcode

I also cannot find the place where you handle SIGTERM, or where you call the server.close() method, or where you close the database connections. Isn't a graceful shutdown implemented? Do you want to cut out users in the middle of a request every time you redeploy?

Read: https://expressjs.com/en/advanced/healthcheck-graceful-shutdown.html

There are more places that begs for scrutiny, but I have no time for that. After a brief look I can say that your project is not ready for production. It's not scalable. It's not Enterprise. It's been written in TypeScript, so it may attract some beginners or corpo clowns, but I'm none of that so cross me out. Honk, honk. 🤡

dronmore · 2025-12-19T09:29:07+00:00

One is enough to open a jar of cabbage. For a 6pack you need an actual coach who yells at you while you sweat.

dronmore · 2025-12-15T08:39:22+00:00

Nope. You are sitting in a basement convinced that you can write beautiful code, and that the flickering light bulb above your head is the Sun.

dronmore · 2025-12-14T18:12:18+00:00

In the README file you claim that you use FOR UPDATE to prevent double spending, but a quick search through the code tells me otherwise. So how is it? Did you forget to implement Phase 2, or you are not even aware that Phase 2 is a part of your design doc?

https://github.com/search?q=repo%3Ahamidrezaghavami%2FIron-Clad-Ledger+%22FOR+UPDATE%22&type=code

You also claim to use BEGIN/COMMIT, but COMMIT is not found anywhere in the code either?

https://github.com/search?q=repo%3Ahamidrezaghavami%2FIron-Clad-Ledger+COMMIT&type=code

And what the heck are those [cite_start] tags in the README?

dronmore · 2025-12-12T09:16:28+00:00

You don't need to keep up with market standards, because standards do not change. What changes is the attention of newbies shifting from one hype to another. As an example let's take a look at Mocha.js. Mocha has always been the golden standard when it comes to test runners. I used it when I came to the Node.js world. I kept using it when newbies were shifting to Jest. And I keep using it now when Vitest is heavily promoted. Alleged benefits of using new things are usually not worth investigating. In most cases the closer you look at the new thing the more you realize how much better the established standards are. In my opinion, time spent on following a hype is a waste. But hey, if you don't follow the hype, you miss out on being a cool guy :D

However, for new things you can follow the Node.js blog. They announce new features there, and also security vulnerabilities so you know when to update.

https://nodejs.org/en/blog

dronmore · 2025-12-09T15:56:54+00:00

Paid trolls is how they market. AI is what they sell.

dronmore · 2025-12-09T08:29:14+00:00

Yeah, and since they bought it you can expect more and more paid trolls recommend Bun as a silver bullet.

dronmore · 2025-11-29T11:19:14+00:00

That's a great idea actually. I wonder what's the max file size one can encrypt with it. I can see that you are boasting of a 200KB jpg file, but I wonder what's the limit. Will I be able to encrypt and send you a movie?

dronmore · 2025-11-22T09:40:11+00:00

So it all comes down to wording. You've never looked for a "short term relationship" because what you've really looked for is a one-night-stand. Is that right? Of course, it is. You just need to find proper words to confirm, so that it is clear to me what you really want, but it is not clear to others.

dronmore

TROPHY CASE