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.
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 am building an ecommerce website for a project for my portfolio, and I wanted to know where the calculations should be done for the cart.
Normally I use react and I create a model folder, route folder and a controller folder but the way I was taught Angular it seems like the services acts like the routes and the actual calls to the database are done in the node server file which I am sure I could separate into a separate controller file. My question is where should the calculations for the cart be done before I send the order to the database? I thought about doing it in the cart component before the order is place or should it be done in the services or in the backend in the controller? I am just trying to figure out what is the standard
When writing an Angular app, I think it is important to adhere to the following principles that:
Components - should have a single responsibility for simple view logic only, shouldn't reach out to the server, and shouldn't do complex calculations and/or logic that is not related to the view.
Services - should have a single responsibility for (reusable/shared) and complex logic, to do outbound communication and reach out to the server, and to act as data stores (using BehaviorSubjects).
Therefore, if your calculations are needed to update the view of the cart, I would vote that these calculations need to be made at the component. If your calculations are needed to update the items or the request to be sent to the server, they need to be made at the service.
Remember, the component "shouldn't know" how the data comes to it or how it is manipulated or sent to the server. The component should only know, given any data - how to present it in the view, and shouldn't "worry about" how that data came to it. Similarly, the component shouldn't know how the data is calculated before being sent to the server, and this would fall within the responsibility of the service that works with and processes the cart data and builds the request to the server.
However, you have to always consider the security of your app, and if a malicious data modification at the client side can affect your cart. If such caculations affect the app's security - they should at least be validated at the server if not fully delegated to it.
I don't know the calculation you need exactly, but since it is an e-commerce website I assume it is simple math such as the total payment amount of checkout.
The main role of the server is communicating to the database. If a task does not involve interacting with data, you can do the calculations on the client-side. Leaving details on client-side allows you to have access to details of your formula, and reduce the communication time between client and server.
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?
Looking for some thoughts and feedback on making async requests from dust.js template helpers:
Dust.js can make async requests from template helpers, but is it actually a good idea to make use of them? Consider this scenario...
A particular page requires several api requests to be rendered. In the page's route controller, a single async api request gets the bulk of the data for the page and passes the data to the template to be rendered. In the template there are several reusable and standalone dust helpers (can be dropped in on any page) that make their own async requests in order to display their components.
In this situation, all the dust helpers have to wait until the request made from the controller finishes before their calls can be made (when template rendering begins).
It seems that ideally (excluding having one endpoint for all data on the page) all requests should occur in the route controller in order to avoid synchronous calls, otherwise the request chain would be 1) controller requests 2) dust helper requests 3) nested/dependent dust helper requests.
Cons:
route controller complexity by calling n services to build the view model
adding display components to new pages require changes to controller and template instead of just adding a template helper
Pros:
reduce/eliminate synchronous requests and increase performance
easier to understand the view model
What are your thoughts? Thanks!
If you consider to use your templates only server side I would move everything into the controller. I like to have a controller who "controls" all the data needed for the view layer.
If you think about using dust templates in the browser (so ajax calls from the cleint) both ways in my point of view are reasonable from an architectural view.
But I would ask my self some question about user experience before deciding:
How much time would take to complete all the calls from the
controller? Sometimes is better to send partial data to the user and
give to him something to view and load other components later for a
better user experience. But if the overhead is not over some ms, I
would decide to build my page context all in the controller.
Where is the data displayed in the page? Do you need it in the first
part of the page? Or user should scroll to view other sets of data?
If the data is not consumed immediately I would decide to leave it
to the client.
I'm using WebKitGTK+ ( WebKit ) application that will be a very simple web browser running in a Linux environment as a separate executable that will need to exchange data between another application. The system is described in the following image:
Example scenario:
Event such as smart card insertion detected in Backend processing Application
smart card data is read and passed to the WebKitGTK+ GUI Application
User interacts with "web page" displayed in WebKitGTK+ Application
Data is passed from WebKitGTK+ Application back to the Backend processing Application
What are the common methods of passing data between the WebKitGTK+ Application and the Backend processing Application?
Does `WebKitGTK+ provide some hooks to do this sort of thing? Any help at all would be appreciated.
I know this is a old question, but will try to answer it to best of my abilities so that it can be useful to someone else.
Webkit is basically rendering a html page. You can connect to various signals that webkit provides and act on these signals. More details at http://webkitgtk.org/reference/webkitgtk/stable/webkitgtk-webkitwebview.html
For your back end application, if something interesting happens, you can update page either by navigating to a new url, new page contents or just by setting text of desired element. Webkit provides DOM api functions and all of these are possible.
It becomes interesting when getting data from webkit and sending it to your back end system. Again, this depends upon your specific design, but generally you can hook up signals such as navigation signals when user clicks on a button and get contents. Another alternative is to use alert handler and simply use javascript alert and process the alert data on backend side.
Shameless plug for example : https://github.com/nhrdl/notesMD. It uses a simple database backend, probably can be good use case as it sends data back and forth between database and webpage. Even manipulates the links so that desired actions take place.