Protocol Agnostic Framework

Hey everyone!

After a lot of R&D, multiple design iterations, and endless hours of experimentation, I’m super excited to share some big updates on Gland. Over the past few weeks, I’ve been hard at work refactoring and rethinking the core of the framework—and now I can confidently say:

Gland is now fully protocol-agnostic and 100% event-driven.

Inspired by architectures like NestJS and Angular, Gland takes the idea of dependency injection and modularity one step further—with a twist that makes it different from anything else out there.

In my previous post, I introduced Gland and talked about its event-driven nature. Back then, Gland was already lightweight, minimal, and built with almost no external dependencies. But even so, it still had a tight coupling to HTTP.

That changes now.

So, what’s new?

Protocol Agnosticism

One of the biggest milestones in Gland’s journey so far: The framework is no longer tied to HTTP at all.

The @glandjs/core package has been completely redesigned to be totally independent of any transport layer or protocol—whether it’s HTTP, WebSocket, RPC, MQTT, or something else.

Introducing Broker Adapters

I’ve introduced a new concept called Broker Adapters—they serve as bridges between your protocol of choice and Gland’s event system. Want to use HTTP? Create an adapter for it. Looking to work with WebSocket, Fastify, or MQTT? Just build an adapter for your needs.

Right now, there’s a working adapter for Express via @glandjs/express. Up next is support for Fastify, followed by additional protocols like WebSocket and MQTT.

HTTP Abstraction Layer

The old @glandjs/http package has been split and abstracted. It no longer implements a specific HTTP server—instead, it provides the decorators and structure (such as @Get(), @Post(), etc.). The actual server implementation now lives in protocol-specific adapters like Express or Fastify.

Still 100% Event-Driven (EDS)

Gland remains completely based on an Event-Driven System (EDS). That means everything—from controller calls to the internal logic—is handled through events, not direct method calls. This architecture makes the framework immensely modular, scalable, and flexible.

Here’s an updated and working example using Express:

import { Controller, Module } from '@glandjs/common'
import { Get } from '@glandjs/http'
import { GlandFactory } from '@glandjs/core'
import { ExpressBroker, type ExpressContext } from '@glandjs/express'

@Controller('/')
class UserController {
  @Get()
  index(ctx: ExpressContext) {
    ctx.res.send('Hello World')
  }
}

@Module({
  controllers: [UserController],
})
class AppModule {}

async function bootstrap() {
  const app = await GlandFactory.create(AppModule)
  const express = app.connectTo(ExpressBroker) // completely type-safety.
  express.listen(3000)
}
bootstrap()

With this setup, you can use Gland with any protocol simply by plugging in the appropriate adapter. Express works today, Fastify is coming next, then WebSocket, and beyond—whatever you need!

What does this mean for Gland’s future?

Gland is now about 80% feature-complete in terms of its architectural vision. The remaining work focuses on:

• Polishing the APIs
• Stabilizing the event system
• Finalizing integrations with more protocols
• Building comprehensive documentation

The core pillars—DI, modular architecture, protocol independence, and an event-based flow—are now rock solid. And yes, you can totally consider using Gland in production if its approach fits your use case. The aim is to offer a minimal yet powerful toolset that evolves as you do.

What’s Next?

• Fastify support – Already in the works
• WebSocket adapter – Planned after Fastify
• Docs + Website – Being built with Astro and GitHub Pages
• Testing and Stabilization – Ensuring Gland is more battle-tested for production scenarios

Let’s Discuss & Contribute!

I’m really excited about this new phase of Gland and would love to hear your thoughts.

• Do you find the protocol-agnostic approach as compelling as I do?
• What potential challenges do you foresee in an event-driven system like this?
• How would you like to contribute—whether in code, documentation, or feedback?

If you’re as passionate about modular, protocol-free, event-driven architectures as I am, please join the conversation and help shape the future of Gland.

• Star the repo: github.com/glandjs/gland
• Join our Discord community: Discord Server
• Contribute docs, adapters, or examples: Your ideas and PRs are always welcome!
• Check out our in-progress docs: github.com/glandjs/docs

The document is not ready yet, but I am looking for a good structure and then I will pursue creating the document and writing its content.

I’d really love to get your detailed feedback on these changes, and I’m eager to discuss how we can improve Gland together. Let’s start a conversation—what are your thoughts about this new direction? Have you encountered any interesting challenges or opportunities in event-driven design that you’d like to share?

Comments

[Jon Randy 🎖️]

Might want to rethink the name??!?

[Genix]

Interesting! Why do you think the name needs a rethink? Got a better one in mind?

I picked Gland because it's short, unique, and kind of symbolic—like glands in the body, it connects, triggers, and manages flow behind the scenes. But open to ideas if something clicks better!

[David Mintz]

If you can come up with a good acryonym, then there's your excuse for sticking with Gland.

[Genix]

Yes, I’ve thought about that too. The closest I’ve come up with so far is:

G.L.A.N.D = Generalized Layered Architecture for Node-based Development

