bene : studio is a global consultancy, helping startups, enterprises and HealthTech companies to have better product
Restless Fingers vs. Restful Service
Join our workshops in 2022
Sign up and get notified about upcoming workshops. Build exciting apps and learn about technologies like React Native, JS, Flutter etc. from experienced engineers.
Join the community and invite your peers as well! For updates regarding the upcoming event, visit the workshop 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
Workshop Recap: connect native modules to build an awesome music creator
Learn, how to work with Native Modules (both Java and Swift) and connect them with React Native.
CI/CD workshop recap: React Native automated tests with Bitrise
Build your quiz app on your own iOS or Android phone.
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
Let bene : studio enhance
your digital product!