YOU’LL NEED THIS A LINUX PC This needs to run OpenVPN.


Pro­gram and set up a tiny web server; build a Pi-pow­ered ran­dom video player; fix OneDrive sync prob­lems; cre­ate an an­i­mated GIF.

A WEB SERVER is a hefty col­lec­tion of soft­ware run­ning in a rack server, which—un­sur­pris­ingly— few of us have at home. So, when you want to make a new web­page, you have to use an on­line ser­vice, such as Code­pen or Js­fid­dle, to test your CSS code.

How­ever, these ser­vices are usu­ally lim­ited to han­dling small code snip­pets, and more ad­vanced code be­comes cum­ber­some to de­velop us­ing such tools. With greater com­plex­ity come other risks, as well, such as com­pat­i­bil­ity. If you hope to be a pro­fes­sional coder, you’ll need to know how to use a few tools to en­sure that you’re build­ing on the cor­rect plat­form for which you will even­tu­ally be de­ploy­ing. In this ar­ti­cle, you’ll be able to learn a few tech­niques to ac­com­plish this.


In its early days, most JavaScript was em­bed­ded in the HTML code. This was handy, be­cause there were only a few lines of it on each page. How­ever, now that many users have cre­ated frame­works from their ini­tial code, sep­a­rate pro­gram files have be­come nec­es­sary. When you start pro­gram­ming in JavaScript, it makes sense to start with sep­a­rate JavaScript files, and make a clear struc­ture for all your con­tent [ Im­age A], in­clud­ing HTML, CSS, and im­ages. This en­sures that you know how to in­clude the frame­works that are es­sen­tial for go­ing be­yond the well-known “Hello World” level of pro­gram­ming.

>> To get started, make the typ­i­cal “Hello World,” and put it in a JavaScript file called “app.js.”

>> At the top of the list­ing, the code starts a web server and sets the min­i­mal pa­ram­e­ters to run it lo­cally. This is the fastest way to get any­thing run­ning as a lo­cal server. Fur­ther 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 cer­tain piece of code works. How­ever, when you’re in­volved with big­ger projects, there are other so­lu­tions that are eas­ier to han­dle, although they re­quire a mod­ule. These mod­ules 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 Foun­da­tion has a fan­tas­tic set of tu­to­ri­als on its doc­u­men­ta­tion web­page [ Im­age B].


Why so many mod­ules in the first place? The an­swer is that you want the mod­ule to be small, yet still sup­port all the func­tions you may need. You can find an ex­am­ple in the “re­act-na­tive-httpd” mod­ule. Not ev­ery­one wants to use Re­act, but you need to have sup­port for the cor­rect frame­works, oth­er­wise the code sim­ply won’t work. On the other hand, if you have el­e­ments you don’t use, the re­sults may dif­fer when you de­ploy. The main rea­son is that we fol­low the clas­sic Unix pro­gram­ming rule of thumb: Make each soft­ware tool do one thing and do it well.

>> One of the most com­mon frame­works for JavaScript code is Node.js. To in­stall these pack­ages, you’d usu­ally use the pack­aged ver­sion. This can be a mis­take, though, be­cause the new­est ver­sion isn’t usu­ally avail­able there. You may also need to have sev­eral ver­sions be­cause of the site’s soft­ware lev­els. You’re bet­ter off go­ing to https://­load/pack­age-man­ager/#de­bianand-ubuntu-based-linux-dis­tri­bu­tions, and find­ing the pack­age there.

>> The setup script changes your sys­tem’s list of repos­i­to­ries, so you can keep us­ing the new­est ver­sion. You can reg­is­ter on, but this is only use­ful when you start shar­ing code.

>> In the npm reg­istry, you’ll find sev­eral pack­ages for run­ning a small, lo­cal web server. Some are for static con­tent only, while oth­ers are only for serv­ing

files. The pack­age called “httpd-server” can han­dle what most reg­u­lar servers can, and bet­ter still, it’s rel­a­tively small and cus­tomiz­able.

>> Start your server with the com­mand http-server . With­out pa­ram­e­ters, the server starts with the cur­rent direc­tory as the main one. This makes it easy to change into your source repos­i­tory, and run what­ever you’ve cre­ated.

>> You can also start the com­mand with pa­ram­e­ters point­ing to the cor­rect direc­tory. Your source code needs to be or­ga­nized so you can eas­ily de­ploy with the same set of files on a live server. In the case of the “http-server,” you now have this so­lu­tion ready. Re­mem­ber that any files be­low the direc­tory you start from are in­vis­i­ble to the server.


To make ev­ery­thing work as closely as pos­si­ble to the real thing, you can trim some pa­ram­e­ters. The port de­faults to 8080, but you can pick your own port in case you have other lo­cal servers. Pa­ram­e­ter -g picks a gzip ver­sion of any file that you’ve packed and had the same name be­fore the “gz” ex­ten­sion. You can also change the de­fault HTML ex­ten­sion, which is use­ful if you’re mak­ing a PHP ap­pli­ca­tion.

