Habeeb Bombata

Node.js explained for mannequins

2019-01-02T20:38:20+00:00

Introduction

Node.js or node is an open source and cross-platform runtime environment for executing javascript code outside of a browser.

Quite often, we use node to build back-end services also called API (Application Programming Interface), these are the services that power client applications like the web app running inside of a web browser, or a mobile app running on a mobile device, these client apps are simply what the user sees and interacts with. The apps themselves are just the surface, they need to talk to some sort of service sitting on a server or in the cloud to store data, send emails or push notifications, and much more

Node.JS is ideal for building Highly scalable, data-intensive and real-time back-end services that power client applications.

Well you might be thinking, but there are other back-end services or frameworks such as ASP.NET, Rails, etc, so what’s so special abouT node?

Great for prototyping and agile development
Superfast and highly scalable
Javascript Everywhere (Cleaner and more consistent codebase)
The Largest ecosystem of open-source libraries.

Node Architecture

Before node.js we used javascript to build applications that ran only inside a browser, every browser has a javascript engine that takes our javascript code and converts it to machine code (code computer can understand ). Microsoft uses chakra, firefox uses spider monkey and chrome uses V8, because of this variety of engines js can behave differently in different browsers.

A browser provides a runtime environment for javascript code, up to 2009 the only way to execute js was in a browser in 2009 Ryan dahl the creator of Node.js came up with a brilliant idea he thought it would be great to execute js out of a browser so he took chrome’s v8 engine and embedded it inside a c++ program and called that program Node.exe so similar to a browser node is a runtime environment for js code ….

I know what you’re thinking why did Ryan create a runtime environment out of the browser, couldn’t he use the browser offline? … why must this be complicated ? Now, we will look a bit more into that.

Node has certain objects that provide an environment for our js code, these objects are different from the environmental objects we have in browsers, for example in browsers we have the window or the document object document.getElementById('') which allows us to work with the environment which our code is running (the browser). but with Node js, we don’t have the document or window object. one very important thing to note was that initially when js was created it was created to run in browsers so it had no access to things like the file system ( for security purposes ) so now with node it gives us more interesting capabilities we can work with the file system fs.readFile() listen for requests http.createServer() and so much more which we can’t do inside of a browser so we can see that both chrome and node use the V8 engine but they provide different runtime environments for Javascript.

Node is not a programming language!

Node is not a framework!

How does Node work

I had mentioned earlier that Node applications are highly scalable, well that is because of the non-blocking/Asynchronous nature of node

What is Asynchronous/ non-blocking?

Let me try to explain with a metaphor, imagine you go to a restaurant and, the waiter comes to customer A’s table takes the order for customer A and goes to the kitchen, drops the order for the chef to prepare the meal so while the chef is preparing the meal he comes back to take customer B’s order drops the order in the kitchen and that way the same waiter can be used to serve many different tables so they don’t have to wait for the chef to finish Customer A’s food before they are served … This is what we call Asynchronous or non-blocking architecture.

Synchronous / Blocking Architecture

Back to our restaurant example, imagine you go to a restaurant and in this restaurant the waiter takes your order goes to the kitchen and waits there for the chef to prepare your meal and while the chef is preparing your meal, the waiter is not doing anything then when the meal is ready the waiter serves you and proceed to the next table. This is what we call blocking or Synchronous architecture and that is how applications like ASP.net or Rails work out of the box.

So when we receive a request a thread is assigned to handle that request, it is likely we will query a database and sometimes it might take a little while until the result is ready, so while the result is processing that thread is sitting idle doing nothing so we need a new thread to process requests for another client, so what would happen if we had a large number of concurrent clients, at some point we will run out of threads to serve the clients, so new clients have to wait and if we don’t want them to wait we need to add more hardware. With this kind of architecture we are not utilizing resources efficiently and that is the problem with synchronous architecture and that’s how back-end frameworks like rails or asp.net work by default. off-course its possible to make asp.net asynchronous but that would require extra work node.js comes asynchronous out of the box.

So in Node we have a single thread handling multiple requests, if it is querying a DB it doesn’t have to wait for the DB to return results. when the DB returns the results it puts it in something called an event queue, node is continuously monitoring this queue in the background, when there’s an event it will take it out and process it, this makes node ideal for I/O-intensive apps, Node should not be used for CPU intensive apps like video encoding or image manipulation in these apps we have a lot of calculation to be done by the CPU and few that touch the file system.

In conclusion

Javascript itself is a single-threaded, non-blocking, asynchronous, concurrent language, it has a callback, an event loop, a callback queue, and some other API’s and stuff

node is a runtime environment for js, javascript itself has some inbuilt functions for codes to be non-blocking (the definition for blocking is relative but we all agree that blocking is slow code ) and a common example is the set timeout.

Also node.js also has some applications on the front-end if you’re curious. You can let me know if you would like an advanced article expatiating more on node.js or applications of Node in the front-end, or writing a simple back-end node server, you can reach me here …Remember this blog is for all things Javascript.

Convenient JavaScript Coding with VS Code Extensions

2018-06-05T16:57:51+00:00

The Battle of choosing the right Code editor is tough, From Atom to Sublime text to Notepad ++ (Pun Intended) , However we wont be Discssing Notepadd++ or sublime text Plugins we will be looking at VS code.

Visual studio code provides an amazing environment for development; especially for JavaScript developers. The cross-platform text editor since introduced by Microsoft and has attracted a large number of developers because of its better performance & long listed amazing features. As a developer, having a well calibrated editor is paramount to productivity, Great tooling can help developers write faster, cleaner, and more consistent code. VS Code already does a lot right from install but with time you might want to add a few extensions, well Fourtunatley VS Code vibrant extension community this very easy with well over 7,00,000 downloads per month.

