Herron Node.js Web Development

Create real-time server-side applications with this practical, step-by-step guide
3. Auflage 2024
ISBN: 978-1-78588-541-9
Verlag: De Gruyter
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)

E-Book, Englisch, 376 Seiten

Node.js is a server-side JavaScript platform using an event driven, non-blocking I/O model allowing users to build fast and scalable data-intensive applications running in real time. Node.js Web Development shows JavaScript is not just for browser-side applications. It can be used for server-side web application development, real-time applications, microservices, and much more.
This book gives you an excellent starting point, bringing you straight to the heart of developing web applications with Node.js. You will progress from a rudimentary knowledge of JavaScript and server-side development to being able to create and maintain your own Node.js application. With this book you'll learn how to use the HTTP Server and Client objects, data storage with both SQL and MongoDB databases, real-time applications with Socket.IO, mobile-first theming with Bootstrap, microservice deployment with Docker, authenticating against third-party services using OAuth, and much more.

Autoren/Hrsg.

Herron, David

Fachgebiete

• Mathematik | Informatik EDV | Informatik Daten / Datenbanken
• Mathematik | Informatik EDV | Informatik Technische Informatik Server
• Mathematik | Informatik EDV | Informatik Digital Lifestyle Internet, E-Mail, Social Media
• Mathematik | Informatik EDV | Informatik Programmierung | Softwareentwicklung Programmier- und Skriptsprachen

Inhaltsverzeichnis

Table of Contents - About Node.js
- Setting up and Configuring Node
- Working with Modules
- HTTP Servers and Clients - A Web Application's first steps
- Your first Express Application
- Implementing Mobile-First paradigm
- Data Storage and Retrieval
- Multiuser Authorization: the Microservice way
- Dynamic Interaction between Client and Server with Socket.IO
- Deploying Node applications
- Unit Testing

Leseproben

Why should you use Node.js?

Among the many available web application development platforms, why should you chose Node.js? There are many stacks to choose from; What is it about Node.js that makes it rise above the others? We will see in the following sections.

Popularity

Node.js is quickly becoming a popular development platform with adoption from plenty of big and small players. One of those is PayPal, who are replacing their incumbent Java-based system with one written in Node.js. For PayPal's blog post about this, visit https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/. Other large Node.js adopters include Walmart's online e-commerce platform, LinkedIn, and eBay.

Since we shouldn't just follow the crowd, let's look at technical reasons to adopt Node.js.

JavaScript at all levels of the stack

Having the same programming language on the server and client has been a long time dream on the web. This dream dates back to the early days of Java, where Java applets were to be the frontend to server applications written in Java, and JavaScript was originally envisioned as a lightweight scripting language for those applets. Java never fulfilled the hype and we ended up with JavaScript as the principle in-browser client-side language, rather than Java. With Node.js we may finally be able to implement applications with the same programming language on the client and server by having JavaScript at both ends of the web, in the browser and server.

A common language for frontend and backend offers several potential wins:

• The same programming staff can work on both ends of the wire
• Code can be migrated between server and client more easily
• Common data formats (JSON) exist between server and client
• Common software tools exist for server and client
• Common testing or quality reporting tools for server and client
• When writing web applications, view templates can be used on both sides

The JavaScript language is very popular due to its ubiquity in web browsers. It compares favorably against other languages while having many modern advanced language concepts. Thanks to its popularity, there is a deep talent pool of experienced JavaScript programmers out there.

Leveraging Google's investment in V8

To make Chrome a popular and excellent web browser, Google invested in making V8 a super-fast JavaScript engine. The competition to make the best web browser leads Google to keep on improving V8. As a result, Node.js programmers automatically win as each V8 iteration ratchets up performance and capabilities.

The Node.js community may change things to utilize any JavaScript engine, in case another one ends up surpassing V8.

Leaner asynchronous event-driven model

We'll get into this later. The Node.js architecture, a single execution thread and a fast JavaScript engine, has less overhead than thread-based architectures.

Microservice architecture

A new hotness in software development is the microservice idea. Node.js is an excellent platform for implementing microservices. We'll get into this later.

The Node.js is stronger for having survived a major schism and hostile fork

During 2014 and 2015, the Node.js community faced a major split over policy, direction, and control. The project was a hostile fork driven by a group who wanted to incorporate several features and change who's in control of making decisions. What resulted is a merge of the Node.js and io.js repositories, an independent Node.js foundation to run the show, and the community is working together to move forward in a common direction.

