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.
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?
My project involves somewhat of a checklist. Initially, I used Redux to keep track of the state (whether something is checked off or not). Later I implemented a backend node server and a mongo database, and I load data from the database every time I fire up or refresh localhost. Since the checkoffs directly modify the elements in the database, there's not a whole lot Redux is doing that pre-emptive loading isn't already doing.
So my main question is that if the data is fetched from the backend the moment I start everything up, what else can I use Redux for in this case? I know my project might be too small and simple to give out a good answer, but I'd still like to know possibilities if possible.
No matter, your data is coming form backend but you still need redux for many reasons. Redux is not about just for storing data but it best for performance. Let discuss it with use cases.
Suppose you have main component of COMPANY and that is fetching data from API/backend and data cam to COMPANY component and same data is required to your ADMIN component and you again call network for data, and you know fetching data for each component from backend is very heavy and make your application slow.
So the best solution is to fetch all you data one time and save them in REDUX STORE and distribute data over your components.
MAIN ROLE:
1- Easy to manage data and state
2- Optimization and performace improvement with SELECTORS
3- Debugging is very easy
4- Easy to track data
I'm currently working on an analytics webapp with a react frontend and node (express) backend.
Describing the functionality in a nutshell:
A user will be able to login on the website, search for a YouTube username and then the YouTube API is called, the data will be stored in a mysql db via my express API and also the data will be used to calucalte some statistics which afterwards are displayed in a dashboard.
Now I was wondering if I should:
Call the YouTube API from the frontend, i.e. inside my react code, do the calculations display them and and then store it in the DB via my express API.
Or, from the react app call an endpoint in my express API that will then call the YouTube API, store the data in the DB and then pass on the data to my react app.
Are there any best practices or up-/downsides to either approach?
When answering questions like these, it's important to remember that the client-side is different for each and every user that visits your website, their internet speed, their GPU & CPU power, etc., but the server is most commonly held in a stable container and much more powerful than a client.
The proper way would be the following:
1. Obtain a search query from a client
Meaning you should get the user's search query from an input, or any other form of control (text area, checkbox, etc.), this way client is doing the least business logic, as it should. The client should always focus more on UI / UX rather than business logic.
2. Send query to the server
Let the server use the query you've just obtained from client, call the youtube api from the server (either explicitly using Axios, or find a node.js youtube library), and do all the necessary calculation on the backend
3. Send processed data to the client
Let client receive the data in the form which is ready for use (iterations, mappings, etc.) - again separating concerns, server - business logic, client - UI / UX
Now to be fair, the example you have will most commonly be done all on the client-side, since it is not as computationally heavy as other enterprise examples, but this is a good rule to follow for big projects, and no one would really complain if you did it this way, since it would be the proper way.
Have small app (My first Node js App), where I want add changing real-time content.
For example I have a common url which have list of content link, when user click on particular link it will open its correspondence link.
I have teacher and student role in the app so if teacher open the specific content(From the common url page) then it will automatically open that content for all student who have common url.
Please give me any Idea to implement this functionality and please tell me any plugin who have same functionality for real time content change.
One way, probably the easiest would be to use websockets, an easily manageable choice is socket.io npm package. What makes websockets different from http requests is the direction of the data flow. While http is pull based, meaning that a request has to be made to the server in order to get a response, websockets - once the connection is established - are or at least can be push based, meaning that the server could push out content without having to get a request from the client. In your situation, the teacher and the studens would all have an active websocket connection with the server. When the teacher clicked on a certain view, it would push the view’s data requirements to the students without any interaction from their side and the view would update on their screens according to the pushed data.
Look into how websockets work and try to experiment with a basic socket.io setup.
I try to solve my problem about architecture of application which is based on node.js. I have some ideas but I'm wondering about your thoughts.
well, my application will be stored activities from customer websites,
activities which will be defined by customer, eg. login on website, click on product, click on the category menu etc. These events will be pass to my application and after that, I show actitivities to customer dashboard for analytics or for another purpose.
First of all I think about sending request by ajax from websites to my server and after parsing data on my node.js server, send that data to dashboard account via socket.io. The user will see every event from him website on dashboard "on the flight". Do you think that concept is ok? Does every ajax request will not be too much costly ? Maybe I should think about another way to send data to my server?
You are trying to design classic analytical application which assembles data from different sources and shows some analytics upon this data like Google Analytic and so on.
Does every ajax request will not be too much costly?
Maybe I should think about another way to send data to my server?
For web applications that’s standard way to send data from client to server. Of course, Http protocol has more overheads comparing to UDP, WebSockets or protocols upon them but it doesn’t need additional security configurations, easy to use and scale. WebSockets require keeping TCP connection all the time and is harder to scale. You can find many post about comparison these protocols like here.
According to this question your app is going to be a proxy of events from web sites to another web apps where them will be analyzed somehow. Every event will have some information like type (login, click), url, user, date and so on. It can work up to some loading. Apparently, you will have problems on browser side accepting more 100 events (requests) per second even via WebSockets. JS with single-thread execution model is not so good for analytics (filtering, calculation, aggregation). I think you don’t need to pass events to dashboard as they are, it would be more useful to send some aggregated data like new events count, event histograms and so on. So, in this case you need to perform analytics on backend side (node.js app).
I recommend you also to look at CQRS approach where storing data (events) and their retrieve (query) is separated in order to achieve good performance for both write (log events) and read (retrieve events or some analytics) operations. Apparently you may need to use some database to do analytics like Mondo DB, maybe Redis and so on.