DEV Community: Joyce Lin

Build a fingerprint-controlled servo lock with Raspberry Pi

Joyce Lin — Tue, 22 Jul 2025 22:12:26 +0000

Create a secure, biometric access control system that unlocks a servo-powered latch when it detects an enrolled fingerprint. Perfect for geocache boxes, garage doors, or any physical access control application.

What You'll Build

A complete fingerprint authentication system using:

R503 fingerprint sensor for biometric scanning and enrollment
Servo motor controlling a physical latch mechanism
Raspberry Pi 4 running the Viam robotics server
Custom control logic that triggers the servo when fingerprints match

Key Features

Fingerprint Management: Enroll up to 200 different fingerprints across multiple slots, with support for enrolling the same finger multiple times to improve recognition reliability under varying angles and pressure.
Automated Latch Control: Servo automatically moves to open position (180°) when authorized fingerprint detected, then returns to closed position (90°) after configurable timeout (default 30 seconds).
Remote Configuration: Use Viam's web interface to test components, enroll new fingerprints via JSON commands, and monitor sensor readings in real-time.
Extensible Design: Build mobile or web apps using Viam's SDKs to create user-friendly enrollment interfaces for others to add their fingerprints.

Hardware Requirements

Raspberry Pi 4 with USB flash drive
R503 fingerprint sensor
USB-to-serial adapter for sensor connectivity
Servo motor (SG90 or similar)
Jumper wires and connection materials
Optional: 3D-printed or custom enclosure and latch mechanism

Implementation Highlights

The tutorial walks through complete setup including Raspberry Pi OS installation, SSH configuration, Viam platform setup, component wiring diagrams, and step-by-step fingerprint enrollment using JSON commands. The modular design separates sensor detection, servo control, and coordination logic for easy customization.

Ready to build your own biometric lock? Follow the complete step-by-step tutorial 👉 Enable physical access using a fingerprint sensor.

How robots talk: building distributed robots with gRPC and WebRTC

Joyce Lin — Fri, 20 Jun 2025 19:39:04 +0000

👉 This article was originally published on the gRPC community blog.

If you’re building any kind of distributed machine, like robots, drones, or IoT devices, two questions come up fast:

How do you send structured commands and data efficiently?
How do you keep communication resilient when you have an unreliable network?

In this article, I’ll share the approach we use at Viam, an open-source robotics platform that combines gRPC for structured RPCs and WebRTC for peer-to-peer streaming. Even if you’re not building robots, the same architectural ideas can help you design more scalable and adaptable systems.

Bridging the gap between lab-grade robotics and real-world systems

ROS (Robot Operating System) has long been the go-to framework for building and prototyping robotics systems, especially in research and academia. It works well on trusted, local networks because that’s what it was designed for.

But today’s robots don’t stay on tightly-regulated lab benches. They’re deployed on factory floors, out at sea, or in remote fields, where network conditions are unpredictable and reliability matters.

ROS doesn’t handle network communication out of the box. If you need to talk to a robot over the internet, you’re on your own to architect the solution. Modern robotics requires more than local LAN protocols. It needs cloud-ready, peer-to-peer, resilient communication stacks.

Rather than relying on a distributed messaging stack like MQTT or relaying commands through the cloud, Viam uses gRPC and WebRTC to power its robotics platform. Used together, these protocols offer a modern alternative that complements ROS’s strengths. gRPC provides structured, language-agnostic APIs with fast, efficient Protobuf serialization. And WebRTC adds low-latency, peer-to-peer connections, which is ideal for streaming sensor data or real-time video between machines.

Some robot builders are also layering gRPC interfaces on top of ROS, blending ROS’s rich ecosystem with the modern transport and scalability of gRPC.

Why gRPC makes sense for robots

Modern robots are no longer single-purpose machines in fixed environments. They’re mobile, multi-part systems that need to collaborate with sensors, perception services, and control loops, often in real time.

gRPC supports these needs in several key ways:

Low-latency, real-time control: gRPC enables continuous, bidirectional streams, allowing systems to send real-time pose updates to a robotic arm, while simultaneously receiving telemetry, without additional round-trip delays.
Cross-platform, multi-language consistency: gRPC automatically generates client libraries (stubs) for languages like Python, Go, C++, and others, making it easier to bridge different devices, SDKs, and environments with a consistent interface.
Lightweight and efficient serialization: gRPC also helps in bandwidth-constrained environments or on embedded devices, enabled by Protobuf’s lightweight binary encoding.
Security benefits: gRPC is designed with end-to-end encryption (TLS by default) and authentication capabilities baked in, ensuring secure communication between machine parts, whether across local networks or the public internet, without requiring developers to bolt on separate security layers.
Service abstraction for machine parts: With gRPC and Protobuf, every part of a robot, from motors to cameras to sensors, can be modeled as a standardized, language-agnostic service.

In Viam’s public API, each robot component is defined as a gRPC service using Protobuf. Components like arms, cameras, and sensors expose typed methods that can be called remotely. Here’s an excerpt from the arm.proto file that defines basic movement and pose retrieval methods for a robotic arm:

// An ArmService services all arms associated with a robot
service ArmService {
  rpc MoveToPosition (MoveToPositionRequest) returns (MoveToPositionResponse);
  rpc GetEndPosition (GetEndPositionRequest) returns (GetEndPositionResponse);
  rpc GetJointPositions(GetJointPositionsRequest) returns (GetJointPositionsResponse);
}

These proto services can then generate SDKs to help you work with your machines. This example uses the Python SDK to move an arm. Under the hood, gRPC handles encoding the command into a Protobuf message and sending it over HTTP/2 (or WebRTC, depending on the environment).

