CODEWITHSUNDEEP
mysqljsonnode.jsserver
Rikard
Rikard

Reputation: 7805

serve content from file vs database in node

I am making a new version of a old static website that grew up to a 50+ static pages.

So I made a JSON file with the old content so the new website can be more CMS (with templates for common pages) and so backend gets more DRY.

I wonder if I can serve that content to my views from the JSON or if I should have it in a MySQL database?

I am using Node.js, and in Node I can store that JSON file in memory so no file reading is done when user asks for data.

Is there a correct practise for this? are there performance differences between them serving a cached JSON file or via MySQL?

The file in question is about 400Kb. If the filesize is relevant to the choice of one tecnhology over the other?

Upvotes: 13

Views: 3674

Answers (7)

Lukasz Korzeniowski
Lukasz Korzeniowski

Reputation: 411

Normally, database is used for serving dynamic content that changes frequently, records have one-to-many or many-to-many relationships, and you need to query the data based on various criteria.

In the case you described, it looks like you will be OK with JSON file cached in server memory. Just make sure you update the cache whenever content of the file changes, i.e. by restarting the server, triggering cache update via http request or monitoring the file at the file system level.

Aside from that, you should consider caching of static files on the server and on the browser for better performance

  1. Cache and Gzip static files (html,js,css,jpg) in server memory on startup. This can be easily done using npm package like connect-static
  2. Use browser cache of the client by setting proper response headers. One way to do it is adding maxAge header on the Express route definition, i.e:

app.use "/bower", express.static("bower-components", {maxAge: 31536000})

Here is a good article about browser caching

Upvotes: 5

Manivannan
Manivannan

Reputation: 3254

I would recomend to generate static html content at build time(use grunt or ..). If you would like to apply the changes, trigger a build and generate static content and deploy it.

Upvotes: 0

Joost Vunderink
Joost Vunderink

Reputation: 1236

If you are not expecting to add (m)any new pages, I'd go for the simplest solution: read the JSON once into memory, then serve from memory. 400KB is very little memory.

No need to involve a database. Sure, you can do it, but it's overkill here.

Upvotes: 0

Arth
Arth

Reputation: 13110

If you are already storing your views as JSON and using Node, it may be worth considering using a MEAN stack (MongoDB, Express, Angular, Node):

This way you can code the whole thing in JS, including the document store in the MongoDB. I should point out I haven't used MEAN myself.

MySQL can store and serve JSON no problem, but as it doesn't parse it, it's very inflexible unless you split it out into components and indexing within the document is close to impossible.

Whether you 'should' do this depends entirely on your individual project and whether it is/how it is likely to evolve.

As you are implementing a new version (with CMS) of the website it would suggest that it is live and subject to growth or change and perhaps storing JSON in MySQL is storing up problems for the future. If it really is just one file, pulling from the file system and caching it in RAM is probably easier for now.

I have stored JSON in MySQL for our projects before, and in all but a few niche cases ended up splitting up the component data.

Upvotes: 3

Rick James
Rick James

Reputation: 142298

400KB is tiny. All the data will live in RAM, so I/O won't be an issue.

Dynamically building pages -- All the heavy hitters do that, if for no other reason than inserting ads. (I used to work in the bowels of such a company. There were million of pages live all the time; only a few were "static".)

Which CMS -- too many to choose from. Pick a couple that sound easy; then see if you can get comfortable with them. Then pick between them.

Linux/Windows; Apache/Tomcat/nginx; PHP/Perl/Java/VB. Again, your comfort level is an important criteria in this tiny web site; any of them can do the task.

Where might it go wrong? I'm sure you have hit web pages that are miserably slow to render. So, it is obviously possible to go the wrong direction. You are already switching gears; be prepared to switch gears a year or two from now if your decision turns out to be less than perfect.

Do avoid any CMS that is too heavy into EAV (key-value) schemas. They might work ok for 400KB of data, but they are ugly to scale.

Upvotes: 2

Rahul Kamboj
Rahul Kamboj

Reputation: 469

Its a good practice to serve the json directly from the RAM itself if your data size will not grow in future. but if data is going to be increased in future then it will become a worst application case.

Upvotes: 0

hd1
hd1

Reputation: 34657

Why add another layer of indirection? Just serve the views straight from JSON.

Upvotes: 6

Related Questions