But you don't manage the servers it runs on or maintain the underlying infrastructure. You simply sign in and get to work. This is called Software as a Service (SaaS), and many people use it for years without knowing the term.

SaaS is just one of three major cloud service models. The other two, Infrastructure as a Service (IaaS) and Platform as a Service (PaaS), give you different levels of control over the infrastructure and software you build. Understanding how these models differ will help you make sense of cloud engineering concepts and choose the right approach for your projects.

In this article, we'll break down IaaS, PaaS, and SaaS, explain what you manage and what the cloud provider handles in each model, and learn how to choose between them for a real project.

What You'll Learn

By the end of this article, you'll be able to:

• Explain what IaaS, PaaS, and SaaS are and what each one manages for you
• Use the shared responsibility model to see where your job starts and ends
• Recognise real products in each category
• Choose the right model for a given project

Table of Contents

• Prerequisites
• What Is Cloud Computing?
• The Shared Responsibility Model
• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Software as a Service (SaaS)
• Beyond the Big Three: CaaS, FaaS, and Serverless
• How to Choose the Right Service Model
• Conclusion

Prerequisites

You don't need any cloud experience to follow this article. If you know what a computer, a server, and the internet are, you have everything you need.

If you're new to the cloud, read my article What is the Cloud and Cloud Computing? first. It explains what the cloud is and how it differs from running your own hardware, and this article builds on that foundation.

What Is Cloud Computing?

Cloud computing is a model that lets you use computing resources, such as servers, storage, and networking, on demand over the internet. YOu pay only for what you use.

These resources sit in data centres that are owned and run by cloud service providers, or CSPs for short. The best-known CSPs are Amazon Web Services (AWS), Microsoft Azure, and Google Cloud.

This is just a short recap to make sure you understand the key concepts. My article above covers it in full if you want or need more info.

What Does On-Premises Mean?

Before the cloud, most organisations ran their systems on-premises. On-premises means the hardware sits in a building the organisation owns or rents. This could be a server room in their office, with its own staff looking after it.

In this setup, you're responsible for everything. This includes buying servers, setting up the network, installing and updating software, and keeping the room powered and cool.

For example, if a small business wanted to launch an online shop, it would need to buy a server, install the software, and pay someone to keep it running. If the shop grew faster than expected, it would need to buy more hardware.

What Changes When You Move to the Cloud?

The cloud moves some of that work to the provider. The physical servers still exist, but someone else owns and maintains them, and you rent what you need.

What differs from one cloud service to the next is how much of the work the provider takes on for you. The cloud service models describe this, and there are three main ones:

• Infrastructure as a Service (or IaaS): Here the provider gives you virtual servers, storage, and networking. Then you manage everything you put on them.
• Platform as a Service (or PaaS): Here, the provider also manages the operating system and the tools your code needs to run. You bring your application and your data.
• Software as a Service (or SaaS): In this model, the provider gives you a finished application. You sign in, use it, and manage your users and data.

So a cloud service model describes how the work is split between you, the customer, and the provider, that is which parts of the system you manage and which parts the provider manages for you.

The Shared Responsibility Model

The shared responsibility model defines which parts of a cloud system the provider manages and which parts you, as the customer, manage. To understand it, you first need to see the parts that make up a running application.

The Layers of a Computing Stack

A computing stack is the set of layers that work together to run an application. Each layer depends on the ones beneath it. From the bottom up, we have:

• Networking: the physical cables, switches, and routers that connect servers to each other and to the internet.
• Storage: the physical drives where files and databases are saved.
• Servers: the physical computers that provide processing power (CPU) and memory (RAM).
• Virtualisation: software that splits one physical server into several virtual machines, or VMs for short. A VM behaves like a separate computer even though it shares hardware with other VMs.
• Operating system: the base software, such as Linux or Windows, that manages the hardware and lets other programs run.
• Middleware: software that connects your application to the outside world and to other services, such as a web server that receives requests from browsers.
• Runtime: the environment your code needs to run, such as Node.js for JavaScript or the Python interpreter for Python.
• Application: the software itself, such as an online shop or an email client.
• Data: the information the application stores and processes, such as customer records, orders, and emails.

Who Manages What in Each Model

AWS describes the split as security “of” the cloud and security “in” the cloud. The provider manages the security of the cloud. This covers the data centres, physical hardware, physical network, and the virtualisation layer.

But security in the cloud is the customer's job. It covers what you put into the cloud and how you configure it. This includes your data, your users and their permissions, and the settings of the services you use.

Infrastructure as a Service (IaaS)

Infrastructure as a Service is a cloud model where the provider gives you the basic building blocks of computing. This includes virtual servers, storage, and networking.

How IaaS Works

With IaaS, you request a virtual machine from the provider. You choose how many CPUs and how much memory it has, which operating system it runs, and which network it connects to. Within minutes, the VM is running, and you can connect to it.

From that point, the server is yours to manage. You install your software, apply operating system updates, configure the firewall, and keep your application running.

Before IaaS, getting a new server meant ordering hardware and waiting weeks for installation. With IaaS, the same server is ready in minutes, and you can delete it when you no longer need it.

Just remember: IaaS removes the hardware burden, but it doesn't remove the server burden.

With IaaS, you usually pay for each hour or second a server is running, plus the storage you keep and outbound data transfer.

Real-World Examples include:

• Amazon EC2 (Elastic Compute Cloud) on AWS
• Google Compute Engine on Google Cloud
• Azure Virtual Machines on Microsoft Azure

Each of these gives you virtual machines. They work alongside other IaaS building blocks, such as virtual disks (Amazon EBS), storage for files and backups (Amazon S3), and private networks (Amazon VPC).

When to Use IaaS

IaaS is the right choice when you need control over the operating system and everything on it, especially when:

• You need a specific operating system version or software that a managed platform doesn't support.
• You need to meet security or compliance rules that require you to configure and audit the server yourself.
• You're moving an existing application from your own servers to the cloud without rewriting it. This is often called “lift and shift”.
• You need development and test environments that you create and delete often.

Tradeoffs

As with any system, there are some tradeoffs you should be aware of before selecting this model.

First, you manage the operating system. You handle patching, security updates, and backups, and a missed update can create a security gap.

You also need to plan for scaling. The provider gives you tools to add servers automatically, but you have to set them up and test them.

In addition, you may need to acquire some new skills. Running servers well requires knowledge of Linux or Windows administration, networking, and security.

And you also pay for idle time. A server that runs all night with no traffic still costs money.

Platform as a Service (PaaS)

Platform as a Service is a cloud model where the provider gives you a ready environment to run your code. The provider manages the servers, operating system, middleware, and runtime. The customer brings the application code and data.

How PaaS Works

With IaaS, you still have to prepare a server before your application can run. This includes updating the operating system, setting up a web server, installing the right language version, and keeping it all maintained.

PaaS removes this burden. With PaaS, you tell the platform which language your application uses, then send your code, usually by pushing to Git or uploading a package. The platform builds your application, runs it on managed servers, and gives you a web address. When traffic grows, it can run more copies of your application based on rules you set.