>> When you need to use se­cure web­pages, you can also start the use of SSL and point to a cer­tifi­cate and key file. With­out the two files, the site won’t start, as en­cryp­tion can’t oc­cur— some­thing that peo­ple who work with se­cure sites will al­ready know. To make sure your code al­ways up­dates in the browser, you can also turn off caching by set­ting the cache time to -1.

>> What can’t you do? Well, be­cause the server needs to be small, you won’t have full sup­port for any frame­work be­yond Node.js. The pack­age can also use a proxy func­tion. This sends some re­quests over to a web­page, even though your code and data is lo­cal. With this in place, you can test how to col­lect in­for­ma­tion from other sites, such as em­bed­ding re­mote con­tent. You can rec­tify this by adding it af­ter­ward, but be­fore you do that, look through the other op­tions that are avail­able:

>> When us­ing this tiny server, you must com­press all files be­fore the server needs them, if you want to use com­pres­sion. In a more ad­vanced web server, for ex­am­ple ng­inx, you can choose to com­press on de­mand. Ei­ther way, it’s use­ful to be able to mea­sure speed gains of com­press­ing your files.

>> Of course, this so­lu­tion is one of many. In this sec­tion, you’ll learn about the pos­si­bil­i­ties and lim­i­ta­tions of this par­tic­u­lar one. Other op­tions are web servers built with more flex­i­bil­ity and/or more fea­tures. The “lo­cal-web­sever” pack­age packs a wider ar­ray of fea­tures and cus­tomiz­abil­ity into it. To in­stall it, use the npm man­ager:

>> Once that’s done, the sim­plest case is to host a static site with no ar­gu­ments. This is the same as the for­mer pack­age. The com­mand is ws . The de­fault port is 8000, which you can choose your­self. If you want to serve a Sin­gle Page Ap­pli­ca­tion, you use the ar­gu­ment

--spa . You can also use prox­ies in this pack­age. >> To serve https and http2, start with the ar­gu­ments

--https or --http2 , re­spec­tively. There are built-in keys and cer­tifi­cates, so you can run with­out your own keys, although you can also sup­ply your own. In case you’re in­ter­act­ing with an­other site, be it on the web or an­other part of your own, you can set up mock an­swers. These mock an­swers can send a re­ply to a re­quest from an ex­ist­ing site us­ing a pre­set an­swer. This way, you can test when you have no con­tact to the spe­cific site, even when you are off­line. To de­fine mock an­swers, use a JavaScript file like the one be­low.

>> Save the code above, call it “mock-ex­am­ple.js,” then run the web server.

>> Af­ter this, you can get the re­sponse with curl .

>> Now you can re­quest your data from the lo­cal sys­tem to check that your code can han­dle the re­sponse.

>> As your projects grow, your test­ing re­quire­ments also grow. To help ver­ify func­tion­al­ity in many sce­nar­ios, you can use the “dev-web-server,” which has more func­tions. It also sup­ports defin­ing API end­points—and with these func­tions, you can call APIs. You also have the chance to de­fine both suc­cess and fail­ure of the end­points. With all this func­tion­al­ity, the full de­sign and the test­ing can be done lo­cally, mak­ing the whole flow safer and less prone to de­lays that lie be­yond your con­trol.

>> The “dev-web-server” pack­age also has a fea­ture for fail­ure sce­nar­ios. To set ev­ery­thing up, con­sider the be­low com­mand to start the server:

>> As you can see, the de­lay is set to 2000. Us­ing this ar­gu­ment, you can test how things will work when your user has a big lag to the web­page. All pa­ram­e­ters can also be de­fined by the “de­vweb-server.json” file in the launch­ing direc­tory. Any ar­gu­ments on the com­mand line over­ride the file. The ex­am­ple file de­fines paths and de­lay. It also de­fines whether you use CORS or not. CORS is a way to en­able pro­grams to fetch data from other do­mains that they co-op­er­ate with. This is reg­u­larly blocked be­cause of se­cu­rity con­cerns.

>> The other pa­ram­e­ters set the base direc­tory where you put your web­page files, and fi­nally the end­point file. In the end­point file, you de­fine how re­sponses are han­dled. These re­sponses in­clude suc­cesses as well as fail­ures. The for­mat is a JavaScript file where func­tions are de­fined. The ex­am­ple points to the “api.js” file, and part of that file is shown be­low.

>> In re­al­ity, you’ll cover many more er­ror codes, and these are two of the main ones. In ad­di­tion, note that the “dev-web-server” pack­age has two de­pen­den­cies: col­ors and ob­ject-tools. This is not usu­ally a prob­lem, but worth men­tion­ing any­way.


