[Suggestion/Question] Where's all this going?

[dedupely]

Contributers here,

First of all amazing library here. It's penetrated every part of my product. I have just have one concern, what's the ultimate direction of this and how much priority is being taken in Vibe.d?

From my perspective Vibe.d is like Express.js. It's not a framework rather a library that can be used to build your own ideas on top of. Love it!

However I see a lot of small details that stop this from being 100% production ready (aside from being in beta and aside from the fact I'm already using it in production) and I'm wondering what the strategies are to make Vibe.d a stable framework. I feel like this alone is a huge benefit of using Dlang.

Also, Vibe.d has been around for a long time. I feel like a lot could be done to spring it's growth and popularity. These kinds of tools is what makes using Dlang worth it. Otherwise, I would have ditched it a long time ago and went with Node.js.

I would also love to contribute since I'm a 7+ year Dlang developer and feel like there are a few parts that need fixing.

Two things I'd look into first (let me know if I'm welcome):

• Fix max header line length of 4000 characters (which for us is an ongoing issue)
• Fix the issues with leaked FDs that seem to happen all the time for me for years.
• Create a library for handling permissions that comes out of the box with Vibe.d
• A library for rate limiting

Let me know what you all think of this. My goal is to add a few features that allow businesses to build lucrative products in Vibe.d. I know a lot of companies are already doing that but I'd love to contribute here to make it more viable across the board.

[s-ludwig]

I think from a feature perspective, there are two major things that stand out, HTTP/2 and HTTP/3 support, as well as a new module that allows writing dynamic web frontend logic in D, without having to switch to JavaScript. Both are things that, at the time, I cannot personally actively tackle due to priorities in other projects, unfortunately.

So, right now I'm basically mostly fixing things as I encounter them, and overall things are pretty stable for my own use cases. One exception to note is I/O cancellation in eventcore for the win32 implementation - this is more or less fundamentally broken and I'm not yet sure how to best approach this, as it will require some non-trivial changes to the way OVERLAPPED structures are stored. So that's something on my TODO list to fix.

Contributions are definitely welcome, especially with this otherwise limited time right now!

• Fix max header line length of 4000 characters (which for us is an ongoing issue)

Sounds like a good candidate for a quick fix in the form of a new HTTPServerSettings field.

• Fix the issues with leaked FDs that seem to happen all the time for me for years.

I've fixed a few of those "recently" and mostly find the cause somewhere in the application itself these days. But there may still be hidden leaks of course, and for example the HTTP client API could be improved to be more robust against accidental resource leaks. If you can point your finger on a particular issue, definitely a good thing to target.

• Create a library for handling permissions that comes out of the box with Vibe.d

Which kind of permissions do you have in mind here? On the web app level there is the vibe.web.auth module, which is a little hidden, but is able to handle a lot of use cases already.

• A library for rate limiting

So far I've always had a proxy configured in front of vibe.d apps, so that this hasn't been practical a priority, but this is also something that has been loosely planned since the beginnings. Also, I guess there are enough uses cases where a proxy would struggle, for example when operating with sessions or API tokens as rate limit identifiers, so this also sounds like a useful topic.

[dedupely]

Thanks for the quick response Sönke. I see you're currently involved in a startup! Using vibe.d there as well?

Glad you're open to my suggested contributions here. I'd love to get involved. Next few weeks I'll be creating a PR or two where I can, obviously doing the best I can to stay within the best practices.

For permissions I might be too biased to my own needs to create a generic solution here but I'll think of a few ideas and see if they make sense for the community.

Also, for rate limiting. Yup, I get it. I'm actually in between using different tools in Google Cloud and GKE to handle that but I find as well that there are some advantages in handling some of these things application side. The only major problem being that Cloudflare type WAF setups or rate limiting services usually identify visitors a lot better than we can on the client side. However, that being said, nothing stops me from creating separate plugins or middleware outside of vibe.d main repo. I'm thinking kind of how a lot of expressjs developers do things: for the most part separate. Maybe the same idea can be applied to permission handling.

Speaking of permissions, where I'm going with that is in the IAM direction. Identities, roles, permissions, resources. Basically those are the elements. Authentication is not really an issue as it stands and haven't had any missing parts there. However, setting permissions for roles (e.g. Admin, End User, Readonly User, etc) might be overkill for the core. So again, could be a great contribution but outside of the main repo.

My biggest needs right now and I think possibly for others is getting a few small things done that I noticed cause problems long term for projects that have a decent number of users.

Thanks for being open to contribution and best of luck in the startup world!!