Express.js 2: The SQL
We’ve been digging deeper into backend programing this week with the addition of mySQL. It’s been interesting with its own challenges. There is a new syntax of finding the right information. It’s a simpler syntax but feels more complex at the same time. It sounds like a normal way to ask for the information. Select this info from that place where all the results look like this. And at first it is simple. But it gets complex fast and doesn’t like to be asked the wrong questions.
There are a number of http status codes that come back with a database query. One of them happens when a user attempts to create a resource that already exists. It will fall within the 400 status codes. Most likely it will return something like the 409 code that indicates there was a conflict with the provided information. The user can adjust their submission and try again. The conflict error will stop and prevent any database changes. But it doesn’t lock it out.
It is often beneficial to plan ahead with a responsive website and include images at different sizes. This allows for faster loading on smaller devices and prevents having to scale down large images to fit smaller view areas. One common way is to save your background image at the different sizes with a small variation at the end of the file name. For example: bg-image-sm.jpg, bg-image-lg.jpg, etc. With a set of images in place, there are a couple effective ways to responsively change them to fit best. One way is through the CSS style sheet. A background image can be changed through the @media style rules. When the window width is 1000+ pixels, use the large image. At 700px, use a medium image. But the image you need to change may not always be a background image. This is where JavaScript can come in. Give you image an ID that JS can access. And have JS read the width of the window when it starts and if it changes. Then at the specific window size, you can write a code to dynamically change the src of the image file from one size to another.
Yarn isn’t just for cats and grandmas. But it’s also something that we haven’t covered in class before. So far we’ve been very NPM heavy. And understandably so. NPM appears to be the most used package manager out there. But Yarn has a good following and can load packages a little differently. One of the big differences is the load speed of Yarn. Packages can load almost 3 times as fast. When you only have one or two packages, that doesn’t really make a big difference. But if you are working on a large project with multiple packages attached. That can make a big difference to you and to others. Security is a concern of NPM as well. The way the packages can be loaded on the fly leaves room for vulnerabilities. But Yarn will only packages locked in the lock file, making is a little more secure. It’s hard to say if one is better than the other. But they are both very useful package managers.
Jumping back to some mySQL questions. Although we have only touched upon the code that goes into making a database, I’ve taken the time to look through some of it to try and understand what I see in the query results. Often when a key is defined, it also defines and length of characters. There are two common way to specify how many characters will fit into each field. When a key is specified with something like CHAR(6), it creates a value that has six characters regardless of what is entered. If the string is less than six, it will fill the remaining spots with extra blank spaces. It will always return six characters. But VARCHAR(50) has a different effect. It allows a string up to 50 characters in length. But will only count the actually length. This allows for a much wider range of information. But I’ve read that the database will account for the space of 50 characters in each entry even if they aren’t used. So the string length will be right length. But the empty space will still exist.