You still decide how much memory your application gets, which settings it uses, and who can deploy it. You just no longer have to log in to servers to patch and maintain them.

With PaaS, you usually pay for the resources your application uses, such as the size and number of running instances, billed by the hour or month.

Real-World Examples include:

• Heroku
• AWS Elastic Beanstalk
• Google App Engine
• Azure App Service

There are some products that sit between categories. For example, Firebase from Google is often called a PaaS, but it's more accurately a Backend as a Service, or BaaS. A BaaS gives you ready-made backend features, such as a database, user authentication flow, and file storage, that your app calls directly. You don't deploy a whole application to it the way you would on Heroku, for example.

Another is Amazon RDS (Relational Database Service), which is a managed database. AWS runs the database software and backups, while you manage the tables, data, and access. It works like PaaS, but for databases.

When to Use PaaS

• You want to launch a web application or API quickly and focus on code.
• Your team is small and has nobody dedicated to managing servers.
• Your application uses a common language the platform supports, such as Node.js, Python, Java, or .NET.
• You want deployments, scaling, and monitoring without building them yourself.

Tradeoffs

The first tradeoff here is that you have less control. You can't install just any software you want or change operating system settings. Also, if the platform doesn't support something, you have to work around it.

You also risk vendor lock-in. Vendor lock-in means that moving to another provider becomes hard because your application depends on features only one platform offers.

Also, you may pay more at scale. As traffic grows, PaaS can cost more than running the same workload on servers you manage because you pay for the convenience.

And you need to work within platform limits, such as maximum request times or supported language versions.

Finally, you still own your code’s security, including the third-party libraries it uses (and all the risks that come with that).

Software as a Service (SaaS)

Software as a Service is a cloud model where the provider delivers a complete application over the internet. You access it through a web browser or an app, and the provider manages everything needed to keep it running.

How SaaS Works

Before SaaS, using business software meant buying a license, installing it on every computer, and updating each one for every new version. For example, if an organisation wanted its own email system, it would need its own email server, someone to run it, and a backup plan.

This is different with SaaS. The provider runs the application on its own infrastructure, and every customer uses the same centrally updated version. You create an account, add your users, and start working. New features and security fixes arrive without you installing anything.

Your work moves from running software to configuring it. You decide who gets an account, what each person can access, and how files are shared.

With SaaS, you usually pay per user per month or per year, often in tiers with more features at higher levels.

Real-World Examples include:

• Gmail and Google Workspace, for email, documents, and file storage
• Microsoft 365, for Outlook, Word, Excel, and Teams
• Slack, for team messaging
• Zoom, for video meetings
• Dropbox, for file storage and sharing
• Salesforce, for managing customers and sales

When to Use SaaS

• The software solves a common problem that many organisations share, such as email, documents, chat, or accounting.
• You don't want to build or run the software yourself.
• Your team needs access from anywhere, on any device.
• You need the tool working this week, not in six months.

For example, say a non-governmental organisation with twenty staff who need professional email, shared documents, and video calls. It has no IT team. With Google Workspace or Microsoft 365, one administrator can set up accounts for every staff member in a day, while the provider handles the servers, updates, and spam filtering.

Tradeoffs

With this option, you have the least control. You get the features the provider builds, and if you need something it doesn't offer, you wait or look elsewhere.

Also, your data lives with the provider. You depend on their security, so you need to know where your data is stored and how you can export it if you leave.

Your costs could also easily grow with your team.

Further, you depend on your internet connection. When connectivity is unreliable, a browser-based tool can become unavailable when you need it most.

And you have limited customisation options. Connecting the tool to your other systems depends on what the provider allows.

Beyond the Big Three: CaaS, FaaS, and Serverless

IaaS, PaaS, and SaaS are the main models, but there are also options like CaaS, FaaS, and serverless. Let’s look at what each means and how it works.

Containers as a Service (CaaS)

A container packages your application with everything it needs to run, including its runtime, libraries, and settings. Because everything is inside the package, a container runs the same way on your laptop as it does on a server in the cloud. Docker is the most common tool for building containers.

Containers as a Service, or CaaS, is a model where the provider runs and manages containers for you. You give it your container images, and it starts them, restarts them when they fail, and spreads them across servers. The software that makes these decisions is called a container orchestrator, and Kubernetes is the most widely used one.

CaaS sits between IaaS and PaaS. You have more control than on a PaaS, because you decide exactly what goes into each container, but the provider handles much of the work of running them.

Some common examples include:

• Amazon ECS (Elastic Container Service), which is AWS’s own orchestrator
• Amazon EKS (Elastic Kubernetes Service), which is managed Kubernetes on AWS
• Google Kubernetes Engine (GKE), which is managed Kubernetes on Google Cloud

With ECS and EKS, you may still manage the virtual machines your containers run on, unless you use AWS Fargate, which runs containers without you managing any servers.

Functions as a Service (FaaS)

Functions as a Service, or FaaS, is a model where you upload small pieces of code called functions, and the provider runs each one only when an event triggers it. An event is something that happens, such as a web request arriving, a file being uploaded, or a scheduled time being reached.

You don't keep a server running while you wait for work. When the event happens, the provider starts your function, runs it, and stops it. You pay per request and for the compute time each run uses, so you pay nothing for compute when nothing happens.

For example, say that an online shop needs to create a small thumbnail every time a seller uploads a product photo. With IaaS, you keep a server running all day to watch for uploads, even at 3 a.m. when nobody is uploading. With FaaS, the upload itself triggers a function that creates the thumbnail, and you pay only for the seconds it runs.

Some common examples include:

• AWS Lambda
• Azure Functions
• Google Cloud Run functions, previously called Google Cloud Functions

FaaS has trade-offs, too. Each run has a time limit, and an idle function can take a moment longer to start. This is called a cold start.

Where Serverless Fits

Serverless describes cloud services where you never set up or manage servers, the service scales automatically with demand, and you pay only for what you use rather than for idle capacity.

Serverless isn't a fourth model on the stack. It describes how a service is operated and billed, not which layers you manage. FaaS is serverless, but so are many other managed services, such as Amazon S3 for file storage, Amazon DynamoDB for databases, and AWS Fargate for containers.

Google Cloud Run functions, which are CaaS, also fit into the serverless category.

How to Choose the Right Service Model

No single model is best for every project. The right choice depends on what you're building, who's building it, and how much control you need.

To help you decide, you can work through these questions in order:

• Does software that does this job already exist? If yes, start with SaaS.
• Are you building your own application in a common language? If yes, look at PaaS first, or FaaS for small tasks that run in response to events.
• Is your application already packaged in containers? If yes, CaaS or a serverless container platform may suit you.
• Do you need control over the operating system, custom software, or a strict compliance setup? If yes, choose IaaS.
• Is your traffic steady or unpredictable? Unpredictable traffic often suits serverless pay-per-use pricing.

Start with the most managed model that meets your needs, and move down the stack only when you have a clear reason.

Most production systems combine multiple cloud service models, each serving a different purpose.

Wrapping Up

