High-performance, enterprise-grade engines and tools for the .NET & JS ecosystems.
Built for security by default, and designed to get out of your way.
PepperX exists around one idea: the unglamorous, repetitive parts of software — dynamic filtering, pagination, security validation, standardized contracts — should be solved once, well, and never rewritten per project. Every project under this org is built with the same principles:
- 🛡️ Security by default, not as an afterthought bolted on later.
- 🧩 Provider/runtime-agnostic cores, so the same intent can execute anywhere.
- ✅ Tested and CI-gated before anything ships — no publish without a green build.
- 📖 Documented like it matters, because a library nobody can learn fast is a library nobody adopts.
| Project | Stack | What it is | Status |
|---|---|---|---|
| QueryForge | C# / .NET 10 | A provider-agnostic dynamic query engine. Define filtering, sorting, paging, and hierarchical grouping once — via fluent C# or a JSON contract — and execute it through Dapper today, EF Core and in-memory providers next. | ✅ Active |
| QueryForge Grid Adapters | TypeScript / JS | Frontend adapters translating enterprise data-grid loadOptions (DevExtreme, AG Grid, Kendo UI) directly into QueryForge's JSON query contract — no manual mapping required. |
🔧 In Development |
PepperX.QueryForge.EFCore— Entity Framework Core execution providerPepperX.QueryForge.InMemory— in-memory provider forIEnumerable-based data- First public release of the JS/TS grid-adapter package
Questions, ideas, or found a bug? Open an issue on the relevant repo above — we read all of them.