from viam.components.arm import ArmClient

arm = ArmClient.from_robot(robot=robot, name="my-arm")

# Move the arm to a target 3D position
arm.move_to_position(x=0.1, y=0.2, z=0.3, orientation=None, world_state=None)

Why WebRTC is also part of the picture

At first glance, gRPC and WebRTC might seem redundant. Both can stream data and send structured messages. But they solve very different challenges in robotics.

WebRTC excels at direct, peer-to-peer connections, which is essential when:

Devices are on local networks or constrained by NAT/firewalls
You want to bypass a central relay or cloud server
You’re streaming high-bandwidth sensor data (like real-time video or LIDAR) between machines

Viam uses gRPC for orchestration and WebRTC as the underlying transport, combining them for fast, structured messaging with minimal routing overhead.

Flexible transport layers with gRPC

While WebRTC enables peer-to-peer communication in distributed machines, gRPC also offers flexibility to swap underlying transport layers.

Here is an example gRPC server that runs over WebRTC and other transport protocols. Viam also uses Unix domain sockets (UDS) for local messaging between the viam-server and internal modules, Bluetooth for provisioning machines or proxying network traffic, and serial ports for embedded peripherals.

Because gRPC defines a consistent interface at the API layer, we can change the transport depending on the environment or device without rewriting client logic, a huge strength when building systems that span cloud, local, and constrained networks.

A real-world example: coordinating a claw game

Picture a remote-controlled claw machine, like the ones you’d find in an arcade. It has two main components: a camera and a robotic arm. A user interface, such as a web app or mobile app, sends control commands and receives a live video stream to help guide the claw to its prize.

Here’s how gRPC and WebRTC work together behind the scenes:

Initialization: The system establishes control channels using gRPC over HTTP/2. Each component registers its services (e.g. ArmService, CameraService).
Connection: gRPC coordinates the exchange of peer metadata and signaling to set up a WebRTC session between the SDK and machine parts.
Real-time operation: WebRTC now handles the media and data streams directly between peers. Commands are sent using gRPC method calls, routed over the WebRTC transport. Video and sensor streams flow the other way.

This dual-protocol approach allows real-time interaction, smooth streaming, and resilient fallback behavior, even in unpredictable network conditions.

Why this pattern matters for the broader community

The combination of gRPC’s structure and WebRTC’s flexibility opens the door to a new class of distributed systems, not just in robotics, but anywhere you need:

Real-time, bi-directional communication between loosely-coupled systems
Typed, versioned APIs that span languages and devices
Transport-agnostic flexibility, with the option to go peer-to-peer when needed

gRPC structures the conversation. WebRTC carries it across the network.

Viam for real-time robot control

gRPC has evolved far beyond simple request/response APIs. Across many industries beyond robotics, the way machines communicate is more critical than ever. gRPC and WebRTC aren’t just faster protocols, they’re influential building blocks for the next generation of distributed, resilient, and intelligent machines.

If you’re building systems that need to talk to each other across devices, environments, and networks, it might be time to explore a more scalable and adaptable communication layer.

While you could engineer a similar stack on your own, Viam offers these capabilities out of the box. The on-machine functionality is open-source and free to operate, with optional cloud services available on a usage-based model when you scale to fleets.

Technical review by @hipsterbrown (Viam)

When Code Meets Reality: Lessons from Building in the Physical World

Joyce Lin — Thu, 10 Apr 2025 14:04:02 +0000

As web developers, we get a lot of things for free: controlled environments, predictable inputs, and tight feedback loops. Testing, monitoring, and CI/CD pipelines help us catch and recover from failure quickly. But once code steps off the screen and into the physical world, you give up some control.

Check out my lightning talk at DotJS about how Code in the Physical World can get a little messy.

The good news? You don’t need to throw out your existing skillset to ride the wave of bringing AI into the physical world. The foundations you already have in web development translate more than you might think.

At Viam, we build open-source tools that connect software to hardware. That means robotics, IoT, and edge computing. It’s fun, powerful…and deeply humbling. Because no matter how clean your code is, reality doesn’t always play along.

Failure Looks Different in the Physical World

Compared to software development environments, physical environments face different challenges that result in different consequences.

Rivian pushed an OTA update that bricked 3% of their fleet, all because someone selected the wrong security certificate.
A Nest thermostat update crashed during a winter update rollout because no one accounted for unstable networks.
Facebook suffered a 6-hour global outage after a configuration change took down their internal tools and locked engineers out of data centers.

Unlike web apps, a failed update in physical systems can’t be fixed with a quick deploy. In the physical world, failure is a car that won’t start, a house without heat, or engineers with crowbars trying to get back into their own data centers.

And it’s not just human error:

Cables melt under AI inference loads when NVIDIA sourced power cables that were not well-rated for the intensive operations to support AI pipelines.
Sensors drift over time due to dust, aging, and other environmental factors, one reason why AirGradient recalibrates and smooths the detected values.
Connectivity is intermittent by design, like MQTT for oil pipelines and sea turtles tagged with satellite sensors to store and forward data upon surfacing when connection is re-established.

Buckley the sea turtle being tracked with a satellite tag

So What Can Developers Do?

We can’t count on eliminating failure altogether, but we can plan for it. Just like we design UIs for low-bandwidth conditions or fallback states, physical systems need graceful failure modes too.

Your phone doesn’t catch fire when it overheats, it throttles the CPU, dims the screen, and pauses charging. That’s a designed failure state.
NASA’s Voyager 1 is still running almost 50 years later without the ability to physically replace components. This is largely due to careful planning for failovers, redundancy, and managing tradeoffs.
Starlink satellites are designed to be safely decommissioned and burn up cleanly at end-of-life leaving no debris in space.

