Most of us implement idempotency the same way the first time. Check whether you've seen the key, and if not, do the work and store the key so the next request knows:

app.post("/charge", async (req, res) => {
  const key = req.get("Idempotency-Key");
  if (await redis.get(key)) { 
      return res.json(JSON.parse(await redis.get(`${key}:result`)));
  }

  const result = await chargeCard(req.body);      // real money leaves here
  await redis.set(key, "done");
  await redis.set(`${key}:result`, JSON.stringify(result));
  res.json(result);
});

It reviews fine. Then two things happen in production.

Two retries arrive at the same moment. Both reach the get before either reaches the set, so both charge the card. A load test finds this one if you go looking.

The process dies after chargeCard and before redis.set. The money moved, the key was never written, and the retry charges again. This one you can't easily reproduce on purpose, and it happens on its own during any deploy.

Fixing the first properly means the check and the write have to be one atomic operation, so exactly one caller wins. That creates the next problem: the winner can die holding the key, so the claim needs a lease that expires. Which creates another: the "dead" worker might just be slow, wake up, and overwrite the real result with its stale one. So the write needs a fencing token that the reclaimer invalidates.

I got tired of rewriting that, so it's a library now:

import express from "express";
import { idempotency } from "idemkit/express";
import { RedisBackend } from "idemkit/redis";

const app = express();
app.use(idempotency({ backend: await RedisBackend.fromUrl(process.env.REDIS_URL) }));

app.post("/charge", async (req, res) => {
  res.status(201).json(await chargeCard(req.body));   // runs once per Idempotency-Key
});

Same thing works for queue consumers (SQS, Kafka, RabbitMQ, BullMQ) and plain function calls. Redis, Postgres, Mongo, DynamoDB or in memory. Zero dependencies, Apache-2.0.

https://github.com/idemkit/idemkit

If you find it useful, a star would be much appreciated.

Lemmy isnt ready for this project and so deleting the post

I hope this project has reached a level i can share the following details. I've made a genuine effort towards documentation and transparancy. I dont think it'll ever be enough and so im still concerned it isnt ready to share. While im using AI throughout. This is not a vibecoded project. There is attention throughout for unit tests and formal-verification. With your feedback, id like to make improvements for clarity throughout.

This version of the app demonstrates a fairly unique approach using a browser-based, local-only and webrtc approach. I know it's impossible for any system to be the "world's most secure", but that isnt a reason to not try. By rigorously implementing an exhaustive list of security features and practices, the aim is to get as close as possible.

• Enkrypted.Chat

This is intended to demonstrate client-side managed secure cryptography.

• Introducing Enkrypted Chat
• Whitepaper (work-in-progress)
• Protocol Spec (work-in-progress)
• Roadmap

I know the project above is going to be tricky to understand. It might help to understand with an open-source version of the concept for educational purposes. Its's important to note, i have since deprecated it in favour of the version linked above.

Open source demo (deprecated)

PS. Im calling it a "Signal Messenger Clone"... that's just a matter of how to frame it for users getting started. It doesnt work in a way thats comparable to the signal architecture. This project is fairly complicated and the links above are likely not going to be enough, so feel free to reach out for clarity on the details.

PPS. I made a similar post on Reddit and it seems to be reasonably well recieved and so branching out to Lemmy here. It might help to take a look there if questions are asked/answered already. https://www.reddit.com/r/BuyFromEU/comments/1v8cx0s/europeanbased_signal_messenger_alternative/

I like the full-stack framework SvelteKit. It inspired me to write something more minimal, even brutalist, based on Preact, a few small focused modules popular in its ecosystem, and Vite.

There's intentionally not much API. Documentation entirely fits in a long but straightforward README. Like the Django tutorial, it guides you through writing an application using all the primary features of the EviKit framework.

I wanted to use standard modern JavaScript as supported by Node.js 24+ directly. With strict JSDoc type annotations. So no separate language server is needed - you can use Emacs, Kate or any other modern editor of your choice that supports typescript-language-server. Linting using ESLint and Prettier also works without extra plugins.

There's neither JSX nor a new templating language to learn. There are JS helpers for creating common elements, e.g. you write p({ class: "nav" }, a({ href: "/" }, "Home")). You use JS map for loops and ternary operator for conditional constructs.

I focused on old-school urlencoded and multipart forms, and the app is rendered on the server, so apps should remain partially accessible even when JS doesn't load. At the same time, an EviKit app is a proper SPA, hydrated with client-side routing (with URLPattern-based server-side counterpart) and conveniently made dynamic with React-style hooks.

I want to ease the writing of bots and interoperability with low-code tools. So apps generate OpenAPI (Swagger) specification for your API.

Input/output validation using Valibot is first-class. Type checking catches if e.g. after an upgrade your API starts returning something different from your declaration. With less need for boilerplate unit tests, you can focus on end-to-end replication of real user scenarios.

Most apps need databases. Why not try the node:sqlite built-in? I made it easy to declare a schema using the same Valibot helpers that I use for API declaration. EviKit keeps the database in a standard location following the XDG specification. You can save file uploads as SQLite blobs.

Translatable strings of your UI can be automatically extracted using GNU Gettext tools, well-known in Django, WordPress and Linux desktop app ecosystems. I recomment the Poedit editor for translating the resulting .po files. Your app is shown in the browser language if there's a matching translation, with English fallbacks.

For styling, I wanted to avoid non-standard hacks that make Node.js "import" CSS, so I recommend going with daisyUI and the now usual Tailwind CSS.

There's a real-world FOSS app using EviKit: Lanquiz, that lets you import Kahoot quizzes and self-host them in LAN from a laptop during blackouts.

Non-goals: cloud deployment (I only target VPS and LAN apps), competition with Pracht scope (I guess there are bugs to fix, but the framework is more or less finished).

Last but not least, no "AI" whatsoever was used for writing the framework. I don't have a hardline stance, it's more that I don't see how it could be useful for this tool. LLMs let people come up with ever mode code and boilerplate, while I want radically less of it. If you'd like to contribute, let's keep it simple and human.

TLDR; The title of this post.

Feel free to reach out for clarity instead of reading the code/docs.

I was working on a “react-like syntax for webcomponents”, I wanted to create something robust and flexible for secure data storage and management.

I started off with an approach for asynchronous state management so that components outside the shadow-root could receive updates. (The events are also encrypted to secure against things like browser extensions.)

https://positive-intentions.com/docs/projects/dim/async-state-management

It then made sense to be able to persist that data so it can work between page releoads.

https://positive-intentions.com/docs/projects/dim/bottom-up-storage

The result looks and works like the following when used in a project.

https://positive-intentions.com/docs/projects/dim/encrypted-store

The Dim framework seems like a dead-end. I wanted to try it out on my existing React projects. So I created the equivalent React hooks.

https://positive-intentions.com/docs/projects/dim/use-dim-store-react

I find it to be performant and I want to push the scale of the approach, so I am in the process of testing it out on my projects. A notable use-case there is storing encrypted files at rest.

IMPORTANT: Im not trying to promote “yet another ui framework”, this is an investigation to see what is possible. You should not use this in your own code. It is not reviewed, audited or production-ready. It is not on npm. Shared for testing, feedback and demo purposes only.