Each service model draws the line between your work and the provider’s at a different point on the stack. IaaS gives you virtual infrastructure, and you manage the operating system and everything above it. PaaS gives you a platform, and you manage your code and data. SaaS gives you a finished application, and you manage your users, data, and settings.

CaaS and FaaS sit between these models, and serverless describes how you operate and pay. In all of them, you (the customer) remain responsible for your data and who can access it.

Thank you for reading!

It’s like setting up a communication network for your app’s brain, and the way you do it can seriously impact how well your app performs.

But here’s the fun part: there’s no one-size-fits-all answer. The communication pattern you choose depends on what your application needs to do.

So, in this tutorial, we’re going to take a look at five different ways backend systems like to chat it up. We’ll explore what they’re good at and when you should invite them to the conversation. Let’s dive right in!

What is a Design Pattern?

Before we get into all the cool patterns, let’s talk about what a design pattern is, shall we?

Design patterns are nifty, tried-and-true reusable solutions to common problems encountered during software design and development. You can call them the cheat codes of software design and development.

They can help provide a structured approach to solving recurring challenges, offering a set of guidelines and best practices that can be adapted for various scenarios.

Now that we’ve got that down, let’s explore five of these emerging design patterns used for backend communication.

Request-Response Pattern

The request-response pattern is a fundamental building block for how the front-end and back-end of web applications chat with each other. This pattern is like a conversation between the client (say your browser) and the server, where they take turns speaking. Imagine it as a “ping-pong” of data.

Here's a diagram illustrating what that looks like:

request/response communication model

How does the Request-Response pattern work?

This pattern is all about synchronization. The client sends a request to the server, kind of like raising your hand to ask a question in class. Then it patiently waits for the server to respond before it can move on.

It’s like a polite conversation — one speaks, the other listens, and then they swap roles.

You’ve probably heard of RESTful APIs, right? Well, they’re a prime example of the request-response model in action.

When your app needs some data or wants to do something on the server, it crafts an HTTP request — say GET, POST, PUT, or DELETE (like asking nicely for a page), and sends it to specific endpoints (URLs) on the server. The server then processes your request and replies with the data you need or performs the requested action.

It’s like ordering your favorite dish from a menu — you ask, and the kitchen (server) cooks it up for you.

Interestingly, there’s more than one way to have this conversation. Besides REST, there’s GraphQL, an alternative that lets you ask for exactly the data you want. It’s like customizing your order at a restaurant — you get to pick and choose your ingredients.

It’s important to note that this pattern isn’t just limited to web applications. You’ll spot it in Remote Procedure Calls (RPCs), database queries (with the server being the client and the database, the server), and network protocols (HTTP, SMTP, FTP) to name a few. It’s like the language of communication for the web.

Benefits of the Request-Response pattern

Ease of Implementation and Simplicity: The way communication flows in this model is pretty straightforward, making it a go-to choice for many developers, especially when they’re building apps with basic interaction needs.

Flexibility and Adaptability (One Size Fits Many): The request-response pattern seamlessly fits into a wide range of contexts. You can use it for making API calls, rendering web pages on the server, fetching data from databases, and more.

Scalability: Each request from the client is handled individually, so the server can easily manage multiple requests at once. This is highly beneficial for high-traffic websites, APIs that get tons of calls, or cloud-based services.

Reliability: Since the server always sends back a response, the client can be sure its request is received and processed. This helps maintain data consistency and ensures that actions have been executed as intended even during high-traffic scenarios.

Ease of Debugging: If something goes wrong, the server kindly sends an error message with a status code stating what happened. This makes error handling easy.

Limitations of the Request-Response Pattern

Latency Problem: Because it’s a back-and-forth conversation, there’s often a waiting period. This amounts to idle periods and amplifies latency, especially when the request requires the server to perform time-consuming computing tasks.

Data Inconsistency in Case of Failures: If a failure occurs after the server has processed the request but before the response is delivered to the client, data inconsistency may result.

Complexity in Real-Time Communication: For applications that need lightning-fast real-time communication (like live streaming, gaming, or chat apps), this pattern can introduce delays and is therefore unsuitable for these use-cases.

Inefficiency in Broadcasting: In scenarios where you need to send the same data to multiple clients at once (broadcast), this pattern can be a bit inefficient. It’s like mailing individual letters instead of sending one group message.

Here’s a code example that shows the request-response pattern using Nodejs.

First, we have the server.js file. Here we’ve set up the server to listen for incoming requests from the client.

const http = require("http");

const server = http.createServer((req, res) => {
 res.statusCode = 200;
 res.setHeader("Content-Type", "text/plain");

 //check request method and receive data from client
 if (req.method === "POST") {
  let incomingMessage = "";
  req.on("data", (chunk) => {
   incomingMessage += chunk;
  });

  //write back message received from the client on the console
  req.on("end", () => {
   console.log(`Message from client: ${incomingMessage}`);
   res.end(`Hello client, message received!`);
  });
 } else {
  res.end("Hey there,  Client!\n");
 }
});

const PORT = 3030;
server.listen(PORT, () => {
 console.log(
  `Server is listening for incoming request from client on port:${PORT}`
 );
});

And here's the client.js file:

const http = require("http");

const options = {
 method: "POST",
 hostname: "localhost",
 port: 3030,
 path: "/",
};

//message to server
let messageToServer = "Hey there, server!";

//send a http request to the server
const req = http.request(options, (res) => {
 let incomingData = "";

 res.on("data", (chunk) => {
  incomingData += chunk;
 });

 res.on("end", () => {
  console.log(`Response from the server: ${incomingData}`);
 });
});

req.on("error", (error) => {
 console.log(`Error message: ${error.message}`);
});

//send message to the server
req.write(messageToServer);

//end your request
req.end();

Here's the output:

code output on the terminal

The Publish/Subscribe Pattern

Publish/Subscribe is another communication design pattern you may see on the backend. It is used in distributed systems for asynchronous communication between several (usually decoupled) components. It’s perfect for when you’ve got a bunch of components that need to work together but want to keep their distance.

Here's a diagram showing how it works:

Pub/Sub communication model

How does the Publish/Subscribe pattern work?

This pattern involves the use of message queues (often called message brokers) which serve as intermediaries between the publishers and subscribers. These message brokers group messages into something called channels (or topics).

Publishers are the components that create and send messages while subscribers are the components that receive and consume the messages.

The publishers simply toss messages (or events) into specific channels/topics within the message broker. These channels act as the distribution point for the messages. The subscribers then indicate interest by subscribing to those channels within the message broker and whenever a message or event is published to that channel, they receive a copy.

Message queuing tools like Apache Kafka and MQTT use the publish/subscribe communication pattern under the hood.

Benefits of the Publish/Subscribe pattern

Asynchronous Communication: Unlike the request-response model, pub/sub is designed to be asynchronous by nature. This makes it ideal for building real-time applications with reduced latency bottlenecks.

Loose Coupling of Components: The components in a publish/subscribe model are loosely coupled. This means that they are not tied together and can freely interact by triggering and responding to events.