When you build for the physical world, failure is expected. The goal isn’t to prevent it, it’s to control how it happens.

Writing Code That Controls Hardware

You shouldn’t need to write firmware or low-level code to build real-world systems. That’s where projects like TC53 come in, standardizing JavaScript APIs for physical devices.

Even moreso, you don’t need to write code that runs on the device, you can write code that controls the device remotely. If you’ve worked with REST APIs, event handlers, or browser-based tools, transitioning from purely digital interfaces to code that interacts with hardware is more familiar than you might expect.

WebRTC: With browser-native APIs like WebRTC, you can control a physical device from your browser. No code needs to be deployed to the device itself.
Johnny-Five: This is a framework that lets you run Node.js on your laptop to talk to an Arduino board over serial like a remote control.
Viam: This is an open-source platform that abstracts away the finer details of integrating with drivers, networking, and security. So you can plug-and-play with modules to create your dream machines and then use the SDKs to build applications that control them.

The real lesson? Keep the logic where it's easy to test, debug, and update. In this way, we can leverage our existing skillset to control devices without needing to dive deep into low-level code.

The Shift Toward Embodied AI

We’ve had the fundamental technologies for quite a while - computer vision, robot vacuums, Mars rovers that execute pre-planned logic. So what’s different now to enable the wild growth in AI, beyond the world of software, and into the physical world?

What’s changed? Three key things have made embodied AI possible:

Low-cost, high-performance compute
Tooling and ecosystem to support deploying models and managing fleets
Enough training data to go from rule-based execution to on-the-fly learning

That unlocks a huge shift to enable systems that sense, act, adapt, and recover, just like people.

And we’re not just shipping to the cloud anymore. We’re shipping to physical devices:

Phones
Wearables
Cars
Drones
Robots

The boundary between code and the real world is disappearing. And that’s why this moment is so exciting for web developers. Web developers have a unique advantage here. The shift to client-side AI and edge compute means your skills are in demand in this new landscape.

Want to Try It Yourself?

Modern platforms like Viam make it possible to control real-world hardware using familiar tools like JavaScript, Python, and APIs.

If you're curious about working with real-world hardware using modern software tools, check out the Viam docs. You don’t need to be an embedded systems engineer, just someone who understands how systems interact and wants to see it move something in the real world.

Powering home automation with WebSocket APIs

Joyce Lin — Thu, 06 Jul 2023 15:08:43 +0000

In Part 1 of this series, we learned about the WebSocket protocol and how to set up our own WebSocket server in Node.js. Next, let’s explore how to use a public WebSocket API to access smart devices around a connected home.

REST and WebSockets for a connected home

When it comes to transmitting data in a connected home environment, both REST and WebSockets are commonly used protocols, but they have different characteristics and use cases.

REST follows a request-response pattern, where a client sends a request to a server, and the server responds with the requested data. This is useful for accessing and controlling smart devices and services, and works well for scenarios where data updates are not required in real-time. For example, you could use a REST API to turn on a smart light.

On the other hand, WebSockets enables bidirectional communication between a client and server, enabling real-time data transmission. This is useful for applications that require continuous data updates, such as real-time monitoring of sensor data and displaying live dashboards. For example, you could use a WebSocket API to continuously monitor the temperature in a room over a persistent connection.

In the next section, let’s take a look at a popular home automation platform that provides both REST and WebSocket APIs.

Home Assistant for home automation

Home Assistant is a popular open-source home automation platform that lets you control and monitor smart devices from different brands using a unified interface. Instead of using separate applications to control the kitchen lights, thermostat, and other connected devices all manufactured by different producers, you can manage almost everything from a single Home Assistant web dashboard running on a Raspberry Pi or other dedicated server within your local network.

Home Assistant progressive web application running at http://homeassistant.local:8123

Home Assistant is ideal for DIY smart-home tinkerers because it supports a wide range of integrations and protocols, allowing you to customize automation scenarios based on events, schedules, and sensor readings.

Next, let’s take a look at Home Assistant’s WebSocket API.

Home Assistant WebSocket API

In addition to a REST API , Home Assistant also contains a WebSocket API to stream information. To learn how to authenticate the WebSockets connection and send saved messages to the Home Assistant server, follow along with this step-by-step tutorial, watch the video, and reference the sample collection.

Using a long-lived token, you can use Postman to establish a connection with our Home Assistant server running locally, and then send and receive messages using the WebSocket API.

Receive a stream of information when the state changes on any device connected to Home Assistant

You can also configure your own Saved Messages to create your own customized themes and sequences.

Saved messages to replay common scenarios

Home Assistant also provides a REST API. Explore Home Assistant’s WebSocket and REST APIs side-by-side in Postman to better understand the differences between the two protocols.

Additional resources

You can work in Postman using different API patterns and protocols. Check out these Postman resources to learn more about WebSockets:

Browse the Program smart lights public workspace for APIs from other providers, such as Philips Hue and Elgato, to automatically control smart lights in your home or office. And let us know in the comments below what kind of projects you want to learn about, and what you’re doing with WebSockets.

The post Powering home automation with WebSocket APIs appeared first on Postman Blog.

Create Reusable Tests and Scripts with OpenAPI Reusable Components

Joyce Lin — Thu, 09 Feb 2023 18:34:11 +0000