Threaded versus event-driven architecture Node.js's blistering performance is said to be because of its asynchronous event-driven architecture, and its use of the V8 JavaScript engine. That's a nice thing to say, but what's the rationale for the statement?

The normal application server model uses blocking I/O to retrieve data, and it uses threads for concurrency. Blocking I/O causes threads to wait, causing a churn between threads as they are forced to wait on I/O while the application server handles requests. Threads add complexity to the application server as well as server overhead.

Node.js has a single execution thread with no waiting on I/O or context switching. Instead, there is an event loop looking for events and dispatching them to handler functions. The paradigm is that any operation that would block or otherwise take time to complete must use the asynchronous model. These functions are to be given an anonymous function to act as a handler callback, or else (with the advent of ES2015 promises), the function would return a Promise. The handler function, or promise, is invoked when the operation is complete. In the meantime, control returns to the event loop, which continues dispatching events.

To help us wrap our heads around this, Ryan Dahl, the creator of Node.js, (in his presentation) asked us what happens while executing a line of code like this:

result = query('SELECT * from db'); // operate on the result

Of course, the program pauses at that point while the database layer sends the query to the database, which determines the result and returns the data. Depending on the query, that pause can be quite long. Well, a few milliseconds, which is an eon in computer time. This pause is bad because while the entire thread is idling, another request might come in and need to be handled. This is where a thread-based server architecture would need to make a thread context switch. The more outstanding connections to the server, the greater the number of thread context switches. Context switching is not free because more threads requires more memory for per-thread state and more time for the CPU to spend on thread management overhead.

Simply using an asynchronous event-driven I/O, Node.js removes most of this overhead while introducing very little of its own.

Using threads to implement concurrency often comes with admonitions like these: , , or . The complexity comes from the access to shared variables and various strategies to avoid deadlock and competition between threads. The are an example of such a strategy, and obviously many programmers find them difficult to use. There's the tendency to create frameworks such as to tame the complexity of threaded concurrency, but some might argue that papering over complexity does not make things simpler.

Node.js asks us to think differently about concurrency. Callbacks fired asynchronously from an event loop are a much simpler concurrency model—simpler to understand, and simpler to implement.

Ryan Dahl points to the relative access time of objects to understand the need for asynchronous I/O. Objects in memory are more quickly accessed (on the order of nanoseconds) than objects on disk or objects retrieved over the network (milliseconds or seconds). The longer access time for external objects is measured in zillions of clock cycles, which can be an eternity when your customer is sitting at their web browser ready to move on if it takes longer than two seconds to load the page.

In Node.js, the query discussed previously will read as follows:

query('SELECT * from db', function (err, result) { if (err) throw err; // handle errors // operate on result });

Or if written with an ES2015 Promise:

query('SELECT * from db') .then(result => { // operate on result }) .catch(err => { // handle errors });

This code performs the same query written earlier. The difference is that the query result is not the result of the function call, but it is provided to a callback function that will be called later. The order of execution is not one line after another, but it is instead determined by the order of callback function execution.

Once the call to the function finishes, control will return almost immediately to the event loop, which goes on to servicing other requests. One of those requests will be the response to the query, which invokes the callback function.

Commonly, web pages bring together data from dozens of sources. Each one has a query and response as discussed earlier. Using asynchronous queries, each one can happen in parallel, where the page construction function can fire off dozens of queries—no waiting, each with their own callback—and then go back to the event loop, invoking the callbacks as each is done. Because it's in parallel, the data can be collected much more quickly than if these queries were done synchronously one at a time. Now, the reader on the web browser is happier because the page loads more quickly.

Performance and utilization

Some of the excitement over Node.js is due to its throughput (the requests per second it can serve). Comparative benchmarks of similar applications, for example, Apache show that Node.js has tremendous performance gains.

One benchmark...

Über Autor(innen)

Herron David :

David Herron is a software engineer living in Silicon Valley who has worked on projects ranging from an X.400 email server to being part of the team that launched the OpenJDK project, to Yahoo's Node.js application-hosting platform, and a solar array performance monitoring service. That took David through several companies until he grew tired of communicating primarily with machines, and developed a longing for human communication. Today, David is an independent writer of books and blog posts covering topics related to technology, programming, electric vehicles, and clean energy technologies.