Highly Scalable: There is no limit to the number of subscribers a publisher can publish events to. Also, there’s no limit to the number of publishers subscribers can subscribe to.

Independent of Language and Protocol: The Pub/Sub model can be easily integrated into any tech stack because it is language-agnostic. Also, it often supports a wide range of environments and platforms making it cross-platform compatible.

Load Balancing: In cases where multiple subscribers subscribe to a particular event, the pub/sub model can distribute the events evenly among the subscribers, providing load-balancing capabilities out of the box.

Limitations of the Publish/Subscribe pattern

Complexity in Implementation: Setting up a Pub/Sub system can be more complex than simpler communication models like the request-response pattern. You need to configure and manage message brokers, channels, and subscriptions, which can add overhead to your system.

Message Duplication: Depending on the configuration and network issues, messages can be duplicated. Subscribers might receive the same message more than once, which can lead to redundancy and extra processing.

Scalability Challenges: While Pub/Sub is highly scalable, managing extremely high volumes of messages and subscribers can become complex. You might need to consider how to distribute messages efficiently and handle massive numbers of subscribers.

Complex Error Handling: Dealing with errors in a Pub/Sub system can be challenging. Handling situations like message delivery failures or subscriber errors requires careful consideration and design.

When should you use it?

• In building features that require real-time and low latency responsiveness for the end-users, for example live chat or gaming applications for multiple players.
• In event notification systems
• In building distributed systems that rely on logging and caching

Here’s a code snippet showing a simple pub/sub implementation using the npm package pubsub-js.

Here are the contents of the pubsub.js file:

const PubSub = require("pubsub-js");

/*
create  a topic of choice.
Any subscriber that subscribes to this topic
receives the published messages
*/
const TOPIC = "chat";

//a function to publish a messgae to subscribers
function publishMessageToSubscribers(message) {
 PubSub.publish(TOPIC, message);
 console.log(`Message Published: ${message}`);
}

let subscriber1 = function (msg, data) {
 console.log(msg, data);
 console.log("subscriber1 received: ", data);
};

let subscriber2 = function (msg, data) {
 console.log(msg, data);
 console.log("subscriber2 received: ", data);
};

// Subscriber1 subscribes to the topic
PubSub.subscribe(TOPIC, subscriber1);

//subscriber2 subscribes to topic
PubSub.subscribe(TOPIC, subscriber2);

publishMessageToSubscribers("Hello subscriber!");

console.log("Subscriber 1 is listening....");

console.log("Subscriber 2 is listening....");

Here's the output:

The Short Polling Pattern

Short polling is another communication pattern that facilitates data exchange between client and server. It uses the pull-based communication mechanism (which is basically the client pulling data from the backend) to continuously poll the server for new updates.

How does Short Polling work?

Imagine you’re waiting for a message from a friend, and you don’t want to miss it. What do you do? You keep asking, “Got a message for me yet?”

So, the client makes a request to the server at regular (fixed) intervals (say every x unit of time) to check for new data or updates. The server sends back a response and if there’s new available data or an update, the server includes the data in the response.

Here’s what the client-server communication would look like:

• Client: “Hey, server, any new messages?”
• Server: “Nah, nothing yet.”
• Client: “Alright, I’ll check back later.”
• [Some time passes…]
• Client: “Hey, server, any new messages?”
• Server: “Bingo! Here they are!”

Although polling has some similarities with the request-response model we discussed earlier, a key difference between them is timing.

While polling occurs at regular, predefined intervals regardless of whether updates are available, the request-response model allows clients to request data or actions on-demand when needed, reducing unnecessary communication.

Benefits of Polling

Simplicity: Polling is easy to understand and implement and it’s completely stateless between the client and server. This makes it perfect for scenarios where the complexities need to be minimized.

Compatibility: It can be used with a wide range of technologies and protocols which makes it highly compatible with a number of platforms and environments.

Some example use cases of polling pattern includes simple dashboards, weather apps that require periodic updates, resource monitoring, or in cases where you’re considering cross-platform compatibility.

Limitations of Polling

Latency: Polling introduces latency, as clients must wait for predefined intervals before receiving updates. This can lead to delays in accessing real-time data or receiving notifications.

Inefficiency: Constantly polling the server for updates can be inefficient and can result in unnecessary network and server overhead.

Scaling: Handling a large number of simultaneous clients using polling can be resource-intensive for the server. It may require significant server resources to manage numerous concurrent polling requests.

Here's a code snippet to illustrate short polling. Here, the client sends a periodic request(polls ) to the server to check for upload progress.

The app.js file:

const express = require("express");

const app = express();

//create a dictionary to store the upload progress
const uploadStatus = {};

//simulate upload of file
app.post("/upload", (req, res) => {
 //create a unique request id for incoming request
 const requestId = Math.floor(Math.random() * 1000000);
 uploadStatus[requestId] = 0;

 simulateUploadProgress(requestId);

 res.json({ requestId });
});

//endpoint to check upload progress
app.get("/status/:requestId", (req, res) => {
 const requestId = parseInt(req.params.requestId);

 if (!isNaN(requestId) && uploadStatus[requestId] !== undefined) {
  if (uploadStatus[requestId] === 100) {
   //upload completed
   res.json({ progress: 100, message: "UPLOAD COMPLETED!" });
  } else {
   // upload still in progress
   res.json({ progress: uploadStatus[requestId] });
  }
 } else {
  res.status(404).json({ error: "Request ID not found" });
 }
});

//update upload progress by 10% every 5 secs
function simulateUploadProgress(requestId) {
 if (uploadStatus[requestId] < 100) {
  setTimeout(() => {
   uploadStatus[requestId] += 10;
   simulateUploadProgress(requestId);
  }, 5000);
 }
}
const PORT = 4000;

app.listen(PORT, () => {
 console.log(`Server is running on port ${PORT}`);
});

Here's the output in the terminal

The Long Polling Pattern

Long polling is like polling but uses a push-based communication mechanism. In long polling, instead of the client asking the server, “Any updates?” all the time, it says, “Let me know when something’s up.”

Here’s how Long Polling works:

The client pings the server, just like in regular polling, but this time, the server doesn’t immediately answer. It holds the connection open, like keeping a phone line on hold. When there’s something to share, it responds. It’s like the server’s saying, “Hey, I’ll call you when I have news.”

It is used in web applications to achieve real-time or near-real-time updates between a client and a server.

Benefits of the Long Polling Pattern

Low Latency: Long polling provides low latency when compared to traditional polling as data is immediately sent back to clients as soon as they are available.

Real-Time Updates: With the long polling technique, applications can achieve real-time updates without the need for constantly polling the server.

Limitations of the Long Polling Pattern

Resource Intensive: Long polling requires keeping many connections open. As a result, it can be resource-consuming on both the server and client side.

Increased Latency: Although long polling helps cut down on frequent polling, it can still introduce latency when compared to other real-time communication protocols like Web Socket. Clients may experience delays between updates since they have to wait for the server to respond.

Difficult to Scale: When dealing with a large number of concurrent clients, long polling can strain server resources. As more clients establish long-polling connections, the server may struggle to manage and respond to all these connections efficiently.

