Protocol Agnostic Framework – DEV Community

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.

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?