bene : studio is a global consultancy, helping startups, enterprises and HealthTech companies to have better product
Restless Fingers vs. Restful Service
Our workshops are restarting!
Join the FREE ONLINE React Native workshop on August 11, and learn how to connect native modules to build an awesome Music Creator.
Join the workshop and invite your peers as well! For full details and registration visit the event page:
Most of us have faced the situation when your average user just keeps pressing a button on the frontend and makes subsequent calls to a backend endpoint. Some could say it is mainly the frontend’s responsibility to prevent this situation. But it is the backend’s role to handle it if it happens.
So let’s handle the restless finger in a restful service!
In case of a Get endpoint, which is idempotent, it won’t do too much harm, just repeatedly get the same or not the same response.
If we persist data to the backend or initiate a complex operation the situation become much more serious.
In case of a simple database update we can use an optimistic record lock to handle the subsequent calls. Of course it is working only for updates.
But what can we do, if the endpoint is adding new records or starting a more complex operation: eg. make a calculation, issue an invoice and charges the user’s bankcard in one go?
In this situation our optimistic lock is unusable, but we can try to lock the endpoint itself.
The simplest implementation would be something like this:
1. Create a hash value to the given endpoint call and use it as a key
2. Check if this key is in a store (call it lockmap )
3. If it is in the lockmap, reject the request
4. If it isn’t in the lockmap, put it in and continue
5. When the operation ended, just before sending back the answer, remove this key from the lockmap.
+1. Schedule a process to periodically remove the stuck keys
Some practical notes for a java implementation:
The ideal representation for the lockmap would be a system-wide concurrent hashmap. The implementation of the ”system-wideness” is depends on the system itself, it can be a java bean or a singleton class.
As for our map entry the key can be created in various ways: from the payload and the user’s info or the username and api url, the optimal choice depends on the endpoint itself. To create the key, use some fast algorithm such as murmur hash or even the good old crc32. The value part of the entry will be the timestamp. The cleaning service will use this data to remove the stuck entries.
So go ahead and if you need to handle the “restless fingers”, give this method a try!
What do you think?
Have some comments or want to ask some questions? Share them with us via e-mail to email@example.com and we can set up a talk with our engineers.
Read moreSee all software engineering
Build your own Christmas chat tree
Or should we say Chat-mas tree?😜 Create a working chat application in 2 hours using React, SSE (Server-Sent Events) and OneSignal on Heroku.
5 Ways to Connect Redux Actions
This article provides 5 ways of defining mapDispatchToProps with explanations. Great introduction to our Redux Saga Workshop!
Bene Studio Serverless Workshop - Calorie Counter App
Kickstart your React Native app with Firebase – Cloud Firestore (Tutorial #2)
In this series we will create an iOS and Android application — called Fakestagram — with React Native, using some of Firebase services....
Redux-Saga To The Rescue
In this blog post, we are checking back to our 25. September Redux Saga Workshop. On 19. October we are trying out a new JS Framework for cross-platform...