loading...
Cover image for Poll: Do You Know What "Idempotent" Means?

Poll: Do You Know What "Idempotent" Means?

thorstenhirsch profile image Thorsten Hirsch ・2 min read

In a very good talk about TLS 1.3 at 35c3 Hanno Böck wondered if web developers know what "idempotent" means. Now before you fall into a rage, Hanno was not mean, but rather funny, so let's take his talk as an opportunity to talk about idempotence in web applications. I'm really curious, so let's (mis-) use dev.to's like system as a poll:

Do you know what "idempotent" means or - after checking out wikipedia - used the concept in your projects?

Sometimes idempotent requests to the server are required and obvious, but other times it might be tricky ...or not required at all:

  • dev.to's like buttons don't seem to be idempotent at first, because clicking once activates the like, clicking twice deactivates the like. You might think that the request is just a toggle. But it's not. Each request contains an action ("create" or "destroy"). So the 1st click produces: {"result": "create", "category": "like"} . And this request is idempotent, because if something goes wrong on the network layer and the server receives this request twice it will still do the right thing, it will activate the like on the 1st request and do nothing on the 2nd request.
  • Medium's clapping system is not idempotent. A request looks like this: {"userId":"my123id456","clapIncrement":1} . And you can also see that it's not idempotent, because clapping once turns the counter from $old-value to $old-value + 1, while clapping twice turns it to $old-value + 2. But in this case it's not a bug, you are explicitly allowed to clap multiple times.

Please vote:

  • heart/like = yes, I already knew what "idempotent" means or used the concept in past projects.
  • unicorn = no, this is new to me or I've seen no need to implement this concept in my projects.

I for myself must admit, that I've learned the term only 2 or 3 years ago. However I knew its concept and have used it for more than 10 years in past projects. I guess the poll is pretty anonymous (maybe with the exception of the dev.to admins), so please vote with honesty.

By the way: 35c3 is one of the largest hacker events in the world and the talks are streamed live. You will also find recordings of the talks later behind this link.

// cover photo by Yves Sorge / CC BY

Discussion

markdown guide
 
 

For whatever reason I don't have idempotent in my typical software development vocabulary, even though I know what it means and its conceptual importance. I did implement one of these examples after all.

But I rarely use the word either in speech or in my internal dialog as I'm thinking about things. I certainly use the idea of idempotency, but not the word for some reason.

 
 

Almost ten years ago it was drilled into my head by the CTO. To this day (and no longer working with him for years) I still fear of him discovering that I didn't make this or that function fully idempotent.

 

Thank you for introducing the arcane term, that people should be aware of, Thorsten.

I've only heard "of" the term, Idempotent and been using functions/methods without knowing what it was 😅

1️⃣ First example is SQL server not allowing User-defined functions (UDFs) to call stored procedures (sprocs) as sprocs can have side effects (writing/update database) while UDFs do not allow it (as it needs to be pure).

2️⃣ Second example is in React's setState, where it requires to pass a pure function (meaning having no side-effects) to return a new state object instance (for reconciliation optimization).

I've only realized that after reading your linked Wikipedia article under Computer science meaning section in which it reads,

in functional programming, a pure function is idempotent if it is idempotent in the mathematical sense given in the definition.

 

I knew the term from a discussion on GitHub (and had to google it back then), but I had used idempotency for years before — just without knowing that there's a word for it. That's probably the case for a lot of, if not most programmers who don't know idempotency.

(FWIW that's one of the greatest advantages of studying Computer Science in my opinion — programmers without a CS background often use the same concepts, but CS people know their names, which is basically a superpower.)

 

My favourite example of a need for an idempotent function was on an old e-commerce site I worked on. Where rather than having a remove line function it used the add to basket function with negative max int. I would have loved an idempotent function rather than having to deal with the side effects caused by a shortcut. Safe, repeatable, no side effects. That's the idempotent dream :)

 

NB: I am NOT a webdev... at all.

My definition:
f(f(x)) = f(x)

i.e.
applying the same function f() 1 or more times yields identical output (including side effects).

Idempotent has been a well talked about term in DevOps / Systems Automation circles for a while now. It's also quite popular in functional programming, and of course began in mathematics.

 

Quick way to tell whether your web app is not idempotent: You use a client-side mechanism to disable (or otherwise obstruct) a submit button once it's been clicked because the same transaction can't be allowed to be submitted more than once. If a transaction can be processed more than once - irrespective of what's happening in the client - the implementation isn't idempotent and is still capable of processing the same thing more than once. It's increasingly rare to see this kind of thing in the wild, but it's still out there.

 

Another example of idempotency is the REST architecture in which everything but POST should be idempotent. Repeated GETs should yield the same result, same for DELETEs and so on.

 

Repeated GETs would not yield the same result though, unless the server is a douchebag and disallows edits like Twitter does :)

 

The REST architecture separates resource representation (the response, the state) from the operation. So, repeated GETs will result in the same operation on the server (so it's idempotent), while the actual state might have changed in time.

Instead repeated POSTs will result in new resources being created, so it's not idempotent

It's slightly different from what you intend

By that definition, I guess I have used the concept, even without knowing the word.

 

I was aware of the concept but not the word. Great post!

 

I already knew what "idempotent" meant from a mathematical point of view, but never really thought about how the concept could be used to build "retry-tolerant" systems, so I went for the unicorn. :-)

 

I'll never forget when I had a senior say "you need to make that an idempotent route".....

 
 

wait... it's not item potent? my world is shattered