I'm developing a online bookings web application using MERN. My main concerns are:
Can somebody elaborate how should I approach these two concerns?
To build a transaction system like yours, you need both atomicity and concurrency security. As long as you're dealing with a single collection, you should be fine.
Building on top of Vasan's answer, something like:
db.collectioname.update(
{'available' : true, 'seatId' : 'xxx'},
{$set: {'available' : false, 'transactionID' : 'xxxx'}}
);
would suffice in a simple environment.
However, most booking systems involve mutiple collections in real life. You would need database level locking in that case. If that's your use case, I am afraid, using SQL would be a better solution for this part of your product. Most applications anyway these days need both a SQL and NOSQL database.
Vasan Subramanian
Previous generation techie
Concurrency
Even with SQL databases you have to deal with the fact that the web app UI is showing the item as available to multiple users, but it should let only the first one book it. This is not special to the MERN stack.
The simplest approach is to have a collection of bookable items, with a
bookedfield. When booking an item you'll use anupdate()to setbookedtotrue. In the update, in addition to the item ID in the filter, you'll add abooked = falsecriterion. If it fails (saying such a record doesn't exist), it means someone else has grabbed it, and show a message to the user.For a more generic solution where you want to prevent overwrites, many people use a version field which is updated every time the document is updated. For MongoDB, an ObjectID is a natural choice for the data type of this field. When updating a document, the caller has to supply the value of the version field from the
find()call, and handle a failure as a conflict.Security
httpsmodule. You'll find tons of tutorials on the net on how to do this.dangerouslySetInnerHTML()).