I am working on a personal project where I want to automate the TA assignment system. I want to use Node and MongoDB for this. Though I have some idea about MongoDB, I am new to NodeJS. The aim of the projest is to do something like this :
A school administrator submits the course for which he/she wants to hire a TA.
The database is already populated with eligible students(more than two). The fields assoc with each student is [Student ID, Seniorty(sophomore,junior,senior),Course Taken or not, grade,presentStatus(Avlbl/Hired)]
At any point of time, the school admin requests a TA for a course, he gets the most senior eligible student available in the db.
Once the student is assigned, his status is changed to Hired.
I was planning to implement this using a queue. (Storing all the available students in that course in a queue and assigning the TA-ship to the senior student available in the front of the queue). As soon as he/she is assigned a TA, they are removed from the queue and pushed back into the db with the PresentStatus as 'Hired'. The problem I am facing is, I am not able to understand how I should be implementing the functionalities of the queue using NodeJS. During my research about the approach, I found something related to monq and a blog as well where they have discussed implementing it with Kue(backed by Redis instead), however I am still not able to visualize how this idea should be implemented using queues in NodeJS. Any help would be appreciated.
RabbitMQ is an option you are looking for.
You have to create a message sender and message consumer. The consumer will have a corresponding queue. Once the queue is filled with a message, the consumer will grab it and do it's process. In your scenario, it checks the student's status and then change him/her as hired in your database. What your sender does is that it packages a student's information and put it in the consumer's queue. I can imagine what will be happening in your case: a student submits request on his/her side. The node.js api receive it and pack information. Then it sends it to your customer queue. Your customer will process it if it's free. If it's busy, the information will be waiting in the queue. I recommend you to use json for students' information when different components have to communicate.
Here is the official website of RabbitMQ: https://www.rabbitmq.com/getstarted.html
Hope it helps.
Related
I am trying to design a real time in-app chat for social application using PubNub. I found that the best architecture to do so for one to one chat with PubNub is detailed in this article http://pubnub.github.io/pubnub-design-patterns/2015/03/05/Inbound-Channel-Pattern.html
now my next problem is I have to display the list of users in the chatting window, how can I sort this list with the users who have sent messages latest at the top and the ones who have not interacted for a long time in the bottom. if I start fetching message from the inbound channel, I will have to always traverse inbound channel to the beginning every time a user has logged in, this will be a resource expensive call and also is not feasible if we have large user base and heavy message volumes.
I will also be using PAM to control authorization of users to read / write on channels.
That is indeed a great blog entry!
If you are in hybrid mode, so you do use a replicate channel for History feeding anyway, then I would use that same channel and intercept it the content with a function and simply store in the channel Object the list of latest visitors ordered, by the latest showing first, you can even add any extra info you would like to it. Then, any time a user can access the Object values from a REST function to PubNub, so as to retrieve the "hybrid channel" associated Object values (stored earlier) and send that list that is always updated to the Chat user. This has an advantage: if you do not want to retrieve messages until a user taped on one of the contacts in the contact list to avoid pre-loading, then you would load no messages for any channel, except maybe the first user, but then its always less to load from History then all messages from all of the channels, and its always available, before fetched, so fastest.
Hello I have a question about choreography,
I know it's asynchronous, but in this context:
a requisition in endPoint / addEmployee (where to create an employee the existence in the department is necessary), I would check for an employee and send a message in my department queue to verify the existence and also sign up in the queue to hear the answer, would that be choreography?
Or when confirming the existence of the employee, should I create and send the response already? or can i send the response after consuming the departament queue?
Or in this case, would the orchestration be correct?
If I understand correctly you are receiving a request or a message which contains information to create an employee. One of those field is department name or id. And you would like to validate existence of this department information from department service. Is my understanding correct? If so I would say a lot easier solution would be keeping a basic department data on your employee service. You can get department created, updated events from department service and sync your data instead of asking for each and every employee.
With this solution you wont have a dependency between services. You will just listen the topic or queue to which you wont know where the message comes from which is total opposite of the coupling.
I have 2 option.
1)when addItemTobasket request come. gRPC request to product, pricing, user service and get informations . and save them to cart db.
Or not fetch other service information. Save only references like id. And save basket db. When get basket request call gRPC request aggragate all service datas as viewmodel and return that.
2) create shared redis session server and when addeditem to cart event raise itemAddedToCart includes reference ids. And main services consume that event. Product service get product with id that come with event and write Product info shared redis. pricing service price etc. When getbasket request come data is ready in redis.
For 1) it coupled all servies. it is not good for ddd.
For 2) it is async. When user add item to cart. Waits a responsr success or failed.
If there is better best practice please share with Me.
Honestly I'd say just go with option 1. It's not as complex as there aren't so many interconnected parts. Also depending on the size of your app, that kind of coupling is easy to remove later on when you gain a better understanding of what is going on.
I am developing Social network type of application in node.js and MongoDB.
I want to add a functionality such as -
If user A has followed user B then when user B post something it should automatically come to user A on his wall!
Approach 1- This is what I have research till now
Create a channel of user B and all the other user subscribe to that channel and when user B post something then emit that with socket.io on all the subscribers.
so for this approach, we are thinking to create a channel when the new user signup every time.
But the problem is -
is this feasible approach as for how do I know which channel is which user or is there a way to store the channel in MongoDB.
if I create too many channels will that crash my server?
Approach 2 -
Another Approach that I have got is
Look up the followers of the source user in your database.
And emit feeds to all the followers using socket.io
How to scale this if I have got 100 followers of each user and when everytime user post, will searching in a Database creates an overhead.
Using Redis caching would be better to store followers?
And instead of checking the followers-
find that from Redis and emit the msg using socket.io
Approach 3 -
I have heard the name of Redis pub/sub but not able to find how it will work in my application.
Please suggest some best standards for creating something like this!
And if above approaches are fine can you pls suggest me the flow for that or how do I create a code for that!
I would be great if you provide me an example.
I think you can use Approach 2, but you must create a queue (redis queue or rabbitMQ) to do that.
I mean when you create a post, it must push to queue to push message to 100, 1000 follower in your DB.
I am developing a Rest API using node js, mongo and express as technologies. My models include users, venues, etc. In addition each user has states. Examples of states could be when a user signup the first state is 'new_user', after one week the state must be 'first_week_user' and so on.
The purpose of these states is to notify the user according to his or her state. For example if a user like a picture and the user is in the first week (he has the 'first_week' state) so an email must be sent to him. I am in the design stage right now, so I want to know if somebody had to face the same issue before.
The design that I have in mind is to put a notification_profile inside the user object and using a cron job to check the state and the actions of the day and according to that send the emails/push notifications.
What do you think? Are there a better option? e.g. I can have an email API and queue the emails hitting this API. Do you know where I can find information about design patterns facing this problem?
Thanks a lot for your help.
Without more detail, this sounds like you need the Observer pattern.
Essentially, your Email component would subscribe to each Person object's like(photo photo) event, and either execute an email-send job immediately, or schedule the job to run later, as part of a batch.
One way to specify the state transitions would be as a hierarchical state machine. See http://www.eventhelix.com/realtimemantra/hierarchicalstatemachine.htm#.VNJIflXF--o and http://en.wikipedia.org/wiki/UML_state_machine
I don't have a good node.js example but here's a C# implementation that also includes the concept of timed events. Essentially the state machine keeps track of a NextTimedEventAt so you can efficiently pull it back out of a database at the right time to fire a time-based event.
Actions happen on state transitions: as you enter a state or leave a state.