HTTP GET out of town!
This week brings about the end of 311 and our short break before 411. It’s been an interesting section. And I’ve learned quite a bit about creating express servers and making use of cloud storage systems. Little by littler, we’re getting closer to the end. But that end is only the beginning of the next thing.
HTTP requests that use a RESTful web service will follow the CRUD method. Create, Read, Update, and Delete. The actual HTTP methods are Get, Post, Put, and Delete. The Get method is the Read part of CRUD. It requests the information which the server will return. Post allows the client side to Create a new entry. Put will Update an existing entry. And Delete, believe it or not, will Delete an entry.
A ‘test pyramid’ is a set of test types that should be implemented in a structured order during the development and release of an app or website. From bottom to top, these tests are Unit tests, integration tests, and UI test. The Unit test at the bottom are the fastest and easiest to apply to individual elements and events to make sure they execute as expected. The integration tests are used to test interaction with external elements such as databases or APIs. They don’t get run as frequently as unit tests. And finally UI, or End-to-end tests, are at the top. They test that the whole application is working properly from start to finish. This test pyramid can be very useful in testing APIs. The unit test make sure that you individual HTTP request and functions work as expected. The integration tests make sure that the HTTP requests get back the expect information. And the UI test make sure that the whole thing works as it should.
A demultiplexer is a strange concept to me right now. From what I can tell, it is a function that works like a hub with IO connections. It splits a single channel of IO requests into multiple lines so that none of them need to wait for the previous to finish. They can run asynchronously of each other.
Blocking and Non-blocking functions are opposites of each other. Blocking functions will prevent the execution of the function until all the required data is present. This may mean waiting on a GET request to come back or even a user input. Whatever the data needed, it waits before running. Non-blocking functions don’t have that problem. They will run regardless of the data. If no results are available when it runs, it will return a predefined response indicating that there is no data at the moment.
Node.js has multiple security practices to help prevent application or data breaches. Some of these include multi-factor authentication that help prevent automated attacks. Node.js will discard data after use including sensitive data. There are also a number of security packages that help protect tokens and cookies.
The ‘path’ module is built into the core of Node.js. Therefor there is no need to install it. But it will still need to be required at the start of a JS document. It will provide utilities for working with the file and directory paths. It also has it’s own methods for how to display the results of a file path or how to access other file and directory paths. It can even join path inputs.
This section of class has been a little exciting. I can start to see how a web application is more than what you see. There is a world of back end that makes the front end function. And with the things I’ve learned over the last few weeks of class make it start to come together. It’s not quite there yet, but it’s getting there.
