MAINTAINERS WANTED: Looking for active authors to help with the maintenance/evolution of apicache!

[kwhitley]

First of all, I want to apologize for the long delay in getting to some of these issues. I wrote apicache 8 years ago when the options available for route caching were basically non-existent. I assumed the whole time that the relatively infantile (at the time) Express.js would surely implement something similar, but until then... apicache would fill the gap.

As fortune would have it, they didn't - and 8 years later, libraries like apicache are still in use.

I also made [more than] several mistakes along the way. The idea, which started out small and simple, quickly began to wrap in ideas from others. I am certainly super grateful for the contributions, but each of these involved future support, compatibility issues, and ultimately, a lack of [my] perfect awareness of all the edge cases possible within apicache. Were I to do it over, it would be to create a lightweight interface, implement it with a memory-cache (appropriate for debugging), and make it easy to extend for additional support. In this manner, the core apicache would remain simple, easy to test, and the downstream libraries would be able to simply ensure support for their "flavor" (e.g. restify, koa, different stores, etc), rather than apicache becoming the one-stop shop that's grown out of control.

I intended to do this with v2.x... shift the whole thing to async compatible flow, add a store interface so people could simply drop in any 3rd party store (e.g. redis) for instance, rather than redis support being sprinkled throughout the codebase, etc. Instead, much of my focus over the last few year has shifted to serverless architecture (specifically with Cloudflare Workers), and I no longer became the person using the library to feel the pain points with you all.

What I'd like is to bring on additional maintainer(s), to help take charge of this floundering beast, and hopefully guide it into the light. Have experience working with/on apicache? Have a library or two under your belt (even if unpopular) so you understand the publishing flow? Respond below and let's chat!

❤️ Kevin W

[louisnow]

Thanks @kwhitley for your library! There is work going on at this fork, maybe the two projects can merge? cc @arthurfranca

I'm willing to help in any way I can, maybe porting the fixes you've been making here recently to apicache-plus would be a start. Or maybe bringing additional features from apicache-plus back into here?

[haloboy777]

I'm also willing to help in any way possible. Can review pull requests and work on some issues.

[arthurfranca]

Thanks @kwhitley for your library! There is work going on at this fork, maybe the two projects can merge? cc @arthurfranca

I'm willing to help in any way I can, maybe porting the fixes you've been making here recently to apicache-plus would be a start. Or maybe bringing additional features from apicache-plus back into here?

I've created the fork so to land fixes, specially related to redis support, while keeping api compatibility. I also kept an eye on original apicache issues so to fix/reuse fixes and enhance the fork. Unfortunately, i'm currently a little out of time. Although i have plans to continue work there in a couple of months, specially with bug fixes.

apicache-plus and apicache have the same api but the code changed a lot so i imagine it's hard to backport it. The main problem with apicache-plus is that not so many people are using it (so not many bugs are detected), so something like a npm merge would definitely help make it more stable.

[adityak74]

I am also willing to help out by reviewing PRs and actually contributing to the repository and code. I have been using this plugin at the workplace and we have been patching a lot of things. I would to help out.

[ghinks]

Hello folks. I see that there was a call for maintainer and help in general are we still looking for help?

[adityak74]

Hey folks, just circling back here to see if help is still needed. Thanks!