Typical use cases of long polling include real-time updates, event-driven applications, and event notification systems.

Here's a code snippet to illustrate the concept of long polling where the client waits for updates from the server.

const express = require("express");
const app = express();

const uploadStatus = {};

app.post("/upload", (req, res) => {
 const requestId = Math.floor(Math.random() * 1000000);
 uploadStatus[requestId] = 0;

 updateUploadProgress(requestId, uploadStatus[requestId]);

 res.json({ requestId });
});

app.get("/status/:requestId", async (req, res) => {
 const requestId = parseInt(req.params.requestId);

 //simulate long polling (the server will not respond until done)
 while ((await checkUploadComplete(requestId)) === false);
 res.end("\n\n Upload status: completed " + uploadStatus[requestId]);
});

//update progress by 20% after every 5 seconds
function updateUploadProgress(requestId, progress) {
 uploadStatus[requestId] = progress;
 console.log(`Updated progress to ${progress}`);
 if (progress === 100) return;
 this.setTimeout(() => updateUploadProgress(requestId, progress + 20), 5000);
}

//check upload status
function checkUploadComplete(requestId) {
 return new Promise((resolve, reject) => {
  if (uploadStatus[requestId] < 100) {
   this.setTimeout(() => resolve(false), 1000);
  } else {
   resolve(true);
  }
 });
}
const PORT = 4000;

app.listen(PORT, () => {
 console.log(`Server is running on port ${PORT}`);
});

And here's the output in the terminal.

code output

The Push Pattern

Push is a communication model that is used to deliver real-time updates to connected clients.

In this model, the client opens a connection to the server and awaits messages or updates from the server. Whenever there is a new update or message, the server immediately pushes that update to the client without the client explicitly requesting it — as long it is connected.

This model allows for bidirectional communication between the client and server. Web sockets, a popular protocol, uses the push model as its underlying data exchange method.

The Push model provides the most real-time or near real-time end-user experience when compared to other closely related paradigms such as polling and long polling.

To explain how the push pattern works, imagine a chat room with multiple connected users as an example. The client and server conversation will look like this:

• user1 (client): “Hello…”
• Server: “Oh, user1 has a message!” Instantly sends it to everyone else in the room.
• User2 (client): Gets the message from user1 without doing anything.
• User3 (client): Also receives the message from user1 — no need to refresh or ask for it.

In the example above, the push pattern enables real-time communication such that whenever there’s a message from a client in the chat room, it pushes the message to all other connected clients in that room without them having to continuously poll or request updates.

Popular technologies that uses the push pattern are RabbitMQ and WebSocket.

Benefits of Push Pattern

Real-Time Updates: The push model allows clients to receive updates from the server as soon as they are available. This is key, especially in applications where real-time updates are crucial.

Reduced Latency: Since the server pushes updates to the client as soon as they are available, it potentially reduces the latency.

Efficiency: Because there is no need for continuous polling or frequent client requests, there is efficient use of network resources and reduced server load.

While the push model is widely adopted as the best fit for providing real-time updates, it does have its own disadvantages.

Limitations of Push Pattern

Scalability: It can become difficult to scale as the number of connected clients increases. At this point, it becomes resource-intensive, especially on the server side since the server needs to maintain open connections with multiple clients.

Client support: Some clients might not be able to handle pushed messages as not all client platforms support push technologies. This may lead to compatibility issues and may need some sort of fallback mechanism for unsupported clients.

Some example use cases of the push pattern include chat and messaging apps, notification systems, IoT data streaming, and online gaming, to name a few.

Here’s a simple Node.js code example to illustrate the push pattern using Web Sockets. To run the code, you have to install the ws library using npm.

//create a server - this server will push updates to the clients at intervals
const WebSocket = require("ws");
const server = new WebSocket.Server({ port: 8080 });

server.on("connection", (client) => {
 console.log("Client connected to server");

 //Simulate client to receive real-time updates from the server every 2 seconds
 const interval = setInterval(() => {
  const message = `Message received at: ${new Date().toLocaleTimeString()}`;
  client.send(message);
 }, 2000);

 // Handle client disconnection
 client.on("close", () => {
  clearInterval(interval);
  console.log("Client disconnected");
 });
});

// Client (listens for updates from server)
const clientSocket = new WebSocket("ws://localhost:8080");

clientSocket.onmessage = (event) => {
 console.log(`Message from server: "${event.data}"`);
};

Wrapping Up

In this tutorial, we explored five key communication design patterns: Request-Response, Publish/Subscribe, Short Polling, Long Polling, and Push.

Each pattern has its unique strengths and limitations which makes them suitable for various use cases.

Depending on your application’s goal, understanding these patterns will help you design efficient backend systems.

In this article, you will learn about the fundamentals of regular expressions, regular expression pattern notation, how you can interpret a simple regex pattern, and how to write your own regex pattern. Let’s get to it!

What Are Regular Expressions?

Regular expressions are patterns that allow you to describe, match, or parse text. With regular expressions, you can do things like find and replace text, verify that input data follows the format required, and and other similar things.

Here's a scenario: you want to verify that the telephone number entered by a user on a form matches a format, say, ###-###-#### (where # represents a number). One way to solve this could be:

function isPattern(userInput) {
  if (typeof userInput !== 'string' || userInput.length !== 12) {
    return false;
  }
  for (let i = 0; i < userInput.length; i++) {
    let c = userInput[i];
    switch (i) {
      case 0:
      case 1:
      case 2:
      case 4:
      case 5:
      case 6:
      case 8:
      case 9:
      case 10:
      case 11:
        if (c < 0 || c > 9) return false;
        break;
      case 3:
      case 7:
        if (c !== '-') return false;
        break;
    }
  }
  return true;
}

Alternatively, we can use a regular expression here like this:

function isPattern(userInput) {
  return /^\d{3}-\d{3}-\d{4}$/.test(userInput);
}

Notice how we’ve refactored the code using regex. Amazing right? That is the power of regular expressions.

How to Create A Regular Expression

In JavaScript, you can create a regular expression in either of two ways:

• Method #1: using a regular expression literal. This consists of a pattern enclosed in forward slashes. You can write this with or without a flag (we will see what flag means shortly). The syntax is as follows:

const regExpLiteral = /pattern/;          // Without flags

const regExpLiteralWithFlags = /pattern/; // With flags

The forward slashes /…/ indicate that we are creating a regular expression pattern, just the same way you use quotes “ ” to create a string.

• Method #2: using the RegExp constructor function. The syntax is as follows:

new RegExp(pattern [, flags])

Here, the pattern is enclosed in quotes, the same as the flag parameter, which is optional.

So when do you use each of these pattern?

You should use a regex literal when you know the regular expression pattern at the time of writing the code.

On the other hand, use the Regex constructor if the regex pattern is to be created dynamically. Also, the regex constructor lets you write a pattern using a template literal, but this is not possible with the regex literal syntax.

What are Regular Expression Flags?

Flags or modifiers are characters that enable advanced search features including case-insensitive and global searching. You can use them individually or collectively. Some commonly used ones are:

