Marcos Henrique da Silva wrote a very good and informative post about creating secure REST APIs in Node/Express, which can be found here. In it, he described many best practices for securing the application, including implementing JWT authorization and setting user permission levels (this part, in particular, was fascinating to me, and I will definitely be referring back to it in the future). However, in his simple tutorial, he also made a common choice that many Node developers make: he included a NoSQL database, specifically MongoDB. Now, we have all heard of the MEAN stack and the MERN stack, so we know that using Mongo with Node is a common pattern. But, we are all, too, aware that it is not the only option. Today, I will show you a modified version of his code, replacing MongoDB with PostgreSql, implemented with some common Express middlewares, Bookshelf.js and Knex.js. But first, to motivate the discussion, I will explain the difference between NoSqL and SQL databases, and the cases where a developer might prefer one over the other.
In a recent node/express project, I found myself in a situation where I needed to allow users to upload csv files, parse them asynchronously, and save their contents (but not the files themselves) to the database. While I found many useful examples and tutorials for uploading and storing files, csv and not, I had a considerably tougher time finding any online resources on how to upload and immediately parse a csv file, all within the same route, asynchronously. This seemed strange, since it seemed like a relatively common scenario. As a result, I struggled with the tools I am about to explain for longer than I care to admit, but in the end, I was able to accomplish my task. I hope this guide saves you some of the time and headaches I had!
Before I begin, a brief aside on my CS Basics for Coding Bootcamp Students Series: As you may have noticed, I have ceased making posts about these topics, rather suddenly and abruptly, and have not made one for some time. Rest assured, this is not because I believe there is nothing else bootcamp grads need to know about CS, and it’s not because I believe I am now a CS expert that no longer needs to improve my understanding through teaching. The truth is, I started a new job not too long ago, and among the things that fell by the wayside, was my weekly commitment to writing posts in the series. I may still occasionally blog about new and interesting CS concepts, and I have a vague notion of one day doing a series about either cryptography or blockchain, as I learn more about them, but for all intents and purposes, that series is done. Nonetheless, I feel that the 10 or so posts I did write serve as a reasonably complete intro to CS, and if you found them useful, I encourage you to keep studying and learning. I know I have been!
Ten posts in, we have reached the point where, following the pattern, this post should be called “CS101.0”! However, since this series is not nearly in-depth enough, nor am I nearly knowledgeable enough, to write a CS 101 course, we will call it CS 100.9.1. Don’t think that this means the content herein is, in any way, an order of magnitude less important than what we have covered thus far. In fact, hash tables are extremely foundational data structures, and probably should have been covered earlier in this series. See, I don’t know ANYTHING?! (Also, notice how I opted to go for 100.9.1 instead of 100.91, mirroring the way software versions are released. Can anyone say META?!)
As promised, the follow-up to our discussion of trees: graphs. Of course, we are all familiar with what a graph is. For those that have taken discrete mathematics in some form (not me!), you probably even have a sense of the specific definition of a graph and the different kinds. For those have taken graph theory, skip this blog post, it will bore you (Just kidding, don’t do that). Nonetheless, it is important to hone in on exactly what a graph is as a CS data structure, because graphs are illustrative of many important CS principles, and can be used to solve many different problems.