Lesson 1 · Node.js on IBM i — From RPG Developer to Modern IBM i Developer

Why Should an RPG Developer Care About Node.js?

Learn where Node.js fits on IBM i, why it complements RPG, and when it can make APIs, JSON, and integrations easier.

Saurabh Arora

IBM i Solution Architect | Technical Lead | Modernization & Integration Specialist

Published September 4, 20265 min read

Node.js gives RPG developers a practical way to build modern interfaces around proven IBM i business logic without replacing the applications that already work.

If you already have RPG, SQL, and Db2 for i, asking why you need another language is reasonable.

RPG remains excellent at business rules, transaction processing, and the work your applications have handled reliably for years.

Node.js solves a different problem.

It is especially useful at the edges of an application, where IBM i needs to communicate with web applications, mobile apps, partner systems, cloud services, and modern APIs.

This is not a choice between RPG and Node.js. It is a question of where each one adds the most value.

Start with the architecture, not the language

A useful way to think about Node.js on IBM i is as an application interface layer.

Web / Mobile / Partner / Cloud
              ↓
          Node.js API
              ↓
      RPG Business Logic
              ↓
           Db2 for i

In this design:

• Node.js handles HTTP requests, JSON, and external integrations.
• RPG continues to handle established business rules.
• Db2 for i remains the system of record.

That lets you create a modern interface without moving the database or rewriting years of tested logic.

Node.js should complement RPG, not replace it. Put Node.js where a modern interface helps, and keep proven business logic where it already belongs.

Where Node.js adds value

Node.js is a server-side JavaScript runtime. It is designed around asynchronous, event-driven work and is a natural fit for applications that spend much of their time waiting for network or other input/output operations.

For an IBM i developer, that makes it useful in several practical areas.

REST APIs

Modern applications often communicate through HTTP APIs.

A Node.js service can receive a request, validate it, call existing IBM i logic, and return a JSON response.

Conceptually:

GET /customers/12345
        ↓
Node.js validates the request
        ↓
Existing RPG or SQL retrieves the customer
        ↓
Node.js returns JSON

Node.js does not need to own the customer rules. It can provide the HTTP interface around them.

JSON-heavy integrations

RPG can work with JSON, but Node.js treats JavaScript objects and JSON as everyday data structures.

For example, data returned to a web application may look like this:

{
  "customerNumber": 12345,
  "name": "Northwind Supply",
  "status": "ACTIVE"
}

When an integration involves many JSON requests and responses, Node.js can keep the interface code straightforward while RPG remains focused on business processing.

Web backends

A browser should not connect directly to Db2 for i or call sensitive business logic without a controlled application layer.

Node.js can provide that layer by handling:

• routes
• request validation
• authentication and authorization
• response formatting
• calls to RPG, SQL, or other services

This creates a clear boundary between the user interface and the IBM i application.

Cloud and SaaS integration

Many external services provide JavaScript examples and Node.js libraries for their APIs.

Node.js can be useful when IBM i needs to exchange data with services for payments, shipping, messaging, identity, document processing, or other cloud-based work.

The integration layer can change as an external API changes without forcing the core RPG business rules to change with it.

Asynchronous and event-driven work

Node.js is well suited to work that involves waiting for events or network responses.

Examples include:

• receiving a webhook
• calling several remote APIs
• processing messages from a queue
• streaming a response
• coordinating background integration tasks

This does not mean Node.js is automatically the best tool for every workload. CPU-heavy or long-running business processing may still belong in RPG, SQL, a batch job, or another suitable service.

The npm ecosystem

Node.js includes access to npm, an ecosystem of reusable packages.

Packages can help with common needs such as:

• HTTP servers and clients
• input validation
• authentication
• logging
• testing
• working with common data formats

That can reduce the amount of general-purpose integration code your team must build itself.

It also creates a responsibility: every dependency should be reviewed, maintained, updated, and treated as part of the application’s security surface.

A small example

You do not need to understand all the JavaScript yet. This example only shows the shape of a Node.js interface:

const customer = {
  customerNumber: 12345,
  name: 'Northwind Supply',
  status: 'ACTIVE'
};

console.log(JSON.stringify(customer));

The program creates a JavaScript object and converts it to JSON.

Later in this series, the values could come from Db2 for i or existing RPG business logic, and an API could return the JSON to a caller.

For now, the important point is that Node.js is comfortable working with the kind of data modern application interfaces exchange every day.

What Node.js does NOT mean

❌ Rewrite your RPG applications
❌ Move your database elsewhere
❌ Abandon IBM i
❌ Replace every existing interface

Introducing Node.js can be incremental.

You might start with one API, one partner integration, or one web backend while leaving the rest of the application unchanged.

Existing RPG + Db2
        +
Node.js where it adds value
        =
Modern IBM i application

When Node.js may be the wrong choice

Do not add Node.js only because it is newer or popular.

If an RPG program, SQL procedure, IBM i service, or existing interface already solves the problem clearly and safely, another layer may add complexity without adding value.

Start with the problem:

• Do we need to expose business capabilities through a REST API?
• Are we spending too much effort translating JSON?
• Do we need to integrate with web or cloud services?
• Would a separate interface layer make the application easier to change?

If the answer is no, Node.js may not be the next practical step.

A sensible starting point

RPG and Node.js are not competitors.

RPG can remain the home of trusted business logic. Db2 for i can remain the system of record. Node.js can make that logic easier to expose to modern applications and services.

Keep what works. Add Node.js where APIs, JSON, web applications, or integrations need it.

In the next lesson, we will explain PASE in IBM i terms and show where Node.js actually runs on the system.