• g is used for global search which means the search will not return after the first match.
• i is used for case-insensitive search meaning that a match can occur regardless of the casing.
• m is used for multiline search.
• u is used for Unicode search.

Let’s look at some regular expression patterns using both syntaxes.

How to use a regular expression literal:

// Syntax: /pattern/flags

const regExpStr = 'Hello world! hello there';

const regExpLiteral = /Hello/gi;

console.log(regExpStr.match(regExpLiteral));

// Output: ['Hello', 'hello']

Note that if we did not flag the pattern with i, only Hello will be returned.

The pattern /Hello/ is an example of a simple pattern. A simple pattern consists of characters that must appear literally in the target text. For a match to occur, the target text must follow the same sequence as the pattern.

For example, if you re-write the text in the previous example and try to match it:

const regExpLiteral = /Hello/gi;

const regExpStr = 'oHell world, ohell there!';

console.log(regExpStr.match(regExpLiteral));

// Output: null

We get null because the characters in the string do not appear as specified in the pattern. So a literal pattern such as /hello/, means h followed by e followed by l followed by l followed by o, exactly like that.

How to use a regex constructor:

// Syntax: RegExp(pattern [, flags])

const regExpConstructor = new RegExp('xyz', 'g'); // With flag -g

const str = 'xyz xyz';

console.log(str.match(regExpConstructor));

// Output: ['xyz', 'xyz']

Here, the pattern xyz is passed in as a string same as the flag. Also both occurrences of xyz got matched because we passed in the -g flag. Without it, only the first match will be returned.

We can also pass in dynamically created patterns as template literals using the constructor function. For example:

const pattern = prompt('Enter a pattern');
// Suppose the user enters 'xyz'

const regExpConst = new RegExp(`${pattern}`, 'gi');

const str = 'xyz XYZ';

console.log(str.match(regExpConst)); // Output: ['xyz', 'XYZ']

How to Use Regular Expression Special Characters

A special character in a regular expression is a character with a reserved meaning. Using special characters, you can do more than just find a direct match.

For example, if you want to match a character in a string that may or may not appear once or multiple times, you can do this with special characters. These characters fit into different subgroups that perform similar functions.

Let's take a look at each subgroup and the characters that go with them.

Anchors and Boundaries:

Anchors are metacharacters that match the start and end of a line of text they are examining. You use them to assert where a boundary should be.

The two characters used are ^ and $.

• ^ matches the start of a line and anchors a literal at the beginning of that line. For example:

const regexPattern1 = /^cat/;

console.log(regexPattern1.test('cat and mouse')); // Output: true

console.log(regexPattern1.test('The cat and mouse')); // Output: false because the line does not start with cat

// Without the ^ in the pattern, the output will return true
// because we did not assert a boundary.

const regexPattern2 = /cat/;

console.log(regexPattern2.test('The cat and mouse')); // Output: true

• $ matches the end of a line and anchors a literal at the end of that line. For example:

const regexPattern = /cat$/;

console.log(regexPattern.test('The mouse and the cat')); // Output: true

console.log(regexPattern.test('The cat and mouse')); // Output: false

Note that anchors characters ^ and $ match just the position of the characters in the pattern and not the actual characters themselves.

Word Boundaries are metacharacters that match the start and end position of a word – a sequence of alphanumeric characters. You can think of them as a word-based version of ^ and $. You use the metacharacters b and B to assert a word boundary.

• \b matches the start or end of a word. The word is matched according to the position of the metacharacter. Here's an example:

// Syntax 1: /\b.../ where .... represents a word.

// Search for a word that begins with the pattern ward
const regexPattern1 = /\bward/gi;

const text1 = 'backward Wardrobe Ward';

console.log(text1.match(regexPattern1)); // Output: ['Ward', 'Ward']

// Syntax 2: /...\b/

// Search for a word that ends with the pattern ward
const regexPattern2 = /ward\b/gi;

const text2 = 'backward Wardrobe Ward';

console.log(text2.match(regexPattern2)); // Output: ['ward', 'Ward']

// Syntax 3: /\b....\b/

// Search for a stand-alone word that begins and end with the pattern ward
const regexPattern3 = /\bward\b/gi;

const text3 = 'backward Wardrobe Ward';

console.log(text3.match(regexPattern3)); // Output: ['Ward']

• \B is opposite of \b . It matches every position \b doesn't.

Shortcodes for Other Metacharacters:

In addition to the metacharacters we have looked at, here are some of the most commonly used ones:

• \d – matches any decimal digit and is shorthand for [0-9].
• \w – matches any alphanumeric character which could be a letter, a digit, or an underscore. \w is shorthand for [A-Za-z0-9_].
• \s – matches any white space character.
• \D – matches any non-digit and is the same as [^0-9.]
• \W – matches any non-word (that is non-alphanumeric) character and is shorthand for [^A-Za-z0-9_].
• \S – matches a non-white space character.
• . – matches any character.

What is a Character Class?

A character class is used to match any one of several characters in a particular position. To denote a character class, you use square brackets [] and then list the characters you want to match inside the brackets.

Let's look at an example:

// Find and match a word with two alternative spellings

const regexPattern = /ambi[ea]nce/;

console.log(regexPattern.test('ambiance')); // Output: true

console.log(regexPattern.test('ambiance')); // Output: true

// The regex pattern interprets as:  find a followed by m, then b,
// then i, then either e or a, then n, then c, and then e.

What is a Negated Character Class?

If you add a caret symbol inside a character class like this [^...], it will match any character that is not listed inside the square brackets. For example:

const regexPattern = /[^bc]at/;

console.log(regexPattern.test('bat')); // Output: false

console.log(regexPattern.test('cat')); // Output: false

console.log(regexPattern.test('mat')); // Output: true

What is a Range?

A hyphen - indicates range when used inside a character class. Suppose you want to match a set of numbers, say [0123456789], or a set of characters, say[abcdefg]. You can write it as a range like this, [0-9] and [a-g], respectively.

What is Alternation?

Alternation is yet another way you can specify a set of options. Here, you use the pipe character | to match any of several subexpressions. Either of the subexpressions is called an alternative.

The pipe symbol means ‘or’, so it matches a series of options. It allows you combine subexpressions as alternatives.

For example, (x|y|z)a will match xa or ya, or za. In order to limit the reach of the alternation, you can use parentheses to group the alternatives together.

Without the parentheses, x|y|za would mean x or y or za. For example:

const regexPattern = /(Bob|George)\sClan/;

console.log(regexPattern.test('Bob Clan')); // Output: true

console.log(regexPattern.test('George Clan')); // Output: true

What are Quantifiers and Greediness?

Quantifiers denote how many times a character, a character class, or group should appear in the target text for a match to occur. Here are some peculiar ones:

• + will match any character it is appended to if the character appears at least once. For example:

const regexPattern = /hel+o/;

console.log(regexPattern.test('helo'));          // Output:true

console.log(regexPattern.test('hellllllllllo')); // Output: true

console.log(regexPattern.test('heo'));           // Output: false