In programming, “hacking” has historically meant making something do what it wasn’t originally intended to do, like using a whistle from a cereal box prize to play the tone into a pay phone to get free long distance calls. Today, it also refers to finding an inelegant solution to a problem. The word has gotten a bad rap, since it typically implies a nefarious or criminal activity. But many companies offer public APIs, empowering developers to stitch together their own customized solutions, even if the workarounds are a bit of a “hack.”

For example, if the user interface doesn’t accommodate a specific use case, and you can’t control which features get released and when, it’s time to get resourceful. APIs are an opportunity to create a workaround that suits you.

Alternative solutions for reusable tests and scripts

Postman users have asked if it’s possible to reuse tests and scripts. There isn’t a button or section in Postman that says, “Store your own reusable scripts here,” but there are many ways to accomplish this.

Some alternative solutions that might work for your particular circumstances are:

Creating collection-level or folder-level scripts to run with every request within the collection or folder.
Storing scripts in a global variable to use within the workspace.
Storing scripts in an environment variable to use alongside different collections.
Setting utility functions using any scope of Postman variables at the beginning of the collection, which can then be used throughout the collection.
Accessing your local file system for scripts saved on your machine.
Storing scripts within reusable components in an OpenAPI definition.

In this article, we’ll explore the last option in more detail.

Storing scripts within reusable components in OpenAPI

OpenAPI is the most popular API definition format that’s driving the API-first trend. Reusable components in OpenAPI are a powerful feature in designing and documenting an API. We won’t explore this capability now, but if you’re interested in learning more about it, check out an example of re-using an error schema.

In this article, we rely on reusable components to store our scripts and tests, and then use the Postman API to retrieve them when they’re needed.

Create scripts in OpenAPI reusable components and reference the scripts within a collection.

Create the script

Let’s save our script within a custom component in our API definition.

Create an API definition: In Postman, select APIs in the sidebar, and then select +. Enter a name for your new API, and continue without a repository. Create a new API definition for your API, and author the definition from scratch. Configure the definition as OpenAPI 3.0, YAML format, and check the option to Use a boilerplate (predefined template).
Create custom components: Within the generated file called index.yaml, scroll down to the section called components. Create a custom component under components that begins with an x- prefix. Add the name of your script, test, or any other data you want to store. Add a description that is the code you want to store as text for each component. See rows 38 to 49 in this example. Optionally, add a type or other metadata that is used to remind readers and yourself about this code.

Create custom components using an x- prefix.

Reference the script

Let’s retrieve the custom script and execute it in a request script.

Enable YAML parsing : Store the source code for this YAML parser for JavaScript in a global variable called yaml-js. In other words, copy and paste this code into the global variables editor:

Store source code of external library as a global variable so it can be used in a Postman script.

Then, under the Tests tab of the request, import yaml-js so that it can be used within the script:

Import yaml-js so it can be used within the script.

Retrieve the API definition : Use pm.sendRequest() to retrieve our API definition using the Postman API created in the previous steps. The example in the screenshot below shows the apiId and postman-api-key stored as collection variables.

Use pm.sendRequest() to retrieve the API definition.

Use the reusable components: Once we retrieve the reusable components from the API definition, we can use a function like eval() to evaluate JavaScript code represented as a string. Note : there is a big security risk in using eval(), so make sure you know what code you are running.

Confirm the scripts do what you expect, such as logging to the console, running a test, and incrementing an integer.

Try it out in Postman

Fork the collection to your own workspace by clicking the Run in Postman button

Fork the collection : Fork the example collection from above to your own workspace by clicking the “Run in Postman” button.
Create an API definition : Create a new boilerplate API definition in your own workspace, and make sure to include the code from Rows 38 to 49 as seen in this example.
Define variables : Add the ID for the API from the previous step and your Postman API key as collection variables. Store the source code for this YAML parser in a global variable called yaml-js.
Confirm scripts work as expected : Send the call Using a script to see the components in action.
Customize your own components: Update the API to customize your functions, or add new ones.

Assessing the workaround for your use case

What part of this solution works well?

You can organize a custom group of scripts using an x- prefix in the OpenAPI definition, such as for functions, tests, and other scripts.
The OpenAPI definition is in Postman already, so you can add, edit, and run the new code in Postman without switching context.
You can share these reusable components with team members in a team workspace.

What part of this solution does not work well?

This is not the intended purpose for reusable components in an OpenAPI definition.
The reusable components are not written in a text editor, so syntax highlighting and formatting of JavaScript is missing. It’s easier to copy and paste code into the API definition.
eval() poses a major security risk and the user can run malicious code or code with unintended consequences.

Does this satisfy your particular use case? If not, this was not the only way to solve this problem. For example, the YAML parser was saved as a global variable available within a workspace, but we could have also made a call to a CDN to retrieve the source code for the library. We also used the Postman API to retrieve an API definition containing our reusable components, but we could have accessed our local file system for saved scripts instead.

Feel free to explore some of the other alternatives listed above. And let us know some of your favorite hacks that you use in Postman in the comments below.

Technical review by Ian Douglas

The post Create Reusable Tests and Scripts with OpenAPI Reusable Components appeared first on Postman Blog.

Set Up a WebSockets Server in Node.js

Joyce Lin — Wed, 01 Feb 2023 15:54:45 +0000

The WebSocket protocol provides a way to exchange data between a client and server over a persistent connection. The data can be passed in both directions with low latency and overhead, and without breaking the connection. This means the server can independently send data to the client without the client having to request it, and vice versa.

WebSockets are great for building real-time functionality into web applications, such as games and chat apps, or for communicating financial trading data or IoT sensor data. More and more people are exploring WebSocket APIs in Postman. According to Postman’s 2022 State of the API report, WebSockets are used by 26% of respondents.