If you use the “web­pack” mod­ule, you’ll be in­ter­ested in “web­pack-dev-server” [ Im­age C]. As the name sug­gests, the pack­age is de­signed for de­vel­op­ment only. One of the most in­ter­est­ing fea­tures is the live reload fea­ture, which makes all your new changes load im­me­di­ately. Of­ten, when you find a prob­lem in your code, chang­ing the code is done quickly, but then you have to make sure that the code is ac­tu­ally used by the server. The browser and server cache go some way to­ward saving band­width for users, but when you’re cod­ing, this isn’t al­ways ob­vi­ous, while what level your browser is us­ing isn’t al­ways clear.

>> For the unini­ti­ated, the “web­pack” mod­ule is de­signed to take your project and its de­pen­den­cies, and pack them into a sin­gle mod­ule. This means that any­one in­ter­ested in your mod­ule can down­load the pack and use it as is, with­out wor­ry­ing about de­pen­den­cies. In the case of “web­pack-dev-server,” the pack re­mains in the mem­ory and is served to the client.

>> For npm projects to work at all, you must ini­tial­ize your direc­tory. This cre­ates the “node_­mod­ules” direc­tory that con­tains all the mod­ules you’ll use.

>> With­out the init , pack­ages won’t be in­stalled cor­rectly to the direc­tory; you can in­stall glob­ally, but you have greater con­trol if you make an in­stall lo­cal.

>> The pack­age man­ager will han­dle de­pen­den­cies for you, but you need to tell it what you’re af­ter. You need to make sure the “web­pack” mod­ule is avail­able on your sys­tem. In case it isn’t, in­stall it with:

>> The save-dev ar­gu­ment means that the pack­age will only be used for de­vel­op­ment. This is im­por­tant, be­cause you may need some pack­ages for de­vel­op­ing, while some are crit­i­cal on the de­ployed server. You’ll get some warn­ings, but you can safely ig­nore the “fsev­ents” de­pen­dency warn­ing as it’s not sup­ported on Linux.

>> Next, you need to adapt the con­fig­u­ra­tion file for your own needs. In the file, your main con­cern is the

en­try point. This is the JavaScript file where “web­pack” starts to look through your ap­pli­ca­tion. In the case of a sim­ple ap­pli­ca­tion, you may only have one JavaScript file, but when it grows in size, your best bet is to have many. A great ex­am­ple is avail­able on GitHub (­mueller/yt-web­pack2

ba­sics). This ex­am­ple is fo­cused on “web­pack,” but in­cludes some de­tails about the web de­vel­op­ment server. Ini­tially, you need to cre­ate your “pack­age.json” file in which you de­fine how the pack­age is run: >> In the direc­tory of the “pack­age.json file,” run npm . The

run-server ar­gu­ment is taken from the “pack­age.json” set­ting. In this case, you can use build:prod to make a bun­dle file:

>> You should now be able to see the site in your web browser. The port will show up in your ter­mi­nal win­dow.

>> For more ad­vanced use of “web­pack” use the “web­pack. con­fig.js” file. Cre­at­ing it may be a lit­tle awk­ward in the be­gin­ning. You can al­ways try the tool at https://web­, which cre­ates the con­fig­u­ra­tion files for you. The re­sult will be a good start­ing point.


At first, your web­pages will be triv­ial, but it’s still good to know where to look for the pack­ages that can make your sys­tem run in par­al­lel. There are sev­eral so­lu­tions to this; some known ones are “forky” and “throng.” Of the two, “forky” is the more ad­vanced, but you need to ac­ti­vate both in a JavaScript func­tion. “Forky” has one mas­ter file and sev­eral process files, while “throng” has only worker files and pro­cesses. Whichever you choose, it’s good prac­tice to con­sider these is­sues be­fore you think you’ll need them.

>> For the more pro­fes­sion­ally minded, you should learn how to build a con­tainer­ized en­vi­ron­ment, so the cor­rect sys­tem can be avail­able to you, ir­re­spec­tive of where you’ll fi­nally de­ploy your code. To make ab­so­lutely sure, you need to build an im­age of the site you’re de­ploy­ing to. At first, this will seem as though you end up with the sort of gi­gan­tic server that this whole ex­er­cise was de­signed to avoid, but it’s not quite like that.

>> If you use a con­tain­ment sys­tem such as Docker (, you can have the whole thing run­ning with­out touch­ing your sys­tem, and the “web server” you’ll have cre­ated will act just like the real one. A good start­ing point for web servers is to use a min­i­mal im­age—the smaller ones are just a few hun­dred kilo­bytes. Even the Ubuntu one with ng­inx on top is quite small, but man­ag­ing pack­ages is an­other is­sue when us­ing Docker. That is a story for an­other time…


In this tu­to­rial, you’ve learned the ba­sic meth­ods for start­ing a web server on your lo­cal ma­chine for test­ing. A tiny spe­cial­ized server won’t over­load your lo­cal hard­ware—a sim­ple lap­top is enough. Npm has a num­ber of great so­lu­tions for this type of work. For big­ger jobs, you’ll most likely need to use con­tainer tech­nol­ogy like a Docker im­age to do the same. For your early learn­ing and ex­per­i­ment­ing ses­sions, though, npm will suit you down to the ground.



Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.