• * is similar to the + character but with a slight difference. When you append * to a character, it means you want to match any number of that character including none. Here’s an example:

const regexPattern = /hel*o/;

console.log(regexPattern.test('helo'));    // Output: true

console.log(regexPattern.test('hellllo')); // Output: true

console.log(regexPattern.test('heo'));     // Output: true

// Here the * matches 0 or any number of 'l'

• ? implies "optional". When you append it to a character, it means the character may or may not appear. For example:

const regexPattern = /colou?r/;

console.log(regexPattern.test('color'));  // Output: true

console.log(regexPattern.test('colour')); // Output: true

// The ? after the character u makes u optional

• {N}, when appended to a character or character class, specifies how many of the character we want. For example /\d{3}/ means match three consecutive digits.
• {N,M} is called the interval quantifier and is used to specify a range for the minimum and maximum possible match. For example /\d{3, 6}/ means match a minimum of 3 and a maximum of 6 consecutive digits.
• {N, } denotes an open-ended range. For example /\d{3, }/ means match any 3 or more consecutive digits.

What is Greediness in Regex?

All quantifiers by default are greedy. This means that they will try to match all possible characters.

To remove this default state and make them non-greedy, you append a ? to the operator like this +?, *?, {N}?, {N,M}?.....and so on.

What are Grouping and Backreferencing?

We previously looked at how we can limit the scope of alternation using the parentheses.

What if you want to use a quantifier like + or * on more than one character at a time – say a character class or group? You can group them together as a whole using the parentheses before appending the quantifier, just like in this example:

const regExp = /abc+(xyz+)+/i;

console.log(regExp.test('abcxyzzzzXYZ')); // Output: true

Here's what the pattern means: The first + matches the c of abc, the second + matches the z of xyz, and the third + matches the subexpression xyz, which will match if the sequence repeats.

Backreferencing allows you to match a new pattern that is the same as a previously matched pattern in a regular expression. You also use parentheses for backreferencing because it can remember a previously matched subexpression it encloses (that is, the captured group).

However, it is possible to have more than one captured group in a regular expression. So, to backreference any of the captured group, you use a number to identify the parentheses.

Suppose you have 3 captured groups in a regex and you want to backreference any of them. You use \1, \2, or \3, to refer to the first, second, or third parentheses. To number the parentheses, you start counting the open parentheses from the left.

Let's look at some examples:

(x) matches x and remembers the match.

const regExp = /(abc)bar\1/i;

// abc is backreferenced and is anchored at the same position as \1
console.log(regExp.test('abcbarAbc')); // Output: true

console.log(regExp.test('abcbar')); // Output: false

(?:x) matches x but does not recall the match. Also, \n (where n is a number) does not remember a previously captured group, and will match as a literal. Using an example:

const regExp = /(?:abc)bar\1/i;

console.log(regExp.test('abcbarabc')); // Output: false

console.log(regExp.test('abcbar\1')); // Output: true

The Escape Rule

A metacharacter has to be escaped with a backslash if you want it to appear as a literal in your regular expression. By escaping a metacharacter in regex, the metacharacter loses its special meaning.

Regular Expression Methods

The test() method

We have used this method a number of times in this article. The test() method compares the target text with the regex pattern and returns a boolean value accordingly. If there is a match, it returns true, otherwise it returns false.

const regExp = /abc/i;

console.log(regExp.test('abcdef')); // Output: true

console.log(regExp.test('bcadef')); // Output: false

The exec() method

The exec() method compares the target text with the regex pattern. If there's a match, it returns an array with the match – otherwise it returns null. For example:

const regExp = /abc/i;

console.log(regExp.exec('abcdef'));
// Output: ['abc', index: 0, input: 'abcdef', groups: undefined]

console.log(regExp.exec('bcadef'));
// Output: null

Also, there are string methods that accept regular expressions as a parameter like [match()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match), [replace()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace), [replaceAll()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll), [matchAll()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/matchAll), [search()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/search), and [split()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split).

Regex Examples

Here are some examples to reinforce some of the concepts we've learned in this article.

First example: How to use a regex pattern to match an email address:

const regexPattern = /^[(\w\d\W)+]+@[\w+]+\.[\w+]+$/i;

console.log(regexPattern.test('abcdef123@gmailcom'));
// Output: false, missing dot

console.log(regexPattern.test('abcdef123gmail.'));
// Output: false, missing end literal 'com'

console.log(regexPattern.test('abcdef123@gmail.com'));
// Output: true, the input matches the pattern correctly

Let's interpret the pattern. Here's what's happening:

