Skip to main content

Idempotency in Web Applications



In web applications and user interfaces, idempotency often appears as duplicate submission protection. A common scenario is a user accidentally clicking a form’s submit button twice. If the backend simply inserts a record on each submission, the user would end up with duplicates.

To prevent this, developers add safeguards: for example, disabling the submit button after one click, or generating a unique token for the form. Brandur’s post on Stripe’s approach illustrates adding a hidden <input> with an idempotency key to HTML forms; if the user resubmits, the server can detect the same key and ignore the duplicate request.

1. Disable repeated clicks: On the client side, disable or hide the button after the first click to avoid multiple submissions.

2. Hidden tokens/keys: Include an idempotency key or unique token in the form data; the server checks it like an Idempotency-Key header.

3. Idempotent endpoints: Where possible, use idempotent HTTP methods (e.g. PUT instead of POST) for actions, so retries are safe.

4. Confirmation pages: After a form submission, redirect to a new page so that browser refreshes don’t resubmit the form.

By combining front-end measures (like disabling buttons) with server-side idempotency (tokens or deduplication), web apps ensure users’ repeated actions don’t cause unintended duplicates. This improves reliability and user experience.



Comments

Popular posts from this blog

Mindset — Coin-Size Summary

  Theme: Your beliefs about ability shape your success. Two Mindsets: Fixed Mindset: “I’m either good at this or I’m not.” Growth Mindset: “I can improve with effort and learning.” Key Message: Talent matters, but belief in learning and persistence matters more. Applications: Work: View challenges as growth opportunities. Product: Embrace feedback and iteration. Life: Progress comes from effort, not perfection. Core Lesson: “Becoming is better than being.”

Rethinking Writing Assistants: A Fresh Opportunity in macOS Productivity

In a world full of grammar checkers, writing enhancers, and AI-powered editors, one question remains surprisingly unanswered: why hasn’t anyone built a truly seamless, intelligent writing assistant for macOS that combines next-word prediction with real-time rewriting? The Current Landscape Today’s macOS users have several writing tools to choose from: Compose for macOS: Offers shortcut-activated rewriting, grammar correction, and text shortening in any app. However, it doesn’t predict your next word or sentence. Apple Writing Tools (macOS Sequoia): System-level rewriting, tone adjustment, and proofreading. Great polish, but still reactive rather than proactive. Fixkey: Adds voice-to-text and real-time rewriting with support for multiple languages. GrammarPaw: Lightweight and powerful, with ChatGPT integration, but requires manual activation for each rewrite. Cotypist: Possibly the closest to predictive text—offers GitHub Copilot-style autocomplete across macOS apps, but lacks grammar...

Idempotent Database Operations

In databases, an idempotent operation is one that, when repeated, produces the same result as a single execution. A common idempotent pattern is the UPSERT (update-or-insert) operation. For example, running INSERT … ON CONFLICT UPDATE with the same values multiple times will not create duplicates – it either inserts a new row or updates the existing row, but repeating it makes no further change. In contrast, a naïve INSERT statement without conflict handling will create duplicate rows on each execution, which is non-idempotent. Similarly, UPDATE queries that set a field to a fixed value (e.g. SET status = 'active') are idempotent: once the value is set, running the update again has no new effect. Deleting a row by its primary key is idempotent as well – after the first delete, further deletes simply find nothing to remove. Database constraints and keys also help: for instance, a unique constraint can silently ignore or reject duplicate inserts. Transactions contribute by making...