According to the Postman State of the API report, WebSockets are used by 26% of respondents.

In this tutorial, let’s create a WebSocket server, and use Postman to send and receive messages across the WebSocket connection.

Pre-requisites

To follow along with this tutorial, you’ll need the following:

Node.js installed on your machine
A text editor like VSCode installed on your machine

Create the Node.js server

In your terminal, make a new directory called websockets with the following command:

mkdir websockets

Then, navigate into the new directory:

cd websockets

Next, install ws, a WebSockets library for Node.js:

npm install ws

Installing the WebSockets library like this also initializes your Node.js project and creates a package where your project files are stored. Open the websockets directory using your preferred text editor, like VSCode. You should see the project files scaffolded as below:

One sub-directory and two files at the first level of the root directory.

Look inside the package.json file to see the ws dependency. Add the "type": "module" to the package.json so we can load an ES module in the next step. Your package.json should look like the following:

{
  "type": "module",
  "dependencies": {
    "ws": "^8.12.0"
  }
}

In the root directory, create a file called index.js and paste the following code from the ws documentation for a “Simple server.” This code initializes the WebSockets server. Upon establishing a connection between the client and this server (once running), the server will send the message “something” to the client:

import { WebSocketServer } from 'ws';

const wss = new WebSocketServer({ port: 8080 });

wss.on('connection', function connection(ws) {
  ws.on('message', function message(data) {
    console.log('received: %s', data);
  });

  ws.send('something');
});

It’s now time to run our server locally from the command line:

node index.js

Send and receive WebSocket messages

In Postman, select New > WebSocket Request to open a new tab. Enter the WebSocket server URL. A WebSocket URL begins with ws:// or wss:// and our server is running on localhost:8080. Click Connect.

Connect to local server and receive a WebSocket message.

Once Postman establishes the connection to your local server, the Messages pane will display a list of messages for the WebSocket connection, including incoming, outgoing, and network messages. You can further inspect the connection details by clicking on “Connected to ws://localhost:8080”.

Inspect handshake details.

The connection we established between the Postman client and local server is bidirectional, which means that in addition to receiving messages, we can also send them. Under the Message tab, write your own message and click Send.

If you have good reflexes, you may have seen your outgoing message in the Messages pane. If not, filter for the message using the controls or search bar in the Messages pane.

Filter or search for specific messages in the Messages pane.

Verify the outgoing message was received by your local server:

Send system information

Let’s update our WebSockets server to send something a little more interesting, like our computer’s information, using the systeminformation node package. Terminate the running server ( Ctrl + C ) and install the package from the command line:

npm install systeminformation

Next, import the package by adding the following code to the top of index.js:

import si from "systeminformation";

Add the following code immediately after our WebSocket connection sends the string “something”. Every 1,000 milliseconds, we will send a message about the current load on our CPU.

 setInterval(async () => {
    const cpuTemp = JSON.stringify(await si.currentLoad());
    ws.send(cpuTemp);
  }, 1000);

Save your changes, and restart the local server from the command line:

node index.js

Return to Postman and Connect to the local server. This time, we receive information about our CPU every second!

Local server sends CPU data every one second.

Click on a message to expand the message details and further inspect the data sent from our local server.

Expand message details.

The messages will keep coming until you terminate the connection. Use Postman to Disconnect from the server.

Now that we have a functioning WebSocket server, we can do more things.

Slow down the messages coming from the local server. Try updating 1000 milliseconds to 3000 milliseconds to see what happens.
Instead of sending all the data, try sending only the average load. You may want to inspect the messages in Postman to parse the data properly.

We can write more code to customize our local application. Upon receiving a message from the client, we can do more than logging the message to the console. We can also retrieve data from other sources and perform calculations before sending our messages to the client.

Additional resources

To follow along with this tutorial, watch the video and reference the documentation at Postman Quickstarts:

Check out these Postman resources to learn more about WebSockets:

In the next post, we will explore how to use our WebSockets server with Internet of Things (IoT) devices and do neat stuff around the home. Let us know in the comments below what kind of projects you want to learn more about, and what you’re doing with WebSockets.

Technical review by Ian Douglas.

The post Set Up a WebSockets Server in Node.js appeared first on Postman Blog.

From On-Premises to Cloud APIs: A Meta Example

Joyce Lin — Wed, 01 Jun 2022 16:12:20 +0000

Meta is the latest major tech player to recently announce broader developer access to their WhatsApp Cloud API. Meta owns several social media and messaging platforms including WhatsApp, Messenger, and Instagram. In addition to providing an app and an on-premises API, WhatsApp is opening access to their cloud API, previously limited to a group of partners in beta testing, in order to increase their market reach to include smaller companies.

API producers continue investing in cloud APIs. However, on-premises APIs are still widely prevalent, especially in some highly-regulated industries. For some behemoth enterprises still only dreaming about cloud solutions and companies embracing cloud-native trends, more investment in cloud APIs is welcome news.

Why is Meta, like so many other API providers, doing this?

What is an on-premises web API?

An on-premises web API is one that is deployed on infrastructure owned and managed by the consumer. For example, if you used the WhatsApp Business Platform on-premises API, you could choose to host it on a private server in your on-site data center behind your own firewalls.

Certain industries like artificial intelligence (AI) and electronic data interchange (EDI) frequently provide their solutions as on-premises APIs, even though most now offer cloud or hybrid solutions. And for API consumers, many large enterprises, especially those facing regulatory or compliance requirements, still choose to adopt on-premises APIs.

The following are notable features of on-premises APIs:

