Framework Agnostic

Gland: Beyond Protocol-Agnostic Hey everyone, I’m back again with another update from the world of Gland — and this one is kinda big for me. So far, I’ve talked a lot about Gland being protocol-agnostic. But recently, something shifted. Gland is not just protocol-agnostic anymore — it’s kinda framework-agnostic too. What does that even mean? Let’s be real: right now Gland doesn’t care whether you're using Express, Fastify, Hono, or literally anything else that can act like an HTTP server. You can swap them in and out with minimal effort. And I’m not talking about some theoretical plug-and-play thing. I mean actual working code. Take this simple example: glandjs/gland/main/samples/01-simple/src/main.ts In this setup, I’m using Express. But if you want Fastify instead? Just do this: async function bootstrap() { const app = await GlandFactory.create(AppModule); const express = app.connectTo(ExpressBroker); express.json(); express.urlencoded({ extended: true }); express.listen(3000); } Becomes: const fastify = app.connectTo(FastifyBroker); fastify.json(); fastify.urlencoded({ extended: true }); fastify.listen(3000); Just switch ExpressBroker to FastifyBroker, and the rest works the same way. Replace ExpressContext with FastifyContext, and you’re done. Yes, I personally use Express during development. But the core logic doesn’t care. That’s the point. At first glance, people often confuse Gland with NestJS — and I get it, because of the DI system. But the idea behind Gland is quite different. If you look at the examples, you’ll see that Gland is more about flexibility and architecture than opinionated structure. ⚠️ Note: the current example might not fully run just yet because the stable version of @glandjs/express isn’t published — same for some other packages — but it shows the structure of a Gland app pretty well. Typed Events, But Still Not Happy About It In the example, I’m using something called IOEvents to help define types for input and output of events. It works, but I’ll be honest — I don’t love the DX. It feels kinda clunky. So, I’m still looking for a better way. If you’ve got ideas or cleaner solutions, hit me up. Seriously. This part matters. In Case You Missed It... I’ve already written a couple of posts that explain some of Gland’s core concepts: Protocol Agnostic Framework https://dev.to/mmdym/protocol-agnostic-framework-9p2 New Web Framework https://dev.to/mmdym/new-web-framework-42f5 Gland has evolved a lot since then. I’ve been slowly pushing it toward what I think is its real goal — not just another web framework, but something deeper. So What is Gland Right Now? At its core, Gland has: A super light DI system — just enough to register your modules, controllers, and channels. An event-based broker system that’s aware of different namespaces and protocols. Complete decoupling between core logic and any specific protocol or runtime. That’s why I honestly think Gland is less of a framework, and more of an architecture solution. And that’s also why I started breaking up the repo into smaller pieces. Right now there are a couple of stable packages you can use anywhere, totally independent of @glandjs/core: @glandjs/emitter – A blazing fast, minimal event emitter with wildcard support. @glandjs/events – A full-featured broker/channel system with namespaced events, propagation, and async hooks. Both of these are stable, tested, and I recommend trying them out even if you’re not using Gland yet. And if something breaks? Open an issue or send a PR — I’m watching them closely. What’s Next? Gland is still in active development — but we’re getting very close to a usable release. Most of the core features are already working and in use (you can see them in the examples). Sure, there are always tiny things to tweak, but overall it’s solid. One thing I’m super excited about (but haven’t done yet) is figuring out how to use NestJS modules inside Gland. Think about it: modules like JwtModule in Nest already expose a dynamic module system. What if I could plug them into Gland directly? That’s a tricky one — both in terms of syntax and type-safety — but it’s an idea that keeps bugging me. If you’ve got thoughts, ping me. Comment. Email me. Let’s talk about it. Docs? Yep, Finally. I know, I mentioned the docs site before — but now the structure is actually online: https://glandjs.github.io It’s still a work-in-progress. Some placeholder content. The mobile nav kinda sucks (feel free to fix it and open a PR). But the direction is there. First package doc is already live: https://glandjs.github.io/packages/emitter More will be added soon — including @glandjs/events, which powers a lot of the broker logic behind the scenes. Join In If you're into building modular, protocol-free, event-driven architectures, then I’d really love to hear what you think of Gland. Does it make s

May 11, 2025 - 23:26