It's still unofficial. It may change...

[Jon Randy 🎖️]

"Gland" is a euphemism for an intimate male body part!

[Genix]

LMAO okay I definitely did not see that one coming 😅

I picked "Gland" thinking of biology—something small, modular, and responsible for big flows behind the scenes... not that kind of flow

The Urban Dictionary definition isn’t something I’d normally consider, but if it becomes a major issue, I might change it—though I think it's a little late for that already.

[Jon Randy 🎖️]

youtu.be/edESzn4JcGo?t=40

[Genix]

😂😂😂😂😂😂😂 You just kicked off an epic day for me :))))))

[Jefferson Chidiox]

You said that it might already be too late. Why?

[Jastria Rahmat]

yes, i agree, before it stone carved.

[imonem]

Read the comments about the gland name.

The below suggestions might help you get around the blank page syndrome:
MXCore M Times Core multipurpose
Jux short for juxtaposition
Arcanic derived from Arcane

Good luck

[Genix]

I know the name "Gland" is a bit strange and may not appeal to some.
The story behind the name is that I was thinking of systems that, like glands in the body, send a signal (event) and the rest of the system reacts to it — since Gland is also completely event-driven, I felt like it would fit.

But now that I've gotten more feedback, I think a review might be in order (given the context). Those names you suggested were really interesting, especially Jux and Arcanic, they have a really good vibe. Maybe we'll do a rebrand in the next versions.

For now, I'm focused on building a strong and flexible core, but I'll definitely keep this in mind. Thanks again for saying so ❤️

[Yusuf Al-Aziz]

Enzime?

[Jastria Rahmat]

Nerva – nerves transmit signals, elegant metaphor
Plexo – short for plexus, a nerve network
Cerebra – brain core, subtle power center
Neura – clean and connects with neurons
Fluxel – from flux (flow) + cell
Ventra – feels like “vent” and “center”
Omnix – all + system
etc..

[B Maj]

100% agree - no matter how great the framework is, a name like Gland is going to turn some people off.

[jkanethird]

The name is fine. It's short, unique, and unlikely to ever conflict with any other libraries/frameworks/software solutions. I have a pet peeve for names that are essentially acrostic poems.

[Daniel T Sasser II]

Definitely lightweight 😁
It only took me about 10 minutes to skim the whole codebase.

I saw you introduced Broker Adapters as a way to decouple the transport layer from the core logic.
Did that shift come from experience hitting limitations or complexity in frameworks like NestJS or Angular?
I’m currently using NestJS to build complex e-commerce APIs, so this definitely caught my eye.

[Genix]

Great question! The shift toward Broker Adapters in Gland isn’t just about avoiding limitations in NestJS or Angular—it’s about a design philosophy that emphasizes pure modularity and decoupling. With Gland, the idea is to have an architecture that's truly transport-agnostic. Unlike NestJS, which tightly couples with HTTP and Express, Gland lets you plug in any protocol (or even multiple protocols) without rewriting your core logic.

For example, with Gland’s event-driven architecture, you can have a controller emit an event that’s then handled by a dedicated channel. This decouples your business logic from the transport layer. Here's a quick example:

---

@Controller('users')
class UserController {
  @Get('/')
  createUser(ctx: HttpContext) {
    const data = { /* user data */ };
    // Emit an event, not a direct response
    ctx.emit('user:created', { data, ctx });
  }
}

@Channel('users')
class UserChannel {
  @On('user:created')
  async handleUserCreated(payload: { ctx: HttpContext; data: any }) {
    // Some processing can happen here before sending response
    ctx.emit('@response:send', { ctx, body: payload.data });
  }
}

@Channel('response')
class ResponseChannel {
  @On('send')
  handleResponse({ ctx, body }: { ctx: HttpContext; body: any }) {
    // Centralize how responses are sent back to the client
    ctx.send(body);
  }
}

@Module({
  channels: [UserChannel, ResponseChannel],
  controllers: [UserController],
})
class UserModule {}

@Module({
  imports: [UserModule],
})
class AppModule {}

---

In this setup, you can send a request to the users route and then handle the response through a dedicated response channel—meaning any module can access and contribute to the response simply by tapping into the @response event. This decoupled, event-driven approach makes your code easier to scale and maintain.

My goal with Gland is to create a framework that’s as flexible and adaptable as possible—providing not just an architectural blueprint like NestJS but extending it to be protocol- and eventually even language-agnostic.

[nadeem zia]

Interesting to read

[Nikolay Konovalov]

This is actually something I’ve been looking at for a while and was planning to build it myself. I discovered this article via Google Chrome mobile starting page 🤯

The use case is a project about connecting as many integrations and services within one AI platform. Pretty much I’m thinking about making an assistant that have as much access to things as you do.

Think Slack, Jira, YouTube, Hacker News, e-mail, GitHub, your phone, crypto wallet, web camera, everything!
And every single thing is running on top of some protocol.