Provision and manage your own infrastructure
Control your own data for security regulations or compliance requirements
Administer your own software updates
Monitor and manage your own uptime
Manage your own certificates

What is a cloud web API?

A cloud API is one hosted by the API provider and deployed on infrastructure owned and managed by the API provider, instead of the consumer. For example, Meta’s cloud API is deployed on Meta’s infrastructure. The WhatsApp docs outline the differences between their on-premises and cloud APIs in more detail.

Check out the WhatsApp Business Platform public workspace

Adopting cloud APIs significantly reduces the barriers to entry, and speeds time to implementation for consumers. Developers can develop an integration in minutes, instead of weeks.

The following are notable features of cloud APIs:

Faster time to implementation
Scale up and down usage without incurring incremental infrastructure costs
Your anonymized and aggregated data may be used to improve the product (such as with refining machine learning models)
Usually no control over when updates are administered

Is cloud the future?

For every startup that adopts the latest technologies splashing the headlines, there are ten more well-established businesses that are maintaining legacy code and juggling industry regulations. For API providers, the decision is simple. It’s not a competition between cloud APIs and on-premises APIs. Providers, like Meta, will continue supporting both as long as consumers demand both.

https://blog.postman.com/wp-content/uploads/2022/05/2022-05-27-110738180.mp4

Let us know in the comments below if you observe these same trends within your industry.

The post From On-Premises to Cloud APIs: A Meta Example appeared first on Postman Blog.

How to Be Our Guest on the Postman Blog

Joyce Lin — Mon, 09 May 2022 16:53:08 +0000

When I want to learn how to do something in Postman, the internet is flooded with tutorials and videos from community members who want to share their knowledge with the rest of us. Postman has one of the most talented and generous communities in the world.

And you might already know that Postman has an open call for guest writers to contribute original articles. If you’re interested in writing for the Postman blog, check out the detailed submission guidelines for our guest blogger program here.

Read on for ideas and inspiration.

What should you write about?

Postman is looking for technical tutorials, thought leadership, and other educational resources to teach our community something new and discover what’s possible with APIs. This is an opportunity for developers of all experience levels to contribute to the Postman blog.

Here are examples of exemplary guest contributions.

How to Catch Breaking Changes Before They Happen by Allen Helton

This writer shares a personal anecdote about the SmartThings API releasing an update that breaks his home automation workflow. He recommends some ways to increase resilience, and shows how to set up your own monitor for breaking changes.

Shift-Left Testing: What It Is and How to Achieve It by Dan Martin

This writer introduces an industry trend called shift-left testing and tells a real-world example of a client shifting left. He talks about the struggles, requirements, and benefits of making this change for test automation.

Automate Your Reading List with a Typeform and Notion Integration by Nicolas Grenié

This writer walks step-by-step through how to set up an integration using his organization’s API and another public API and then suggests ways to go beyond the initial scenario. He also talks about dealing with recursion using a Postman script.

How Spritely Uses Postman to Create Health Tech for Retirees by Ryan Cornelius

This writer talks about an industry trend called Fast Healthcare Interoperability Resources (FHIR), the state of healthcare in New Zealand, and how his organization uses Postman to create the APIs empowering interconnected medical devices.

The topics that resonate best with the Postman community:

Show you how to build something
Introduce a technology or concept (or a fresh take on it)
Describe something interesting happening in an industry and why it’s important

Check out the guest blog submission guidelines for more information, and to submit an idea.

What should you NOT write about?

No sales pitches or overtly self-promotional content. If you’re excited about your company’s latest release or introducing a new public workspace, that is a stellar topic for your own blog or a social media post.

These topics are not acceptable for the Postman blog:

The first page of your developer docs
Why your technology is great
Non-original content, or a rehash of something you’ve already written on your own blog

While these are great topics for other channels, they’re not relevant for the Postman blog as stand-alone articles. If you think the Postman community wants to know about your ideas, tweet about it and tag Postman so we can help support it.

What if I don’t want to write for the Postman blog?

If you’re content to blog on your own or really like making videos and workshops, we’d love to hear about it! Let us know what you’re working on by tagging Postman on social media on Twitter or LinkedIn, or tell us in the comments below. And if you’re interested in a full-time job that involves writing or doing something else, Postman is always hiring.

The post How to Be Our Guest on the Postman Blog appeared first on Postman Blog.

Video Tutorial: Twilio’s Livestream API in Postman

Joyce Lin — Wed, 30 Mar 2022 16:54:48 +0000

During a recent Postman livestream with Twilio Principal Software Engineer Miguel Grinberg, we streamed about streaming using the just-released Twilio Live API to build our own interactive audio and video livestreaming experience. Most developers are familiar with Twilio’s SMS messaging API, but Twilio has a plethora of other communication APIs in their public workspace in Postman.

Miguel is well known in the Python community for authoring several books on Python and Flask. Fortunately for me, we decided to work with Node.js and in Postman. Miguel used his new favorite API to invite live viewers to join a separate livestream (without audio to avoid an echo), which inevitably led to a stream for mimes.

Watch what happened and hear straight from Miguel in this full video:

Check out a few highlights

Fork and deploy the example video application
Import OpenAPI specification in Postman
Create player streamer and media processor via API
Invite live viewers to join the Twilio livestream on Postman livestream

Follow along at home with these resources

Fork the example video application code from GitHub
Reference the Twilio Live APIfrom Postman (called “Twilio – Media”), or fork the Twilio Live collection generated from the specification

Don’t miss upcoming streams

Postman currently streams every week on Thursdays. Stop by and say hi, y’all. Follow or subscribe on any of these platforms so you never miss hearing about streams like this one:

