This article describes my personal experience dealing with GraphQL usage for reports in the Asp.Net Core application. I’m not claiming that my solution is the best one. However, I was focused on achieving low maintenance costs and simple implementation.
I will provide only a high-level overview of GraphQL without diving deep into more advanced features like Schema Stitching, etc.
I’m open to discussion about this topic, so feel free to prove I’m wrong :)
GraphQL is a tool that provides dynamic queries against application data.
The main benefit is that client of API can easily configure the data he wants…
This article gives an overview of the techniques that can make your code harder to understand and maintain.
Clean code is the priority of development. Developers can effectively implement any performance optimizations only after setting up measurement for Clean code execution.
Imagine the following hierarchy:
Now, let’s assume that we need to put all of these class instances inside some data structure that will allow us to access them by…
Write clean code. Measure. Optimize.
Optimization of LINQ is necessary only when it is the root of the problem.
If you make an optimization and don’t measure to confirm the performance increase, all you know for certain is that you’ve made your code harder to read.
I’m working on an open-source pet project called QueryNinja that provides dynamic query building. Changes defined in this article are related to version v1.1.0 and will be applied in future releases. The main execution path includes creating the query using Asp.Net Core ModelBinding and translating the query to Expression Trees.
Lead Software Engineer at EPAM