Hello,
I’m starting to create a (old) website from scratch and was planning on automating a lot of the manual proceding.
Right now the process involves a lot of human interaction:
- Client sends us an email or uses a form (which sends us an email)
- We check the email for a name and a phone number
- We assign a code to the client, and send him an email with said code
- We check if the stock is available and then contact the client arranging for pickup
My idea was to completely automate the process (except the phone calls), but while I’m sure I can code 90% of it, I’m stumped on how to avoid concurrency.
Specifically I intend to create a “queue” of the orders to be worked, but we usually have 2 people working on this step at the same time, so how can I temporarily remove the first order from the queue so that the second worker doesn’t work on the same order as the first?
My thought was to have a “next order” button so the users don’t see a list but rather just the current order that they are working on, I’m just stumped on how to have the currently worked on order not served to two users.
Any tips are appreciated thanks a lot!
Mongo has locks, you can’t do simultaneous writes on the same resource, only simultaneous reads:
https://docs.mongodb.com/manual/faq/concurrency/
If you’re getting around that, maybe add a flag of some kind to the data that shows it’s been dealt with once a write has finished, and filter out those from results when a user pulls down orders? Possibly
Edit: there is another option here, which is to use a job or a message queue, so you literally queue up these orders and deal with them that way. That would completely remove any issue, as they have to come through one by one, and once they’re off the queue they’re off the queue. Would need to understand why there are two people working on the data at the same time though, as this seems to be the main complication - if two people need access its a bit (not much, but a bit) more difficult.
If this is written in React (and I’m sure other front ends can do as well), is it possible that when one worker “checks out” the order to work on, the state can be updated so that the order becomes styled differently and can’t be clicked on, or moved to a new queue? (working queue)
@DanCouper basically think of it like a call center: people put orders in and operators have to call them back (not the IRL case but just to give you the idea), so operator A clicks next order, and the first item of the queue pops, operator B clicks next order and the (now) first item of the queue pops. Each order needs to be dealt with accordingly (client doesn’t pick up, pickup date set for X, items found = Y, client wants shipping instead of pickup, and so on and so forth). I’ve looked into job/messaging queues (Bull, bee, ecc ecc) but I can’t say I have any prior knowledge of how they work, or how to implement them, do you have any sort of material on them?
@AdventureBear I’ve thought about creating a different queue, but what happens when an operator closes the browser without saving, or the power goes out? wouldn’t the order be “stuck” in the working queue? Maybe I’m missing something but I really don’t have a clue how to implement an automatic check to transfer “incomplete” orders back
EDIT: I’d like to point out (I really should’ve specified) that I have never learned a front end framework like REACT or Angular, but I use NodeJS + Express + Handlebars, so would all of this be easier with said frameworks?
I dn’t know the answer, but what happens in GIT if you checkout a branch and work on it and don’t save your changes is that it can really screw up your system! Maybe creating a “temp” working flag that is always reset to “available” until the order is closed when the DB is requeried at certain intervals…like how when you order tickets online you have 15 minutes to pay for them. Give a time limit to close the order. Just some ideas. I don’t know if there is an industry standard idea.
Ok, that makes total sense, imo use a message queue. How that part of the system works should not be relevant to the front end - at one side you have a form that chucks something into the queue, at the other end a client for the employees that allows them to pull stuff out and work on it. Message queues are awesome because it doesn’t really matter how you implement those bits as long they can either send or receive a message from the queue, it shouldn’t even really matter what language they are.
So I’d advise going through the RabbitMQ tutorials: part 1 here. Even if you don’t go for that, the tutorials should be informative, they’re well done.
Rabbit is good: easy to use, very solid, very widely used, massive userbase. Quite heavyweight though, if extremely common in Node-land.
Lots of solutions seem to just advise using Redis; Node is pretty good for queues, but it needs something to back it, and Redis seems the most common solution for that (it’s lightweight, available everywhere, stupid simple, extremely quick). Google for ‘message queue node redis’ and you should get a big pile of useful results ifyou dig around. Several out of the box solutions - RSMQ seems quite a nice one.
I couldn’t find much specifically Mongo based, Redis is what you’d normally reach for, but there is Agenda, which is a job scheduler rather than a message queue per se (think “I want the application to do X every Y hours”), but you can use it as one - there are instructions on how to hook in the readme.
Kue is another job queue that can be made to do what you’re talking about. Worrying large number of GH issues though.
Alright thanks a bunch! I’ll browse through and see what I can come up with!