Comparison
How the ocpp-ws-io ecosystem approaches common EV scalability challenges differently from other Node.js libraries.
Comparison with Alternatives
Building a scalable OCPP Central System (CSMS) or Station Client involves navigating multiple architectural trade-offs: memory management, horizontal clustering, smart charging mathematics, and protocol translation.
The ocpp-ws-io ecosystem isn't the only option. Here's how our ecosystem approach fundamentally differs from other popular Node.js OCPP libraries.
A note on honesty: Our ecosystem is newer and has a smaller user base compared to the alternatives listed below. It has been tested primarily in controlled environments and small-scale deployments — not yet at the scale of libraries with years of community adoption.
The comparisons below are based on our reading of each library's public source code and documentation. If anything is inaccurate, please open an issue.
1. Ecosystem Scope vs. Isolated Libraries
Most open-source packages in the Node.js EV charging space supply only the WebSocket RPC parsing layer. Everything else is left as an exercise for the developer.
What ocpp-ws-io ecosystem addresses differently: We recognized that parsing JSON is only 10% of the battle.
- Smart Charging: No other mainstream Node.js library ships with a mathematical load-balancer constraint solver. When you use the
ocpp-smart-charge-engine, you avoid rolling your own power distribution algorithms. - Protocol Proxying: Transitioning from OCPP 1.6 to 2.1 usually breaks everything. Unique to our ecosystem,
ocpp-protocol-proxyallows you to invisibly patch the gap by translating the payloads live on the wire. - Diagnostics: While other libraries require you to connect real hardware, the
ocpp-ws-cligives you a suite of fuzzers, load-testers, and interactive terminal simulators.
2. @voltbras/ts-ocpp
@voltbras/ts-ocpp is a popular, strongly typed, TypeScript-first OCPP library.
Where they excel:
- Excellent out-of-the-box TypeScript types.
- Simple class-based OOP API design.
- Larger community and more mature adoption.
What our Core RPC (ocpp-ws-io) addresses differently:
- Clustering:
ts-ocppstores connections in memory class instances. When scaling across multiple pods behind a load balancer, tracking stations requires custom pub/sub broker code.ocpp-ws-ionatively provides aRedisAdapterfor seamless unicast routing across multi-node kubernetes clusters. - Rate Limiting: We include socket-level token bucket rate limiters that can drop high-frequency DDoS metrics (e.g.,
MeterValues) before parsing, preserving CPU capacity. - Path-based Routing:
ts-ocpprelies heavily on single class handlers.ocpp-ws-iooffers Express-style path routing (OCPPRouter) to safely ringfence middleware and authentication (/api/v1vs/api/v2).
3. ocpp-eliftech
ocpp-eliftech is one of the oldest JavaScript/Node packages for OCPP implementation.
Where they excel:
- Longest track record — it has been used in production for years.
- Complete implementation of OCPP 1.6-J.
- Minimal and unopinionated design.
What our ecosystem addresses differently:
- Modern Protocol Focus:
eliftechis tied to OCPP 1.6. The ocpp-ws-io ecosystem has native, deeply validated auto-generated schema typings for OCPP 2.0.1 and OCPP 2.1. - Schema Validation:
ocpp-ws-ioimplements incredibly rigorous JSON schema validation using AJV, smartly transforming malformed packets straight into valid OCPP-J error framing (FormatViolation). - Idempotency Keys: To prevent duplicate database processing on unstable cell networks, our RPC layer supports deterministic message IDs.
4. rpc-websockets / Generic RPC implementations
While not an OCPP library, many teams pipe raw WebSocket JSON-RPC through generic libraries like rpc-websockets and manually structure their payloads.
Where they excel:
- Extremely lightweight and highly flexible.
- No OCPP-specific constraints imposed on the developer.
What our ecosystem addresses differently:
- Protocol Awareness:
rpc-websocketsdoesn't understand the semantic differences between aCallError(Type [4]) and a generic socket fault.ocpp-ws-ioenforces the official OCPP-J messaging sequence meticulously. - Mandatory Correlation: Generic RPC libraries allow fire-and-forget logic. OCPP fundamentally requires every action to be strictly correlated with a
CallResult. We enforce this at compile-time while explicitly supporting the rareNOREPLYopt-outs.
5. Horizontal Scalability Philosophy
When moving from a local .env setup to a 5,000+ EVSE Kubernetes cluster, the architecture of your socket broker matters.
| Concern | Typical In-Memory Libraries | ocpp-ws-io ecosystem / Core RPC |
|---|---|---|
| Multi-Node Routing | Manual implementation required | Native Redis presence registry with O(1) routing |
| Connection Rehydration | Connections lost on restart | Eager Redis presence re-registration on exponential reconnect backoffs |
| Surge Handling (Thundering Herd) | No built-in protection | Randomized ±25% ping jitter + strict token bucket throttling |
When to Use What
| Your Situation | Recommended Choice |
|---|---|
| Simple single-instance OCPP 1.6 app, rely on vast mature community | @voltbras/ts-ocpp or ocpp-eliftech |
| Building an interconnected OCPP 2.1 platform from scratch | The ocpp-ws-io ecosystem |
| You need to load balance multiple cars on a single breaker | ocpp-smart-charge-engine |
| Upgrading backend software but stuck with legacy 1.6 hardware | ocpp-protocol-proxy |
The ocpp-ws-io ecosystem is an open-source tool suite built to solve specific infrastructure problems. If those problems aren't yours, the other libraries listed here are highly capable choices.