Gland: Beyond Protocol-Agnostic

Hey everyone,

I’m back again with another update from the world of Gland — and this one is kinda big for me.

So far, I’ve talked a lot about Gland being protocol-agnostic. But recently, something shifted. Gland is not just protocol-agnostic anymore — it’s kinda framework-agnostic too.

What does that even mean?

Let’s be real: right now Gland doesn’t care whether you're using Express, Fastify, Hono, or literally anything else that can act like an HTTP server. You can swap them in and out with minimal effort. And I’m not talking about some theoretical plug-and-play thing. I mean actual working code.

Take this simple example:
glandjs/gland/main/samples/01-simple/src/main.ts

In this setup, I’m using Express. But if you want Fastify instead? Just do this:

async function bootstrap() {
  const app = await GlandFactory.create(AppModule);
  const express = app.connectTo(ExpressBroker<EventTypes>);
  express.json();
  express.urlencoded({ extended: true });
  express.listen(3000);
}

Becomes:

const fastify = app.connectTo(FastifyBroker<EventTypes>);
fastify.json();
fastify.urlencoded({ extended: true });
fastify.listen(3000);

Just switch ExpressBroker to FastifyBroker, and the rest works the same way. Replace ExpressContext with FastifyContext, and you’re done.

Yes, I personally use Express during development. But the core logic doesn’t care. That’s the point.

At first glance, people often confuse Gland with NestJS — and I get it, because of the DI system. But the idea behind Gland is quite different. If you look at the examples, you’ll see that Gland is more about flexibility and architecture than opinionated structure.

⚠️ Note: the current example might not fully run just yet because the stable version of @glandjs/express isn’t published — same for some other packages — but it shows the structure of a Gland app pretty well.

Typed Events, But Still Not Happy About It

In the example, I’m using something called IOEvents to help define types for input and output of events. It works, but I’ll be honest — I don’t love the DX. It feels kinda clunky.

So, I’m still looking for a better way. If you’ve got ideas or cleaner solutions, hit me up. Seriously. This part matters.

So What is Gland Right Now?

At its core, Gland has:

A super light DI system — just enough to register your modules, controllers, and channels.
An event-based broker system that’s aware of different namespaces and protocols.
Complete decoupling between core logic and any specific protocol or runtime.

That’s why I honestly think Gland is less of a framework, and more of an architecture solution.

And that’s also why I started breaking up the repo into smaller pieces. Right now there are a couple of stable packages you can use anywhere, totally independent of @glandjs/core:

@glandjs/emitter – A blazing fast, minimal event emitter with wildcard support.
@glandjs/events – A full-featured broker/channel system with namespaced events, propagation, and async hooks.

Both of these are stable, tested, and I recommend trying them out even if you’re not using Gland yet. And if something breaks? Open an issue or send a PR — I’m watching them closely.

What’s Next?

Gland is still in active development — but we’re getting very close to a usable release. Most of the core features are already working and in use (you can see them in the examples). Sure, there are always tiny things to tweak, but overall it’s solid.

One thing I’m super excited about (but haven’t done yet) is figuring out how to use NestJS modules inside Gland. Think about it: modules like JwtModule in Nest already expose a dynamic module system. What if I could plug them into Gland directly?

That’s a tricky one — both in terms of syntax and type-safety — but it’s an idea that keeps bugging me. If you’ve got thoughts, ping me. Comment. Email me. Let’s talk about it.

Docs? Yep, Finally.

I know, I mentioned the docs site before — but now the structure is actually online:
https://glandjs.github.io

It’s still a work-in-progress. Some placeholder content. The mobile nav kinda sucks (feel free to fix it and open a PR). But the direction is there.

First package doc is already live:
https://glandjs.github.io/packages/emitter

More will be added soon — including @glandjs/events, which powers a lot of the broker logic behind the scenes.

Join In

If you're into building modular, protocol-free, event-driven architectures, then I’d really love to hear what you think of Gland. Does it make sense to you? Could it help your projects? What kind of potential do you see in it?

Let’s build this thing together.

GitHub: https://github.com/glandjs
Docs: https://glandjs.github.io
Discord: https://discord.gg/GtRtkrEYwR
Main Repo: https://github.com/glandjs/gland