I am new to node and back end so please excuse me if my question seems dumb.
My use scenario is as follows:
I have a simple UI that will make only one ajax call at a given time. I have a node js backend that will take this call, make a login call to a webservice and use the response data to make another get call. When the call is over I will make a logout call and delete the login response data.
Problem:
The problem is that being single threaded and async and having no database the logout call will invalidated the login data for all the calls coming afterwards or that are in progress. I need a way to persist and encapsulate the data for each call without blocking the IO for each request.
Solution:
The only thing that I thought so far was to save the login data into dynamic created variables (based on the UI caller ID) and delete those vars when the call is over. However this seems like a very error prone solution that might also cause memory leaks.
I do not want to persist the data into a database and could not figure other solution, can you please advise?
Related
Let's say, hypothetically, I am working on a website which provides live score updates for sporting fixtures.
A script checks an external API for updates every few seconds. If there is a new update, the information is saved to a database, and then pushed out to the user.
When a new user accesses the website, a script queries the database and populates the page with all the information ingested so far.
I am using socket.io to push live updates. However, when someone is accessing the page for the first time, I have a couple of options:
I could use the existing socket.io infrastructure to populate the page
I could request the information when routing the user, pass it into res.render() as an argument and render the data using, for example, Pug.
In this circumstance, my instinct would be to utilise the existing socket.io infrastructure; purely because it would save me writing additional code. However, I am curious to know whether there are any other reasons for, or against, using either approach. For example, would it be more performant to render the data, initially, using one approach or the other?
I'm experiencing an issue in my node application with accessing the contents of a mongoDB collection via mongoose.
this problem only ever happens the very first time my application makes a call to the database collection. what should occur when the user presses the submit button, is that the contents of the collection should be added dynamically to the DOM. However, this does not occur. but when I check the collection via the command line interface, the user submitted data is there, and then when I press the refresh button on the browser (which hits the same route the user was redirected to upon initially submitting the form) the data renders to the page like it should have the first time.
When I noticed this, i tried starting from scratch. I dropped my database, restarted my server, but this time, I used robo3t to create the db and the collection before I started my app and filled out the form data, and viola, when I submit my data and hit save, the information gets saved to the collection AND rendered the the page successfully the first time.
So i went and looked at the different Model methods provided by mongoose and thought maybe I just needed to add a function call to initialize the collection sometime before calling Model.find() but everything i'm looking at tells me that the collection is already (obviously) initialized when you call mongoose.model()
so i'm a little confused about what to do in order to make sure my data gets rendered to the webpage the first time the user submits information, rather than after refreshing.....i've been careful about awaiting all the async functionality but maybe I missed something?
the repo is here in the unlikely case someone wants to clone this and try to recreate the situation. Let me know if there is more information I can provide
https://github.com/Funkh0user/TripCheq-Travel-Assistant
Thank you.
I Solved it. I needed to rearrange some things such that the block of code responsible for doing some computations and then sending the result back to the application was in the callback for model.find()
Thanks!
My endpoint
POST example.com/user/transfer/
should not be able to be called by the same user until his earlier request has been processed. How do I do that?
Ideas
Keep a request Nonce in the user table (database) and make sure it can only be used once.
?
I might be not wrapping my head around it the right way.
Hi I´m trying to make a unit test creating some fake data and executing a request (using supertest) to check if the controller works well.
The problem rise up when the controller tries to get the fake data, because it exists only inside the transaction.
So my questions are:
Did someone make a junit like test using node.js and express?
How do you manage the database data? How do you do rollback on it?
Thanks in advance.
If I'm understanding you correctly, you are trying to run a bunch of api calls with some fake data, but you are unable to actually get the data from database?
If that's the case, one of two things I would suggest:
Allow your api to update the db, then retrieve from db. When your tests are done, you can do the full clean up at that point (that can be achieve via the after() in mocha)
Use sinon.js, and stub all db calls to return some fake data that you know.
I have an interesting problem that I need to solve and I have no clue where to even start. I am writing an MVC web application that take a list of records via a form and will make an ajax call for each. The controller that the ajax call hits uses a resource that can only process one request at a time. The simple solution is to change the ajax calls to synchronous, however, that hangs the browser and gives a poor experience.
Also, it is possible that multiple users might use this app concurrently so queuing on the client side will not work.
Anyone have any suggestions?
Mike
Well first off, my requirements are not quite the same as yours. My problem was that my backend database tends to be a little slow, and user responsiveness was extremely important.
Therefore, I had to remove the database interaction from the equation.
My solution has two main parts:
Maintain a server side cache of the data
Create a separate process to contain all database work that can interact with the server
The separate process was implemented as a named pipe WCF service hosted by a windows service.
The basic process overview is:
User clicks "Save", Ajax post the form to an Mvc controller
The controller updates the cache data, then invokes the WCF pipe
The service pushes the data into a concurrent queue (along with a session ID), and returns a guid token
The controller returns the token as a JSON response.
jQuery Ajax handler intercepts the response and saves the token into a UI element that 6. represents the "Saved" form.
The service itself works like this:
On start create a timer.
On Timer tick:
Stop the timer.
Remove all queued work items from the concurrent queue
Send each item to be processed by the work processor
Add the item to the "Completed", or "Has an Error" concurrent dictionaries, keyed by the earlier session Id (along with some time keeping stuff to eliminate stale data). This includes the original work token.
Start the timer again.
Back in user land, there is a javascript setInterval loop running:
Ajax request to the server (Heartbeat controller)
The controller connects to the service, and passes the current session id
The service returns all items from the "Completed" and "Error" dictionaries
The controller returns the lists as JSON object arrays
The javascript loops through the returned lists and uses the tokens to do appropriate UI updates
The end result is a very responsive UI despite the slow backend persistence server.
If you want any specific portions of implementation code let me know.