Gridify: turning text filters into LINQ queries in .NET

What a text filter replaces in a typical endpoint

Gridify is a dynamic LINQ library for.NET that converts strings into LINQ queries. The problem it addresses is concrete: an endpoint that returns a list of records usually ends up with a parameter, a string, and a chunk of code that turns that string into a predicate. Gridify takes the string as the input format and produces the query expression, so the same grammar covers filtering, sorting and pagination.

The library is written in C#, published on NuGet as Gridify, and MIT licensed. It also appears on npm as gridify-client, a JavaScript and TypeScript client, which is the sign of a design decision: the filter grammar is meant to be produced by a browser or a mobile app as well as by server-side code.

The README states that Gridify is a simpler and faster alternative to GraphQL and OData, and it is worth being precise about that claim. It is the project's own comparison, and the repository contains a benchmark/ directory where those numbers are produced. What is verifiable from the outside is the mechanism: a text grammar mapped onto LINQ, applied to any collection LINQ supports.

The capability list beyond simple predicates

The features section lists more than a single equality operator, and the extra entries are where a library like this earns its keep.

Nested queries and sub-collections are supported, so a filter can reach into a child collection rather than only matching top-level properties. String to object mapping lets a filter target a value that is not a direct property. Query compilation means the parsed expression can be compiled and reused, which matters when the same filter runs across many rows or many requests. Collection indexes are supported, and custom operators let a team extend the grammar with its own terms.

The compatibility claims are broad and worth taking at face value only as far as you test. Gridify is described as compatible with ORMs, especially Entity Framework, usable on every collection LINQ supports, compatible with object mappers such as AutoMapper, and compatible with Elasticsearch. The last one is the interesting boundary case: if the same filter string can be expressed in a query that Elasticsearch understands, then one grammar can serve both a SQL store and a search cluster, which is a differentiator for an application that migrates between them.

A JavaScript client and what it implies for the contract

The npm package gridify-client is the client-side half of the story, and the repository holds a client/ directory to match. The topics attached to the project include dynamic LINQ, dynamic queries, OData, query builders and both LINQ to Objects and LINQ to SQL, which is a good description of where the library sits between an ORM and a wire format.

The practical consequence is that the filter string becomes a public API contract. Once a browser application sends something like a named filter expression, the grammar is no longer an internal detail: it has to be documented, versioned, and defended against hostile input, because a query language reachable from an untrusted client is an injection surface unless the translator only emits safe operators.

The README does not publish a grammar reference inline. The documentation site at alirezanet.github.io/Gridify carries the material, along with a page on using Gridify in API controllers, and the README links several community articles that show it in ASP.NET Core Web API projects, including one on building an ASP.NET Core Web API with Gridify and a reference bank API project suitable for bootstrapping a compliant API.

Where the alternative approaches leave you

There are two competing ways to solve the same problem, and it is worth naming them so the choice is explicit.

The first is to hand-roll the parsing. A team writes a small parser for its own filter grammar and emits expression trees by hand. The advantage is total control over the surface and no dependency, and the cost is that every operator, every type conversion and every nested-property case is code you own and must test.

The second is to lean on the ORM's own facility. Entity Framework can translate expression trees to SQL, and libraries exist that turn a query object into those expressions. The advantage is that the translation stays inside the ORM's own safety rules, and the cost is that the contract is now expressed in your API's own model types, which means the API layer and the persistence layer stay coupled.

Gridify's position between them is a shared string grammar that produces LINQ rather than SQL, so the same filter can be applied to a database-backed IQueryable or to an in-memory collection, and to other stores such as Elasticsearch. That portability is the actual argument for adopting it, and the cost is that you accept a grammar you did not design.

The repository, the benchmarks and the documentation site

The tree shows a small, focused project with the parts a library of this kind needs. There is src/ for the code, test/ for the tests, benchmark/ for the performance comparison, client/ for the JavaScript package, docs/ for the documentation sources, and gridify.slnx as the solution file. Tooling around it includes a.husky/ directory for git hooks, an.editorconfig, a.config/ directory, an update-version.bat script for cutting a release on Windows, a SECURITY.md and a CODE_OF_CONDUCT.md.

The presence of both a benchmark directory and a separate documentation site is a good sign for a library whose main claim is speed. The README's claim to be a faster alternative to GraphQL and OData is the kind of statement that only means something when the numbers can be reproduced, and the benchmark directory is where that happens.

Documentation is published at alirezanet.github.io/Gridify/, with separate pages for the documentation itself, the contribution guide and the API controller example, and the package is also listed on fuget.org.

Release cadence and the questions to answer before adopting

The release history shows a steady cadence. The three most recent versions are v2.20.0 from 2026-09-17, v2.19.1 from 2026-04-30 and v2.19.0 from 2026-03-14, and the last push to the repository was on 2026-10-16. The project is not archived, and the release numbering moves in minor versions with patch releases in between.

Two things are worth settling before a team commits to it. The first is the operator set, because a grid client in the wild will eventually send a filter the library cannot parse, and you need to know what the failure mode is: an exception, an empty result, or a silent no-op. The second is what the generated expression does on your specific store, since the same LINQ expression can translate differently on Entity Framework against SQL Server and against PostgreSQL, and the library's own compatibility claims are about the LINQ layer rather than about each provider's translation.

A third practical point is version pinning in the API. If clients generate filter strings against a published grammar, upgrading Gridify can change how those strings are interpreted. The MIT licence means you can vendor or fork the library if you need to freeze that behaviour, which is a legitimate reason to read the source rather than only the documentation.

Editorial conclusion

Gridify suits a .NET team that exposes tabular data over an API and wants the filtering, sorting and pagination contract defined in one string-based grammar rather than in per-endpoint expression code. It is the wrong choice for a codebase that already has a well-understood query layer, since the value of Gridify is the removal of that code, and it is the wrong choice if you need a hardened parser, because the project publishes no security guidance on the query language itself beyond a SECURITY.md file in the repository. Verify first that the operators Gridify supports match the ones your clients send, that the generated expressions translate to SQL on your database, and that your API version pin matches the release you deploy, since v2.20.0 was published on 2026-09-17.

Frequently asked questions

Official sources

1. alirezanet/Gridify on GitHub
2. License: MIT
3. Project website
4. README
5. Releases