YouTube: Subscribe to the Postman on YouTube and turn on your notifications
Twitch: Follow Postman on Twitch to receive notifications when we go live
Twitter: Follow Postman on Twitter to see when we go live
LinkedIn: Follow Postman on LinkedIn to be notified of upcoming events

The post Livestreaming with Twilio’s Livestream API appeared first on Postman Blog.

APIs to Automate Your DevOps Workflows

Joyce Lin — Wed, 16 Mar 2022 15:00:25 +0000

With the Public API Network offering APIs for nearly everything, this handpicked list is a group of popular APIs to automate your operations workflows. You can now make them part of your developer toolkit, and try them out by forking their collections to your own workspace to start exploring the possibilities. Learn about their tech, explore their APIs for free, and don’t forget about other Postman-featured APIs, workspaces, and collections in the network.

Docker has become synonymous with containers, which are used to simplify and automate the deployment process for applications. And Docker Hub is the world’s largest library of container images from software vendors, open source projects, and the community. See how you can create, manage, and deliver your container applications in this Docker Hub public workspace.
CircleCI is a continuous integration and delivery (CI/CD) platform. Fine tune your development processes with pipelines, jobs, and workflows using the CircleCI API to deliver quality code with confidence. Try it out in this CircleCI public workspace.
Humanitec empowers developers to build an internal developer platform. Improve your productivity by automating deployments, orchestrate infrastructure, and spin up environments. Or deploy a simple web application to a Kubernetes Cluster using the Humanitec API. Try it out in this Humanitec public workspace.
CloudBees is a DevOps technology platform to automate previously manual jobs with continuous integration and delivery. Their feature management API allows development teams to release, control, and measure features in any environment in the deployment pipeline. Try it out in this CloudBees public workspace.
Vultr is an infrastructure cloud provider to deploy cloud servers, bare metal, and storage. They are an API-first company, and their API is teeming with resources to build apps and automate infrastructure management without using a customer portal. Save time managing your infrastructure and check out their recently-launched Vultr Kubernetes Engine. Check out their API in this Vultr public workspace.
Oracle Cloud is a cloud computing service for enterprise applications. Their public workspaces are packed with extensive API references and helpful guides for scaling up your infrastructure. Splash around in their Kubernetes Playgroundfor Oracle Container Engine for Kubernetes (OKE). Or if you’re just getting started, check out the Oracle Cloud Infrastructure REST APIs public workspace.

We hope these free up your operations team by automating your tedious DevOps workflows. And if you have other automation APIs to recommend, let us know in the comments below.

Try Postman now

The post APIs to Automate Your DevOps Workflows appeared first on Postman Blog.

Build a Postman Alert for HackerNews

Joyce Lin — Mon, 14 Mar 2022 15:00:00 +0000

It’s every founder’s worst nightmare: your startup is going viral on HackerNews (HN), and you hear about it first from a customer, or worse yet, an investor. HackerNews is a message board known for its opinionated pundits stirring up discussions on everything related to technology. While it’s important to keep a pulse on the community, you may not have the resources or bandwidth to scour the interwebs for any mention of your company.

Let’s set up and customize your own Postman alert by cobbling together a few API calls and scheduling a cron job to run on Postman servers. In this example, we can watch HackerNews for any mention of our company, and then get notified on Discord.

A monitor is like a cron job running on Postman servers

Set up the alert

Fork the collection from this HackerNews public workspace by clicking the orange Run in Postman button below. If you also choose to “watch” the collection, you can get notified about updates when new API workflows are added to the collection.

Next, configure two parameters and schedule a monitor in your own workspace.

1. Set config : Under the Body tab of the “Set config” request, update the keyword to the name of your own startup. Then update the destination to your own discord webhook (or other type of webhook).

Set the keyword and destination parameters to configure the monitor

2. Schedule a monitor : Once you have the alert working locally like you want it, schedule a monitor to run this collection from Postman servers as frequently as every five minutes.

Schedule a monitor to run as frequently as every five minutes

And that’s it!

In the next section, let’s see what’s happening behind the scenes.

The API workflow

The API workflow to send an alert based on content in HackerNews stories

If you forked the collection, you can review the code under the Pre-request Script and Tests tabs for each API call. The API workflow utilizes the first four requests in the collection.

POST Set config : The first request “Set config” is a dummy request to httpbin. It requires setting two parameters that are saved as collection variables to be used in subsequent requests.
GET Get HN Top stories : This request queries the HN API to retrieve the top stories.
GET Get HN item by id : The third request queries the HN API to check each story retrieved in the previous step, looking for the keyword specified. Postman will continue to cycle on the current query until there are no more stories to check. If the keyword is detected, Postman moves on to the last request.
POST Send alert : This request is only triggered when the keyword is detected in the previous step, and issues an alert to Discord about the HN story containing the keyword. This request can also be updated to trigger alerts on other platforms.

Conditional logic under the Tests tab to send an alert only when keyword is detected

If you caught all of that, then you understand these fundamental concepts in Postman:

Collection: A collection is a group of requests. This is helpful for organizing your work and collaborating with teammates. But it’s also the foundational building block for more advanced features in Postman, such as executing a more complex API workflow.
Scripting: You can add JavaScript code to run before and after an API call as pre-request and test scripts, respectively. This is the basis of test assertions once you receive a response from the server. But also allows you to control your API workflows, and incorporate branching and looping logic, like we did in this example.
Monitor: A monitor is like a cron job running on Postman servers. Lots of people use them to monitor the health of their websites and APIs. But you can also use them to run any kind of API workflow on a scheduled cadence. Monitors are closely related to webhooks, which are actually monitors triggered by an event.

