0

I am currently using NodeJS & Express to load webpages which contain element content that is rendered via a query to MongoDB.

A GET request will create Button elements, binding the MongoDB _id to each button.

I am designing a Point of Sale system. Each button is an item with an associated price on the Database server. I can query the DB for the price of each item by passing in this _id into an OnClick function.

Each time the client registers an order of a particular item, I have to query the Database.

I could avoid querying the Database with each button click. When the webpage is loaded, I can simply store the price as the value attribute of the button. This will allow me to reduce the amount of requests the server gets by hundreds or thousands. But I will be essentially storing the model in the view.

Is this bad? Why? The functionality is the same, and the load is reduced.

Sorry if this is a dumb question, I'm just curious

Improve this question
3
  • 3
    What are you going to do when somebody modifies your DOM and sets the price to $0.01? (There are various answers to this, some very wrong).
    – Philip Kendall
    Commented Nov 12, 2017 at 7:34
  • @PhilipKendall Yeah I really overlooked that one. Everything needs to be kept on the server. I'm also storing the ID of each item and transaction in the DOM, since the whole idea is to allow the user to interact with the Database, but theoretically a user could modify the DOM and modify other transactions on the database too. I'm not sure how I would avoid putting the IDs in the DOM and still allow Javascript to talk to the database from the client...
    – Mikhail
    Commented Nov 13, 2017 at 3:09
  • My working solution now is each button press needs to query DB for item price w/ GET req, then update the transaction with a PUT request which can return the new transaction object as a response, allowing it to be rendered back into the DOM in the form of a table. My mistake was creating that table first with each button click, and then scraping the table for values and using those to update the transaction with a single PUT request, making it vulnerable to messing with the DOM. I'm still concerned about putting the IDs in the DOM, and I'm keeping the current transaction ID in localStorage...
    – Mikhail
    Commented Nov 13, 2017 at 3:18

2 Answers 2

Reset to default
1

After having worked on a trabaction processing engine, I would highly recommend you use a more traditional relational database as opposed to mongo. Aside from handling transactions in a more same manner, if you build a normalized database, it is much more compact and caches nicely.

If the database, either a rdms or mongo, is running too slowly, the simplest was to speed things up is to use solid state drives. Ssds are about 1000 times faster than spinning disks.

For things like prices, you could cache them local to the server. This would make the look up of the faster, and would not put them on the client making it possible for people to change the price when the submit the purchase request.

For optimizations like this it is useful to know the general speed of differt devices.

Long range networks. 100s of ms Disk storage. 10s of ms Local network. 0.5 ms Sdd storage. 0.5 ms Sdram. 10 ns

You can tally how much time it takes for a specific call, then work on optimizing it.

Improve this answer
1
  • Thanks for the advice. I realized that using SQL would allow me to link tables very easily, but I am still fairly new to Node and the tutorial I was following used MongoDB and Mongoose. My other experience with SQL was using Python + Flask to serve up pages and using phpLiteAdmin to handle the querying easily. Are there any convenient frameworks for integrating SQL or other relational DBs with a Node/Express application that you would suggest? I like Mongo because I can iterate through a DB query with PUG/Jade and generate a webpage from that, is this functionality still present in other DBs?
    – Mikhail
    Commented Nov 12, 2017 at 19:02
6

One can never trust input from a client, especially sensitive input like prices.

If you want to cache information to avoid stressing the database server (did you measure that this is actually an issue?), you'll need to cache it somewhere you can trust, on the backend.

But as soon as you start caching, you need to think about when do you invalidate the cache. What if the price changes in the meantime? This would have also been an issue when caching such information on the client even if the client is not malicious: one would change the price, but the client would continue to send the old price for hours/days on end.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.