We will look at must have plugins, Nice to have and a few Honourable mentions.

The Must Have

This List was Very Hard to compile, Choosing between so many Great Extensions, some were given preferences according to my personal needs also taken into consideration and there still tons of extensions left i might just write a part two.

Git Lense

The Git Lens extension is truly amazing, it enables you to visualize code authorship within VS Code. You can browse and explore the history of a file, view a git blame annotation for each file line, and even add a changes (diff) hover annotation, all of which are fully customisable. GitLens is especially useful on larger projects where you may not be aware who wrote what within a given file.with GitLens you can easily see with a glance who wrote a specific line right from the bottom status bar. and when specific questions arise they can be contacted.

NPM Intellisense

The npm InteliSense extension is a small utility to enable autocompletion of module names in require statements using the VS Code IntelliSense feature. The extension is dead simple, but provides a nice quality of life improvement when in development.

ESLint

ESLint is a very commonly used and highly customizable JavaScript linter that can be configured for most major frameworks and code styles. Instead of having to manually run ESLint to see what errors out, this specific VS Code implementation of ESLint highlights the linting errors within the editor, as well as offers to automatically resolve them with a few mouse clicks.

Although comes with IntelliSense built in which does a perfectly descent job of code hinting.” That’s true, but what if not everyone on your project is using the same editor? What if you want to have different config settings just for JSX, or specific ECMAScript version for vanilla JS running in the browser, or Node.js server code? Well, ESLint has got you covered for all those scenarios.

This extension integrates ESLint into VS Code, it requires you to already have ESLint installed on your computer: either locally or globally. You can do this with npm, by running npm install -g eslint. There are more detailed configuration and installation settings and instructions on the extension marketplace page.

todo Highlight

It often happens that you code a function, and think that there is a probably better way to do the same thing. You leave a comment // TODO: Needs Refactoring or something to that effect. But then you forget about the note and push your code to master/production. With Todo Highlighter, that won’t happen. Hopefully.

It highlights your TODOs/FIXMEs or any other annotation in your code in bright colours so it is always clearly visible. One nifty feature is List Highlighted annotations. It lists all the TODOs in the output console.

The Nice to Have

Open in Browser

VSCode Great Icons

Trailing white spaces

Code Runner

Material Palenight

Some Honorable mentions

Conclusion

VS Code has a huge library of extensions to choose from,and I’ve barely grazed the surface. If you have an extension you think i missed please feel free to reach out to me.

This blogpost was Originally written for Codeship authored by me you can find it here

Effectively debugging Node.js

2018-04-30T16:57:51+00:00

Debugging is the task to identify and remove errors from software applications, and is more than just printing out values in your code. This post describes how to efficiently debug Node.js programs using the latest Google Chrome DevTools. A lot of developers use console.log in order to debug their application. but why? The answer is easy: It’s inconvenient to use the debugger if you haven’t set up your environment correctly.

Why console.log is not the best option?

Using console.log to debug your code generally dives you into an infinite loop of “stopping your app, adding a console.log, and start your app again” operations. Besides slowing down the development of your app, it also makes your writing dirty and creates unnecessary code. Finally, trying to log out variables alongside with the noise of other potential logging operations, may make debugging difficult when attempting to find the values you are debugging.

Debugging tools

Debugging tools provide you with a few important functionalities that console.log isn’t able to provide. In particular they let you pause the execution of your application at specific points in the code, and inspect and modify the values of the variables while the program is still running.

Built-in debugger

Node.js ships with a built-in debugging facility. If you start your application on the command line with node debug index.js where index.js is the starting point of your application then it is started in debug mode. This command has two effects: You start an interactive debugging shell and you open a TCP connection on port 5858 where you can connect a remote debugger with your application. The CLI debugger is the most uncomfortable solution directly after debugging with console.log. But you have a set of commands that make it possible to navigate within your application at run time.

$ node debug index.js

More Advanced Debugging

Chrome and Node.js share with V8 the same JavaScript engine, so it should be possible to use the same tools for debugging and profiling your applications. For older versions of Node.js there was a tool named node-inspector which connected the V8 engine of node with the Chrome Developer Tools. Unfortunately it doesn’t work for current Node.js versions. But this is not a problem anymore, because in May 2016 the –inspect flag landed in Node.js and with it a much better debugging support. In contrast to node-inspector you don’t have to install any additional module in order to get the –inspect flag working. You just have to start your application with this flag.

$ node--inspect index.js

As soon as you start your application, Node.js provides you with a URL which you have to copy to the address field of your Chrome browser. Your browser then connects to your Node.js instance and lets you debug and profile your application. This includes setting breakpoints and watch expressions or capturing memory snapshots of your application.

IDE Debugging (VS Code)

Most of the current IDEs support debugging of Node.js applications such as WebStorm, Eclipse or Visual Studio Code. It’s surprisingly easy to get your debugging environment started in Visual Studio Code, which is by the way just another Node.js application. You just have to hit the debug button on the left side of the window and select the environment you want to debug (Node.js). Visual Studio Code then creates the launch configuration for you and saves it to the .vscode/launch.json file in the root folder of your application. Depending on the starting point of your application you have to make an adjustment here. VSCode expects your application to start at app.js. If you name the starting point differently, just go to launch.json and change the value of the program key. After this is done, you can launch your debugger and have a look at your application.

For this example a simple web server was created. In order to debug this application, you have to set a breakpoint (by clicking on the left of the line number), launch the debugger and go to the server URL in your local browser. The application then automatically stops at your breakpoint and you can start stepping through your code.

As you see, there’s no more need for console.log statements to debug your application code. Just start the debugger of your choice and have a comfortable interface to have a look at your code at run time.

This blogpost was Originally written for Codeship authored by me you can find it here on codeship’s blog