Comparison
We compare by category of tool, not against named products. A vendor who names a competitor also picks the criteria; we would rather give you the criteria and let you name the product.
This page contains no performance figure, in any column — neither ours nor anyone else’s. The numbers that decide an integration are the ones measured on your traffic, with your real messages.
A classic on-premise ESB suite
Where we fit
An integration is a text file, published as a compiled artifact: its structure, names, templates, transforms and SOAP version are checked at publication rather than discovered at runtime. An installation is the program and a state directory: it scales by starting the program again against the same directory, coordinated by file locks, with no orchestrator, no consensus service and no cluster with operators of its own.
Where the suite is better
A wide ecosystem of ready-made connectors. Graphical schema-mapping tools. Automatic failover between nodes, with cluster administration tooling around it. A market of specialists you can hire.
Cloud iPaaS
Where we fit
The platform runs where you put it, with the data staying there. The contract is commercial, and what runs is a binary you control. The gate is closed by default and runs before the message body.
Where iPaaS is better
Nothing to operate: no boot, no backups, no migrations. A large catalogue of connectors to commercial services. Scale you buy rather than build.
Hand-written integration code
Where we fit
Deduplication, correlation with a mandatory deadline, retry with its own write-ahead log and the response contract belong to the platform and are not rewritten per integration. The measured unit is the delivery, and its verdict is a column, not a team convention.
Where the code is better
No limits but the language’s own: whatever the team can write, it can build. Debugging with the tools the team already has. No licence to buy.
A message broker plus your own code
Where we fit
Translation and routing are declared in the flow and checked at publication; guards refuse or filter a message at run time. All four inbound doors enter through the same delivery bracket, so deduplication and correlation are decided in one place, not rewritten per door.
Where the broker is better
Delivery and ordering guarantees of its own, with prioritisation and reordering. A large ecosystem, familiar operations, and horizontal scale.
An API gateway
Where we fit
The door is closed by default and authenticates before the body is read, with throughput bounded per credential; a SOAP request goes through the same gate. Behind the door, NexusFabric transforms the message, routes it and queues it with retry, and what the journal counts is the delivery.
Where the gateway is better
Developer portals, API catalogues and a wide ecosystem of plugins.
An assembled open-source stack
Such a stack joins a gateway, an integration framework, an identity server, a broker, a search cluster and a database: each with its own runtime, high availability and upgrade cycle.
Where we fit
The front door, transformation and routing, a persistent queue and the message journal, with a management UI, in one program. It validates the tokens your identity provider issues. More capacity is the same program started again on shared storage.
Where the stack is better
Each part scales and is replaced on its own. Replicated queues. Full-text search over the logs. An identity server that issues tokens.
Choose the category that fits
Set these categories beside your project. If NexusFabric is the one that fits, bring us one integration you run today and we walk through it with you.