HOW TO
YOU’LL NEED THIS A LINUX PC This needs to run OpenVPN.
Program and set up a tiny web server; build a Pi-powered random video player; fix OneDrive sync problems; create an animated GIF.
A WEB SERVER is a hefty collection of software running in a rack server, which—unsurprisingly— few of us have at home. So, when you want to make a new webpage, you have to use an online service, such as Codepen or Jsfiddle, to test your CSS code.
However, these services are usually limited to handling small code snippets, and more advanced code becomes cumbersome to develop using such tools. With greater complexity come other risks, as well, such as compatibility. If you hope to be a professional coder, you’ll need to know how to use a few tools to ensure that you’re building on the correct platform for which you will eventually be deploying. In this article, you’ll be able to learn a few techniques to accomplish this.
1 THE BASICS
In its early days, most JavaScript was embedded in the HTML code. This was handy, because there were only a few lines of it on each page. However, now that many users have created frameworks from their initial code, separate program files have become necessary. When you start programming in JavaScript, it makes sense to start with separate JavaScript files, and make a clear structure for all your content [ Image A], including HTML, CSS, and images. This ensures that you know how to include the frameworks that are essential for going beyond the well-known “Hello World” level of programming.
>> To get started, make the typical “Hello World,” and put it in a JavaScript file called “app.js.”
>> At the top of the listing, the code starts a web server and sets the minimal parameters to run it locally. This is the fastest way to get anything running as a local server. Further down, you can see code that runs a “Hello World” script. To start this JavaScript, just run
node app.js . This is fine if you just want to see how a certain piece of code works. However, when you’re involved with bigger projects, there are other solutions that are easier to handle, although they require a module. These modules start a server so that all files in your tree are read as they will be in the live server. If you want help with JavaScript, the Mozilla Foundation has a fantastic set of tutorials on its documentation webpage [ Image B].
2 SMALL AND PERFECTLY FORMED
Why so many modules in the first place? The answer is that you want the module to be small, yet still support all the functions you may need. You can find an example in the “react-native-httpd” module. Not everyone wants to use React, but you need to have support for the correct frameworks, otherwise the code simply won’t work. On the other hand, if you have elements you don’t use, the results may differ when you deploy. The main reason is that we follow the classic Unix programming rule of thumb: Make each software tool do one thing and do it well.
>> One of the most common frameworks for JavaScript code is Node.js. To install these packages, you’d usually use the packaged version. This can be a mistake, though, because the newest version isn’t usually available there. You may also need to have several versions because of the site’s software levels. You’re better off going to https:// nodejs.org/en/download/package-manager/#debianand-ubuntu-based-linux-distributions, and finding the package there.
>> The setup script changes your system’s list of repositories, so you can keep using the newest version. You can register on www.npmjs.com, but this is only useful when you start sharing code.
>> In the npm registry, you’ll find several packages for running a small, local web server. Some are for static content only, while others are only for serving
files. The package called “httpd-server” can handle what most regular servers can, and better still, it’s relatively small and customizable.
>> Start your server with the command http-server . Without parameters, the server starts with the current directory as the main one. This makes it easy to change into your source repository, and run whatever you’ve created.
>> You can also start the command with parameters pointing to the correct directory. Your source code needs to be organized so you can easily deploy with the same set of files on a live server. In the case of the “http-server,” you now have this solution ready. Remember that any files below the directory you start from are invisible to the server.
3 CONFIGURE HTTP-SERVER
To make everything work as closely as possible to the real thing, you can trim some parameters. The port defaults to 8080, but you can pick your own port in case you have other local servers. Parameter -g picks a gzip version of any file that you’ve packed and had the same name before the “gz” extension. You can also change the default HTML extension, which is useful if you’re making a PHP application.
>> When you need to use secure webpages, you can also start the use of SSL and point to a certificate and key file. Without the two files, the site won’t start, as encryption can’t occur— something that people who work with secure sites will already know. To make sure your code always updates in the browser, you can also turn off caching by setting the cache time to -1.
>> What can’t you do? Well, because the server needs to be small, you won’t have full support for any framework beyond Node.js. The package can also use a proxy function. This sends some requests over to a webpage, even though your code and data is local. With this in place, you can test how to collect information from other sites, such as embedding remote content. You can rectify this by adding it afterward, but before you do that, look through the other options that are available:
>> When using this tiny server, you must compress all files before the server needs them, if you want to use compression. In a more advanced web server, for example nginx, you can choose to compress on demand. Either way, it’s useful to be able to measure speed gains of compressing your files.
>> Of course, this solution is one of many. In this section, you’ll learn about the possibilities and limitations of this particular one. Other options are web servers built with more flexibility and/or more features. The “local-websever” package packs a wider array of features and customizability into it. To install it, use the npm manager:
>> Once that’s done, the simplest case is to host a static site with no arguments. This is the same as the former package. The command is ws . The default port is 8000, which you can choose yourself. If you want to serve a Single Page Application, you use the argument
--spa . You can also use proxies in this package. >> To serve https and http2, start with the arguments
--https or --http2 , respectively. There are built-in keys and certificates, so you can run without your own keys, although you can also supply your own. In case you’re interacting with another site, be it on the web or another part of your own, you can set up mock answers. These mock answers can send a reply to a request from an existing site using a preset answer. This way, you can test when you have no contact to the specific site, even when you are offline. To define mock answers, use a JavaScript file like the one below.
>> Save the code above, call it “mock-example.js,” then run the web server.
>> After this, you can get the response with curl .
>> Now you can request your data from the local system to check that your code can handle the response.
>> As your projects grow, your testing requirements also grow. To help verify functionality in many scenarios, you can use the “dev-web-server,” which has more functions. It also supports defining API endpoints—and with these functions, you can call APIs. You also have the chance to define both success and failure of the endpoints. With all this functionality, the full design and the testing can be done locally, making the whole flow safer and less prone to delays that lie beyond your control.
>> The “dev-web-server” package also has a feature for failure scenarios. To set everything up, consider the below command to start the server:
>> As you can see, the delay is set to 2000. Using this argument, you can test how things will work when your user has a big lag to the webpage. All parameters can also be defined by the “devweb-server.json” file in the launching directory. Any arguments on the command line override the file. The example file defines paths and delay. It also defines whether you use CORS or not. CORS is a way to enable programs to fetch data from other domains that they co-operate with. This is regularly blocked because of security concerns.
>> The other parameters set the base directory where you put your webpage files, and finally the endpoint file. In the endpoint file, you define how responses are handled. These responses include successes as well as failures. The format is a JavaScript file where functions are defined. The example points to the “api.js” file, and part of that file is shown below.
>> In reality, you’ll cover many more error codes, and these are two of the main ones. In addition, note that the “dev-web-server” package has two dependencies: colors and object-tools. This is not usually a problem, but worth mentioning anyway.
4 LIVE RELOAD FACILITY
If you use the “webpack” module, you’ll be interested in “webpack-dev-server” [ Image C]. As the name suggests, the package is designed for development only. One of the most interesting features is the live reload feature, which makes all your new changes load immediately. Often, when you find a problem in your code, changing the code is done quickly, but then you have to make sure that the code is actually used by the server. The browser and server cache go some way toward saving bandwidth for users, but when you’re coding, this isn’t always obvious, while what level your browser is using isn’t always clear.
>> For the uninitiated, the “webpack” module is designed to take your project and its dependencies, and pack them into a single module. This means that anyone interested in your module can download the pack and use it as is, without worrying about dependencies. In the case of “webpack-dev-server,” the pack remains in the memory and is served to the client.
>> For npm projects to work at all, you must initialize your directory. This creates the “node_modules” directory that contains all the modules you’ll use.
>> Without the init , packages won’t be installed correctly to the directory; you can install globally, but you have greater control if you make an install local.
>> The package manager will handle dependencies for you, but you need to tell it what you’re after. You need to make sure the “webpack” module is available on your system. In case it isn’t, install it with:
>> The save-dev argument means that the package will only be used for development. This is important, because you may need some packages for developing, while some are critical on the deployed server. You’ll get some warnings, but you can safely ignore the “fsevents” dependency warning as it’s not supported on Linux.
>> Next, you need to adapt the configuration file for your own needs. In the file, your main concern is the
entry point. This is the JavaScript file where “webpack” starts to look through your application. In the case of a simple application, you may only have one JavaScript file, but when it grows in size, your best bet is to have many. A great example is available on GitHub ( https://github.com/mschwarzmueller/yt-webpack2
basics). This example is focused on “webpack,” but includes some details about the web development server. Initially, you need to create your “package.json” file in which you define how the package is run: >> In the directory of the “package.json file,” run npm . The
run-server argument is taken from the “package.json” setting. In this case, you can use build:prod to make a bundle file:
>> You should now be able to see the site in your web browser. The port will show up in your terminal window.
>> For more advanced use of “webpack” use the “webpack. config.js” file. Creating it may be a little awkward in the beginning. You can always try the tool at https://webpack.jakoblind.no, which creates the configuration files for you. The result will be a good starting point.
5 PARALLEL EXECUTION
At first, your webpages will be trivial, but it’s still good to know where to look for the packages that can make your system run in parallel. There are several solutions to this; some known ones are “forky” and “throng.” Of the two, “forky” is the more advanced, but you need to activate both in a JavaScript function. “Forky” has one master file and several process files, while “throng” has only worker files and processes. Whichever you choose, it’s good practice to consider these issues before you think you’ll need them.
>> For the more professionally minded, you should learn how to build a containerized environment, so the correct system can be available to you, irrespective of where you’ll finally deploy your code. To make absolutely sure, you need to build an image of the site you’re deploying to. At first, this will seem as though you end up with the sort of gigantic server that this whole exercise was designed to avoid, but it’s not quite like that.
>> If you use a containment system such as Docker ( www.docker.com), you can have the whole thing running without touching your system, and the “web server” you’ll have created will act just like the real one. A good starting point for web servers is to use a minimal image—the smaller ones are just a few hundred kilobytes. Even the Ubuntu one with nginx on top is quite small, but managing packages is another issue when using Docker. That is a story for another time…
6 MOVING ON…
In this tutorial, you’ve learned the basic methods for starting a web server on your local machine for testing. A tiny specialized server won’t overload your local hardware—a simple laptop is enough. Npm has a number of great solutions for this type of work. For bigger jobs, you’ll most likely need to use container technology like a Docker image to do the same. For your early learning and experimenting sessions, though, npm will suit you down to the ground.