In addition to this HackerNews alert, browse other samples and documentation for the Official HN API in this public workspace. You can swap out HackerNews with other social media sites. Or you can swap out Discord for a different platform to receive a notification. And once you learn how to build one alert, you can build an army of them to be your eyes and ears across the Internet.

The post Build a Postman Alert for HackerNews appeared first on Postman Blog.

How to Build a Jamstack Application in Postman

Joyce Lin — Mon, 31 Jan 2022 17:40:03 +0000

Jamstack originally referenced a web architecture composed of JAM: JavaScript, APIs, and Markup. Websites could be delivered statically, such as serving HTML from static hosting, while providing dynamic content and an interactive experience through JavaScript and APIs.

A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup
—Mathias Biilmann, Co-Founder and CEO of Netlify

This type of architecture decouples the frontend from the backend. So instead of running on a backend web server, a Jamstack site typically deploys to a content delivery network (CDN) so web content can be delivered quickly from edge servers that are close to the end users and API endpoints can be hosted on serverless architecture.

Over the last few years, Jamstack has grown beyond just sites to serve static content, and it has led to a colorful debate about what constitutes Jamstack and even opinions about its capitalization. Regardless of your criteria, these static web apps are becoming very popular among hobbyists and global enterprises alike. And their growth is further driven by the booming API economy that can offer any variety of third-party services and turnkey solutions.

For developers who are new to Jamstack, let’s walk through a simplified example in Postman to see how each part of the JAM works.

4 steps to build a Jamstack application in Postman

The modular and decoupled nature of Jamstack architecture means there are a bunch of tools available to help you with each part of the implementation. For example, most Jamstack applications are developed using JavaScript web frameworks like Next.js and Gatsby. And then they’re deployed using services like Vercel and Netlify and hosted on a content delivery network (CDN).

Let’s build and host a simplified Jamstack application in Postman using code samples from the Postman documentation for the visualizer. And then we will take a closer look at the JAM.

1. Create a collection: In Postman, create a new collection named Jamstack. Then add a GET request to the collection named API call with the request URL {{url}}/data.

2. Add an example response: Select the overflow menu (…) of the request to add an example response (e.g.) called Example data. This example response is what will be returned from our mock server. Under the Body tab of the example response (on the bottom), select the JSON data type from the dropdown menu. Then add the following placeholder JSON. If you’re copying from the Postman documentation, make sure to remove the commented row beginning with // and preceding , character so that the JSON is valid.

[
    {
        "name": "Alice",
        "email": "alice@example.com"
    },
    {
        "name": "Jack",
        "email": "jack@example.com"
    }
]

Under the Headers tab of the example response (still on the bottom), add a header with a key Content-type and value application/json. Lastly, add a response status code of 200 OK.

3. Add a mock server: Select the overflow menu (…) of the collection Jamstack to add a new mock server called Mock data to the collection. Once Postman finishes creating a mock server, select the new environment created by Postman called Mock data. Hover on {{url}} in the request URL to see the value being read from the actively-selected environment.

4. Visualize the data: Select the request API call, and send the request to see the example data returning from the mock server. To update the data returned from the mock server, you can edit the example response body (e.g.). We will continue using code samples from the Postman documentation for the visualizer. Under the Tests tab, add the following code for an HTML table represented as a template string.

var template = `
    <table bgcolor="#FFFFFF">
        <tr>
            <th>Name</th>
            <th>Email</th>
        </tr>
        {{#each response}}
            <tr>
                <td>{{name}}</td>
                <td>{{email}}</td>
            </tr>
        {{/each}}
    </table>
`;

And then add the following code to pass the response data to render in the template string and instantiate the visualization.

// Set visualizer
pm.visualizer.set(template, {
    // Pass the response body parsed as JSON as `data`
    response: pm.response.json()
});

Save your changes. And then send the call, and toggle over to the Visualize tab of the response to see our table.

Watch and learn

If you want to skip ahead to the finished product, fork this example collection and environment to your own workspace.

In the next section, let’s dissect the JAM in this example, and think about ways to enhance each component.

A closer look at the JAM

JavaScript
The visualization is instantiated using the pm.visualizer.set() function invoked in a test script. The Postman sandbox provides access to other JavaScript functions and libraries that can be used in pre-request or test scripts. Furthermore, external CDN libraries can be imported using a function like pm.sendRequest() among other ways of using external libraries.

APIs
We stored our data using a mock server hosted on Postman cloud, accessing the data with a call to our mock API. This allows us to quickly edit the data and “deploy” our updates by saving our changes to Postman. If we find a third-party service we like, or create our own custom API, we can swap out the API to call. In fact, we can call as many APIs as we wish, synthesize the data and perform calculations to create our own custom services.

Markup
We visualized an HTML template string that can be styled with CSS. You can also use Handlebars templating language to generate HTML. If you don’t feel like writing your own Markup, search for other visualizations created by other members of the Postman community. And once again, external CDN libraries can be imported, this time using script tags within the template string.

Extend this to production-level applications

We did it! It is possible to develop, deploy, and host a complete Jamstack application in Postman. But this was a simplified example. At some point, you may choose to swap out your mock data with a third-party service or your own API hosted on serverless architecture. Or you may decide not to visualize the HTML in Postman, but in a web browser instead. There are a bunch of tools, technologies, and workflows to support your Jamstack applications.

The Jamstack architecture lets you get creative with your implementation. JavaScript and APIs allow you to pull data dynamically with interactivity limited only by your imagination. And the thriving API economy means your options for this dynamic behavior are growing fast.