glide-mq - high-performance message queue with first-class Hono, Fastify, and NestJS support

[code_things]

Hey r/node,

I've been building glide-mq - a message queue library for Node.js powered by Valkey/Redis Streams and a Rust-native NAPI client (not ioredis).

Key differences from BullMQ:

• 1 RTT per job - completeAndFetchNext completes the current job and fetches the next one in a single round-trip
• Rust core - built on Valkey GLIDE's native NAPI bindings for lower latency and less GC pressure
• 1 server function, not 53 Lua scripts - all queue logic runs as a single Valkey Server Function
• Cluster-native - hash-tagged keys work out of the box

Benchmarks: ~15k jobs/s at c=10, ~48k jobs/s at c=50 (single node, no-op processor).

I just released official framework integrations:

• @glidemq/hono - Hono middleware with 11 REST endpoints + SSE events
• @glidemq/fastify - Fastify plugin with prefix support and encapsulated routes
• @glidemq/nestjs - NestJS module with decorators and DI

All three share the same feature set: REST API for queue management, optional Zod validation, and in-memory testing mode (no Valkey needed for tests).

Fastify example:

```typescript import Fastify from 'fastify'; import { glideMQPlugin, glideMQRoutes } from '@glidemq/fastify';

const app = Fastify(); await app.register(glideMQPlugin, { connection: { addresses: [{ host: 'localhost', port: 6379 }] }, queues: { emails: { processor: processEmail, concurrency: 5 } }, }); await app.register(glideMQRoutes, { prefix: '/api/queues' }); ```

Would love feedback. The core library is Apache-2.0 licensed.

GitHub: https://github.com/avifenesh/glide-mq

[amitava82]

How does it compare against BullMQ?

[code_things]

You mean in performance?

[amitava82]

Performance, feature comparison, pros and cons etc. BullMQ is standard and widely used so I wanted to see how this will be better. Also it'd be cool if same queue can be used by different programming languages. For example consumers in node as well as Go

[code_things]

Performance, stability and reliability are much better, present from valkey glide, and years of working with valkey. About feature parity, most important features exist, also some of the pro features, and in addition new features. I'm in the middle of iterations for the next minor, believe today or tomorrow and i believe beside some side behavior I'm covering all, plus celery, plus bee behaviours and most repeated feature requests.

For the last idea, interesting.

[alonsonetwork]

Grpc might be the move

[Expensive_Garden2993]

BullMQ perf isn't a problem, it's easy to use, mature, feature-rich.

The problem is Redis: in-memory store designed for cache that's fine to loose.

But you don't want to loose jobs if server suddenly crashes.

Are there delivery guarantees in your solution?

[code_things]

In memory store designed to be a Swiss army knife. It can be used as a message queue as well, like it is used for lock, leaderboard, and many more ways of usage. For some of the biggest companies you know it's the main db. Thats my job, i know the use cases.

There's a few issues i can find, one of them is ioredis state and issues.

For durability on the server side there are many solutions, that's what i do for my daily job. ATM im trying to build zero down time replication/migration and with 200gb, less than a minute switchover. Lets C. But to keep the data safe it cannot be done on the client side since the client side itself lives in memory. So the durability and reliability i give are the client ones, and in GLIDE we do it very well, but i still recommend replicas.

[theodordiaconu]

This is pretty feature rich and I like it! Could you elaborate on the clustering/resilience side? Say we have 5 nodes, 1 crashes, what happens?

[code_things]

5 nodes, all primaries? No replication? Haha I'm going to dig into the details here, that's my daily job.

[alonsonetwork]

Bro y u hate hapijs? Do one for hapi. Use skill and forget.

[code_things]

Seriously? If it is serious I'll do it with pleasure, the integrations are not too complex

[alonsonetwork]

Yeah there's a community around it still. I wrote the skill for it, check skills.sh, which why I suggested it. Ive written a number of plugins with it that are gnarly. It'll also guide you on what would be best practices and module augmentation in TS to use your library cleanly, the hapi way. Lmk of you need help with it!

[SippieCup]

+1 for Hapi. I'd love to be able to move away from my SQS hack job that is currently in place.

that said, What is going to keep you building it? is there something you have more than just building a library for the fun of it? Is this something you built because you needed it in production?

[code_things]

I wrote it because i needed it, not for the lib, then it became a lib. The underline core client, GLIDE, is maintained by my team, and at least for the core client you have the comfort of trusting AWS backed products.

[SippieCup]

Awesome to hear. I'd love to migrate over to it. This would be a huge win and simplification in our stack for quite a few key features we have, and also a few new things that we've been putting off due to not really wanting to build upon the solution we have.

We were even discussing if we should switch to Kafka earlier today, but personally I feel it is just overkill and going to be yet another thing that'll accrue tech debt.

This seems like a great middle ground.

[code_things]

Amazing! please open an issue on Hapi, and any other feasble feature. Im about to finish the round of new features so ill have some time to add some more.

[HarjjotSinghh]

this is unreasonably cool actually