So the very first problem is how to standardize interactions between all those things and I came to conclusion that at the core of it we need to use microservices that solve just one specific problem/domain. Every microservice can communicate via REST, websockets, or use pub/sub. However, the problem is amount of boilerplate we need to write, so every microservice needs an SDK that solves the boilerplate problem.

One specific problem I see is that I don’t to limit myself only to JavaScript or Python or even Ruby even though I’d write everything in one 🙂

So my question is whether we can also have SDKs to this framework from popular languages?

Overall, thank you for making the prototype, I’d definitely look into the code and maybe it could help with my use case 🙇

[Genix]

This cross-language communication goal is exactly what I'm aiming for with Gland. My vision is to build a framework that's not only protocol-agnostic but eventually language-agnostic as well—much like BMW’s joynr project (github.com/bmwcarit/joynr). The plan is to transform Gland into a tool where, thanks to its event-driven architecture, every component can interact seamlessly regardless of the underlying protocol or language.

Right now, my primary focus is on nailing down the core functionality. This means improving broker-to-broker communication and refining how adapters work take for instance the integration between @glandjs/express and the core. These are the foundational steps we need to stabilize before jumping into broader cross-language support. There's a lot to do here, like enhancing internal APIs and ensuring smooth interactions between different parts of the framework.

Once the core is rock solid, the ambitious goal of cross-language support will be more attainable. Imagine building microservices in different languages JavaScript, Python, Ruby all communicating effortlessly through standardized interfaces and events.

I recently checked out projects like joynr to inspire these ideas, and while integrating multiple languages is a long-term goal, there’s plenty to work on right now. The alpha version has just been released, and I really encourage you to give it a try, share your thoughts, and let me know about any issues or additional features you’d like to see.

[Nevo David]

Amazing! This framework's adaptability for various protocols is truly cutting-edge. How might this improve scalability in real-world applications?

[Genix]

Great question! Gland's flexibility lets you choose the best protocol for your needs—whether it's HTTP, WebSocket, or something else. Its event-driven design decouples every component, so each part can scale independently without interfering with the rest. For example, imagine you're running your HTTP server with Express and notice that you need more performance under heavy load. With Gland, you can seamlessly switch to Fastify without changing your core business logic. This means you can focus on enhancing and scaling specific parts of your app while keeping the overall system stable and efficient.

[HexShift]

Really interesting approach here! I like the idea of making the framework protocol-agnostic — decoupling the transport layer from the core logic is super smart and definitely opens things up for flexibility down the line.

A couple thoughts that might be worth exploring:

Type safety across adapters: The Express example looks solid, but making sure type safety is preserved across other adapters (like Fastify or WebSockets) would really help maintain confidence as the project scales. Could be a nice DX boost.

Error handling: Would love to see some kind of unified error handling pattern built in. Maybe something like an event-based or middleware-style system to catch and respond to errors in a consistent way?

More examples: The docs are off to a good start, but I think more real-world usage examples (esp. with different protocols) would help folks grok the framework’s versatility a bit faster.

Benchmarks?: If you’ve done any performance comparisons or load tests vs other frameworks, I think that could be a cool addition to show where Gland shines.

Overall, this is a cool direction. Excited to see how it evolves — definitely feels like a solid foundation to build on 👏

[Genix]

You're absolutely right about type safety across adapters. That's one of the biggest priorities moving forward. Right now, the @glandjs/express adapter sets the pattern, and I’m working on abstracting common contracts so adapters like Fastify, WebSocket, or even RPC can preserve strict typing while staying flexible. The goal is to have a shared context interface that works seamlessly across all transport layers.

As for error handling — I couldn’t agree more. An event-based error system is already on the roadmap. I’m experimenting with a global @error:* channel concept where errors propagate through events, allowing developers to intercept them anywhere in the system using middleware-like listeners.

About examples: 100% valid. I’m working on putting together a few real-world use cases that demonstrate Gland’s protocol-agnostic power — including usage with multiple adapters at once (e.g., HTTP + WebSocket in the same app).

And yes — benchmarks! I haven't published any yet, but early tests on the core event broker show promising results. Once the base stabilizes, I'd love to run and share structured comparisons against other frameworks (NestJS, Fastify, etc.).

[DS4 Windows]

Wow, this sounds like a huge leap forward for Gland! Moving toward protocol-agnosticism and an event-driven system is a fantastic direction, especially for developers who need flexibility and scalability in their frameworks. I love the idea of Broker Adapters, which allow users to integrate with different protocols without being locked into one. This will certainly make Gland more versatile and future-proof.

[Đạt Phạm Vĩnh]

You might want to look at gokit, a similar thing in golang

[Benjamin Smith]

Any plans to write an adapter for socket.io?

[Bryan Hurley]

Considering your thought process, as you have described, that led to "Gland" as a name, might I suggest, Adrenal, Adrenaline, or some other responsive sub-type of the aforementioned phenotype. Lol

[Genix]

lol, I totally get what you're saying. But honestly, Gland is perfect just as it is! Keep the adrenaline pumping, but for now, I’m sticking with Gland!