• / represents the start of the regular expression pattern.
• ^ checks for the start of a line with the characters in the character class.
• **[(\w\d\W)+ ]+** matches any word, digit and non-word character in the character class at least once. Notice how the parentheses were used to group the characters before adding the quantifier. This is same as this [\w+\d+\W+]+ .
• **@** matches the literal @ in the email format.
• **[\w+]+** matches any word character in this character class at least once.
• **\.** escapes the dot so it appears as a literal character.
• **[\w+]+$** matches any word character in this class. Also this character class is anchored at the end of the line.
• **/** - ends the pattern

Alright, next example: how to match a URL with format http://example.com or https://www.example.com:

const pattern = /^[https?]+:\/\/((w{3}\.)?[\w+]+)\.[\w+]+$/i;

console.log(pattern.test('https://www.example.com'));
// Output: true

console.log(pattern.test('http://example.com'));
// Output: true

console.log(pattern.test('https://example'));
// Output: false

Let's also interpret this pattern. Here's what's happening:

• /...../ represents the start and end of the regex pattern
• ^ asserts for the start of the line
• [https?]+ matches the characters listed at least once, however ? makes 's' optional.
• : matches a literal semi-colon.
• \/\/ escapes the two forward slashes.
• (w{3}\.) matches the character w 3 times and the dot that follows immediately. However, this group is optional.
• [\w+]+ matches character in this class at least once.
• \. escapes the dot
• [\w+]+$ matches any word character in this class. Also this character class is anchored at the end of the line.

Conclusion

In this article, we looked at the fundamentals of regular expressions. We also explained some regular expression patterns, and practiced with a few examples.

There's more to regular expressions beyond this article. To help you learn more about regular expressions, here are some resources you can read through:

• Regular Expression
• Learn Regex crash course
• Regular Expression Tutorial
• Regular Expression Cheatsheet

And that's all for this tutorial. Happy coding :)

In this article, you will learn what functions are in JavaScript, how to write your own custom functions, and how to implement them.

As a prerequisite, you should be familiar with some fundamental JavaScript concepts such as variables, expressions, and conditional statements to follow along with this article.

What is a Function in JavaScript?

A function is a block of reusable code written to perform a specific task.

You can think of a function as a sub-program within the main program. A function consists of a set of statements but executes as a single unit.

In JavaScript, we have some browser built-in functions like alert(), prompt(), and confirm(). You have probably used these in your project before, right? But you can still create your own custom functions.

There are several ways to define a function. Most commonly, we have function declaration and function expression.

How to Define a Function using Function Declaration

You write a function declaration like this:

function nameOfFunction() {
	//some code here....
}

Basically, it consists of the following:

• Function keyword
• The name of the function
• Parentheses (which can take in parameters, or also be empty)
• The body of the function (wrapped in curly braces).

Here's an example:

function sayHello() {
	console.log("Hello world"); 
}

This function won't do a thing – in this case, output Hello world – unless you call it. The term for this is invoking the function.

Here’s how to call the function:

sayHello();

//output: Hello world

Here’s another example:

function sum(num1, num2){
	return num1 + num2;
}

To invoke this function, we call it like this:

sum(1, 2);

//output: 3

You can see a slight difference between our first function example and the second.

If you guessed that it's the content within the parenthesis of the second function, then you’re right!

The function sum() took in two parameters when we defined it – num1, and num2. And when we call it, we passed in two values – the arguments, 1 and 2. Let me explain what these two terms (parameters and arguments) mean.

A parameter is a variable you pass to a function when you declare it.

Suppose you want your function to be dynamic, so that it applies the function’s logic to different sets of data at different times. That’s where parameters come in handy. This way, your function doesn’t just output the same result repeatedly. Instead, its result is dependent on the data you pass in.

An argument, on the other hand, is the value equivalent to the parameter that you pass to the function when you call it.

So the syntax for declaring a function with parameters will look like this:

function nameOfFunction(parameters){
	//function body.....
}

And to invoke it:

nameOfFunction(arguments)

How to Define a Function using a Function Expression

A function expression is another notation for defining a function. In terms of syntax, it is similar to the function declaration. But function expressions allow you to define a named function or omit the function name to create an anonymous function.

Let’s see what a function expression looks like:

let namedFunction = function myFunction(){
	//some code here...
}

Notice that in this example, the function has a name, myFunction. This is not the case with the anonymous function. When defining an anonymous function, you omit the function name just like in this example below:

let anonymousFunction = function(){
	//some code here...
}

You can see that both function examples are assigned to a variable, right?

A function keyword creates a function value that can be assigned to a variable when it is used as an expression.

So, to invoke this function, we call it using the variable name which serves as the new function name.

One major difference between the function declaration and function expression is that, with function declaration, you can invoke the function even before defining it. This is not possible with function expressions.

For example:

console.log(greeting());

function greeting(){
  console.log("Hope you're are good?");

}
//output: Hope you're good?

This won’t work if the function is defined as a function expression because the function expression follows a top-to-bottom control flow sequence.

How to Use Arrow Functions in JavaScript

Arrow functions are yet another notation of a function expression but they have a shorter syntax. They were introduced in ES6 and help us write cleaner code.

Here, the function keyword is excluded and we use an arrow symbol (=>) instead. The syntax looks like this:

let nameOfFunction = (parameters) => {
	//function body
}

If the function body within the curly braces contains only a single statement, then the braces can be omitted. An arrow function with curly braces must include the return keyword.

What are Immediately Invoked Function Expressions (IIFEs)?

IIFE is another function expression notation (explicitly an anonymous function) that works in isolation and is independent of any other code. It gets invoked immediately where it is defined.

The syntax is as follows:

(function (){
	//function body
})();

A use case of IIFE would be to enclose a variable that you may likely not use again inside your code. So, as soon as the function is executed, the variable ceases to exist.

How to Use the Return Keyword in a Function

To create a function that will resolve to a value after the function is invoked, you use the return keyword. You write this within the body of the function.

return is a directive that returns a value to the function after the code within it has been executed.

Here’s an example of a function that returns a value, in this case, the sum of two numbers:

function sum(a, b){
	return  a + b;
}

sum(10, 20);

//output will be 30

Using return inside a function makes it easy to manipulate the data the function returns, by either passing it as a value to, say, another function, or performing additional operations on it.

How Do Function Scope and Closures** Work in JavaScript?**

A scope is a nested namespace that localizes the names created within it such that these names don’t interfere with similar names created outside of that scope. There are certain scope rules that apply within a function.

Each new function you define creates a new scope known as the function scope. Variables created within the function scope are not visible or accessible outside of that scope.

Nevertheless, variables created outside the function scope but within the scope in which the function is defined can be accessed inside the function. Therefore, if you define a function in global scope, it can access all variables declared in that global scope.

Also, suppose you have a child function (that is, an inner function) nested inside a parent function (which is the outer function). The child function can access all variables and functions declared in its parent function as well as all variables and functions the parent function has access to – even when its parent function has finished executing and its variables are no longer accessible outside that function. This concept is known as closures in JavaScript.

However, the parent function cannot access the variables created inside the child function. In this way, the variables and functions inside the child function are confined to their own scope.

Let’s see a code example of this:

//variables defined in the global scope

let  a = 40;
let b = 20;

//this function is also defined in the global scope

function parentFunc(){
	//access variables a and b inside this function

	console.log(a + b); 
}

//output: 60

Suppose I nest an inner function inside the parent function, like this:

//variables defined in the global scope

let a = 40;
let b = 20;

//this function is also defined in the global scope

function parentFunc(){
	let  name = “Doe”;
    
    //this inner function is defined inside the parent function scope
    
	function childFunc(){
		console.log(`${name} is ${a - b} years old`); 
      }
    return childFunc();
}

parentFunc(); //ouput: Doe is 20 years old

Now, if I create a variable inside a function and try to access it from the global scope, we will get a reference error. This is because that variable is local to the function scope and is not visible to the global scope.

console.log(c);

function parentFunc(){
	let c = 30
} 

//output: reference error - c is not defined

Let’s try to access a variable created inside a nested function in the parent function:

function parentFunc(){
	console.log(age);
	function childFunc(){
		let  age = 20;
	} 
    return childFunc();
}

parentFunc(); //output: reference error - age is not defined.

How Do Default Parameters Work in JavaScript?

Originally, function parameters are assigned undefined when no value is explicitly passed to them. Default parameters let you assign a default value to a parameter when you define a function. For example:

function greeting(name, message = ”Hello”){
	console. log(`${messgae}  ${name}`)
}

greeting(‘John’); //output: Hello John

//you can also assign a new value to the default parameter 
//when you call the function

greeting(‘Doe’, ‘Hi’); //output: Hi Doe

It is important to note that in declaring a default parameter, it must come after the regular parameter.

How Do Rest Parameters Work in JavaScript?

With rest parameters, you can define a function to store multiple arguments in a single array. This is particularly useful when you're invoking your function with multiple arguments. Here's an example:

function sayHello(message, ...names){
  names.forEach(name => console.log(`${message} ${name}`));
}

sayHello('Hello', "John", "Smith", "Doe");

/*
output:

Hello John

Hello Smith

Hello Doe 

*/

The ... is what makes names a rest parameter.

Just like default parameters, rest parameters should appear after any regular parameter in your function.

Conclusion

In this article, you learned what functions in JavaScript are all about and how you can write your own functions.

With functions, you can organize your code by grouping everything into separate blocks that perform different tasks.

I hope you enjoyed reading this article. To learn more about functions, here are some resources you can check out:

• JavaScript Functions
• Closures

That's all for this piece. Happy coding :)