Coffee Beaner intention is to make GraphQL adoption much easier than other frameworks and libraries. Providing it as code rather than as a NuGet package to allow full customizations on a case-by-case basis.
Current Features
- Configuration-based and faster development
- No N+1 problem since the entire query/mutation is batched and materialized by the database engine
- Framework agnostic
- Allows business service logic within the GraphQL API project
- Allows custom mapping between Entity models and Data models
- Supports subgraph mutations and queries
- Data annotation-based configuration (Data models and Entity models)
- Leverage to a mapping framework the mapping between Data models and Entity models
- Leverage generics to generate the column names based on the data entities
- Supports any GraphQL framework or vanilla .NET API, since it is not tightly couple to a vendor
- Nodes (Left joins between entities)
- Edges (Joins between entities)
- Paging
- Filtering
- Sorting
Customizable Features
- Granular access by table/columns based on token-claims
- Data and column validations
- Query cache can be customized in multiple layers
- Query result handling can be fully customized
Queries
Even though the query cannot be directly converted and translated during the tree processing, the library supports multiple caching techniques, since queries need to be processed as a single statement for the entire tree
Support of multiple cache levels
- key: main node string Value: Calculated query
- Where and Pagination are decoupled from the query, allowing better cache plans
- Query Result data: based on the requirements, the returning data result can be upserted and saved into the cache Mutations Mutations are not cached as they are directly converted and translated during the tree processing, since the upserts do not need to be combined within a single statement. Also, mutations are tightly coupled with data, so there is not much gain in caching the queries with specific values
Top comments (0)