It really depends on what you’re looking for. Express still "works," and NestJS still "works," so if those fit your needs, there's no reason to switch.

But whether we need a new framework or not comes down to what problems you're trying to solve. Gland isn't trying to replace NestJS it’s taking a different, fully event-driven approach that makes code more modular and flexible. If that resonates with your project’s needs, then it’s worth considering. If not, sticking with what already works is totally fine.

This one is unique due to its event driven nature

Short answer? Yes. Even thousands more, as long people are creating them in the name of innovation.

Haha, I get it. "What? Again?" -- M. Quimby. But hey, sometimes a new approach can bring fresh perspectives! Gland’s fully event-driven design isn't just another NestJS clone, it’s a different way of thinking about how data flows. Check it out: Gland GitHub.

SEO is a separate concern when it comes to backend frameworks like Gland, NestJS, Express, Koa, Fastify, and others. These frameworks primarily focus on server-side logic, and SEO optimization typically relates more to frontend rendering and how search engines crawl and index the content.

The main goal of Gland is to provide an event-driven and modular system, offering innovative ways to implement logic in backend applications. While SEO is important, it falls outside the scope of what Gland is designed to address.

dev.to/m__mdy__m/comment/2m57f

Good question! Right now, Gland’s event system is highly dynamic, allowing you to emit events without strict type constraints. While this provides flexibility, as you pointed out, it can make tracking responses harder.

One of the planned improvements is to introduce better type safety for emitted events, ensuring that the caller knows exactly what to expect. This could involve a type mapping system that links events to expected return types, making event-driven logic more predictable.

I’ll definitely take a closer look at this and explore ways to improve type inference in Gland’s event-driven flow. Thanks for the feedback!

Thanks for the great insights! I really like the idea of going beyond just controllers and providing structured guidelines for architectures like DDD and Clean Architecture. That’s definitely something worth exploring—especially how event-driven patterns can naturally fit into these architectures and enhance modularity and maintainability.

I've already been working extensively on this idea and actively exploring ways to integrate these principles into Gland. Additionally, I plan to release third-party modules for database interactions that seamlessly integrate with Gland’s event-driven approach. These modules will provide a clean, decoupled way to manage data without tightly coupling the database logic to the application’s core.

In the future, I will also publish detailed documentation and guidelines on how to build third-party extensions for Gland, ensuring that developers can easily create plugins and integrations that align with its architecture. Of course, this will come after Gland reaches a stable release.

I also love the suggestion about event-based logging and tracing. Implementing a system that tracks and records all emitted events could be incredibly useful for debugging, monitoring, and even replaying events for auditing purposes. This is definitely something I’ll be looking into as Gland evolves.

Really appreciate the feedback! If you have any concrete ideas, specific use cases, or even suggestions on how you'd like to see these features implemented, feel free to share—I’d love to refine Gland’s event-driven approach even further.

There are many cases where you may care that the event was handled before you moved on to something else, you may not care who has handled the event, but you many care that it has been handled.

Thank you for your thoughtful comment! You’ve raised a really important point about how event-driven systems should work, and I completely agree with the idea that emitters shouldn’t necessarily care about who handles the event or how it’s handled. This is actually one of the core principles behind Gland’s design, and I’d love to explain how we’ve approached this.

In Gland, ctx.emit is designed to give developers flexibility. While it can return the result of the handler, it doesn’t have to. This is intentional because we want to support both scenarios:

1. When you need a response: Sometimes, you might want to ensure that an event has been handled before moving forward. For example, if you’re processing a payment, you might want to confirm that the payment was logged before proceeding. In this case, waiting for a response from the handler makes sense.

2. When you don’t need a response: In other cases, like sending a notification, you might not care about the result at all. Here, you can simply emit the event and let the listeners handle it independently.

This flexibility allows developers to choose the right approach for their specific use case. If you prefer a more decoupled workflow where the emitter doesn’t wait for a response, you can design your system so that listeners emit follow-up events, and the emitter listens for those if needed. This keeps the emitter completely unaware of who’s handling the event or how it’s being handled, which aligns with your suggestion.

For example, imagine a scenario where a user signs up:

• The controller emits a user:signup event.
• A listener handles the event, saves the user to the database, and emits a user:created event.
• Another listener picks up the user:created event and sends a welcome email.

In this case, the emitter doesn’t need to know about the database or the email service. It just broadcasts the event, and the listeners handle the rest.

That said, I completely understand your concern about the emitter potentially becoming too involved in the handling process. This is something I’ll keep in mind for future updates. For example, we could introduce stronger type constraints or event-response contracts to make it clearer when and how responses should be used. This would help developers avoid unintended coupling while still maintaining the flexibility that Gland offers.

Thanks again for sharing your thoughts! Your feedback is incredibly valuable, and it’s exactly this kind of discussion that helps make Gland better. If you have more ideas or suggestions, I’d love to hear them!

why?

The problem is not with us, but with our idea of ​​progress. Perhaps progress does not mean reaching a final and perfect technology at all, but rather the same constant movement between ideas, tests and failures.

I like @m_mdy_m response but here's another perspective. Maybe the problem is just that humans can't remain fixed on one thing. They say change is nature and we die the moment we stop changing and improving.

If all humanity agrees to use one perfect framework then that eliminates variety and subsequently, change. There has to be options.

No! I did not try it. But now I looked at its documentation. I only saw controllers with packages named "event", but I didn't see any traces of eds in them. What is your eds implementation?

But I was attracted by your package @wooksjs/http-body. It's a good idea, maybe I'll try it.

yes you can

Thank you for your constructive suggestion about simplifying the framework. Can you elaborate further on which parts you find complex and what changes could help improve it?

Yeah, using event-emitter in NestJS is a great way to introduce some level of event-driven behavior. But the key difference with Gland is that in NestJS, events are more of an extra tool, while in Gland, everything is an event it’s not just a feature, it’s the foundation.

In NestJS, you still have controllers calling services, DI-based providers, and a structured dependency flow. You might emit events for things like notifications or background tasks, but at the core, your business logic is still function calls inside a class.

In Gland, the entire execution model is event-driven:

• Controllers don’t call services they just emit an event.
• There are no hard dependencies multiple listeners can handle the same event dynamically.
• You don’t “import a service” to use it; instead, you respond to an event when needed.

For example, in NestJS, you’d do something like:

@Controller('users')
class UserController {
  constructor(private userService: UserService) {}  
  @Get('/:id')
  getUser(ctx: Context) {
    return this.userService.getUser(ctx);
  }
}

Even if you use event-emitter, you're still relying on direct service calls.

In Gland, it’s completely different:

@Controller('users')
class UserController {
  @Get('/:id')
  getUser(ctx: Context) {
    ctx.emit('read:server', ctx);
  }
}

No direct function calls. No dependencies. The controller doesn’t care what happens next.

A Channel picks it up:

@Channel('users')
class UserChannel {
  @On('read:server')
  handleRequest(ctx: Context) {
    ctx.emit('@response:send', { ctx, body: { id: 1, name: 'John' } });
  }
}

And another channel handles the response:

@Channel('response')
class ResponseChannel {
  @On('send')
  handleResponse({ ctx, body }) {
    ctx.send(body);
  }
}

With this approach, you can add new behaviors without modifying the existing code want caching? Logging? Rate limiting? Just add more listeners.