Jump to content
  • entries
    63
  • comments
    51
  • views
    20,322

Web app development is actually a good way to learn multi-threading concepts

Mira Yurizaki

856 views

As a way to expand my skill set and give me something to do in my spare time on programming, I've taken up learning what is called full stack web development. In it's most high level description, that means dabbling in both the front-end (client app, web page, etc.) and back-end (server, database, etc.) of the development process. To ease going into this, because I didn't want to learn almost a half-dozen languages, I've stuck with Node.js and MongoDB, as both use ECMAscript. Essentially all that means is I have to learn JavaScript. This has been a key point in where I'm going with the title.

 

A full web application is made up of several independent pieces

Pieces like the server, the database, the client, and others. These pieces are independent form each other, yet they still need to talk to each other and perform as a cohesive unit. If one of these breaks or isn't developed well, the whole application can have a bad time.

 

Multi-threading means asynchronicity

Synchronicity in this means that everything runs in order as you might expect while reading the code. Asynchronicity means that some code can execute right away, some code will be skipped, and some code will be put to the side, only to be run later.

 

If there is something you run into a lot of in JavaScript, it's that a lot of things are asynchronous. You have a lot of things on a web page that are waiting for user input. However, the web site can't freeze itself or force the user to do things in a specific order, because this decreases the quality of the user experience. In a server, when you do a database request, you don't want this hanging the entire server because a database request can take a while. You want the server to go right back to serving other people's requests if the current one is going to take a while and can be put off to the side. In JavaScript, these are handled by mechanisms such as callbacks and Promises. For example, here's some client code I've written, requesting to the server to get a list of groups:

var getInfo = function(){
        // Making an HTTP GET request
        $http.get('/groups/getList?index=' + $scope.startIndex)
        .then( function(response){
            if (response.data.status === 30000){
                $scope.groupList =
                    $scope.groupList.concat(response.data.groupList);
                $scope.startIndex += response.data.groupList.length;
            }
            else {
                console.log("There was an error getting groups. Code:" +
                             response.data.status);
            }
        }, function(response){
            console.log("There was an error getting groups. Code:" +
                         response.data.status);
        });
        // Script resumes from here after making the HTTP GET request
        console.log("I made a HTTP GET request!");
    };

The first part has the client make an HTTP GET request to the server to a particular URL for getting a list of groups. Since the server isn't going to respond instantaneously, the client will put this action off to the side and continue executing. What happens then is the client will execute console.log("I made a HTTP GET request!"); immediately afterwards. Essentially, for the moment since the data isn't available, it skips everything from the HTTP request function to the comment about where the script resumes. When the server sends the data back to the client, a signal is generated to let the client know to go back and execute the code that was skipped.

 

This is a key point in multi-threaded programming. Things need to be asynchronous. The application needs to be able to put tasks that are waiting for something else to be cast to the side and signal the application when the result comes in.

 

People may be sharing resources and you need to manage them

An example is on Wikipedia. What if two people are editing a page at the same time, but adding different things to the page? How do you handle them both saving data? This is a common issue with multi-threading programming. One way of handling it the server having a token that only one person can take. If the token was taken, then nobody else can touch the page until the token is released. Another solution is if someone submits their edit, then another does, you can respond "hey, someone made changes already."

 

Web application development gives you more control in the debugging process

This part makes understanding how each bit interact with each other easier.

 

One of the hardest things about developing and debugging multi-threaded applications is that a lot of things happen on the OS and processor level. It can be hard to poke into those to figure out what's going on. Like when you want to pause the execution of the application in the source code, you're not quite sure which thread you're on. When you're doing web application development, each instance you are accessing the web page can be thought of as a process or a thread in the entire application. In this way, you can pause one instance's execution and know exactly which one you're poking at.

 

In another sense, you may be able to control aspects behind the scenes, such as latency and such. It's harder to see how a local application will behave with hiccups and such without clunky methods, but you can certainly add latency to your network or simulate it another way without adding debug code or whatnot.

 

It's practical and relatively easy to setup!

One of the hardest problems with learning something about software development is what to do with it. I'm finding full stack web development practical to learn because it touches upon something we all use in our daily lives. So instead of trying to figure out a local application you can run that can be multithreaded, try developing a website server and a client to go with it. The flip side is it's very visible and you can see your results.

 

Now I say it's relatively easy to setup, but it still has a learning curve. In my case, at the barest minimum you need to learn HTML and JavaScript. CSS is highly recommended. Then again, multi-threaded programming isn't a beginner level concept either. But if you take an afternoon to study, you can certainly get a web server setup: https://www.tutorialspoint.com/nodejs/nodejs_express_framework.htm

 

My development setup at the moment is:

  • VirtualBox with Lubunutu
  • Node.js  with Express as the server framework.
  • MongoDB for the database. This is a document-oriented database, as opposed to a relational database like SQL.
  • Whatever text editor of choice you want (I use Atom).

0 Comments

There are no comments to display.

×