What is your primary use case for Hasura?

In our trading application, we use Hasura mainly as a GraphQL gateway on top of Postgres to expose our data APIs quickly without writing any repetitive CRUD services. It has helped us accelerate front-end and back-end integration together while still keeping the authorization and business logic controlled through the roles of the back-end services. For example, in our trading monitoring dashboard, traders need real-time visibility of orders and positions. Earlier, we had custom REST endpoints which required frequent data retrieval directly from the database and took more time. With Hasura, we exposed GraphQL on top of Postgres and used subscriptions for updates, so UI teams got the data faster and experienced less back-end work, which required fewer APIs.

My main use case for Hasura is in a web application, specifically for data management.

Hasura was my main tool and platform for exposing all of our APIs for our insights page. Everything on our insights webpage was our analytics products from Atency, and that is where we were using Hasura for data access control, having security classes, and controlling the data via APIs. In general, everything related to APIs was via Hasura in my previous company. We had our webpage with reports via Power BI, but for all our API-related components, it was everything via Hasura.

My main use case for Hasura involves dealing with multiple source systems, where we had to create a bunch of repetitive backend work, leading to many APIs that needed to be built. Hasura made development easier because it was useful without wasting time building basic APIs over and over again; instead of creating the controller, service, repository, and DTOs manually, along with filtering and sorting, Hasura has made the work straightforward. A quick specific example of a project where Hasura helped me save time is our auto-renewal system, which we built in a recent renewal job. Without Hasura, after processing, a backend would need to expose an API endpoint such as /renewals, requiring us to manually build the DTOs, maintain multiple endpoints, support frontend changes, and handle real-time updates separately using WebSockets. With Hasura, the work became straightforward; the .NET jobs update the database, and it automatically exposes the updated data with no need for backend changes, also aiding in the real-time dashboard updates. The feature that had the most impact on my work was real-time data combined with eliminating the backend API development; that combination greatly sped up building the systems. This mattered most because our system needs to process tasks such as renewal processing, background jobs, and orchestration workflows. Using the AG Grid table was particularly useful, as we have to show renewals that are pending, processing, completed, or failed. Without Hasura, we would have had to create several REST endpoints, polling APIs, and manage WebSockets, along with manual filtering APIs. Hasura has changed our approach by handling API generation, GraphQL queries, subscriptions, and filtering, allowing the frontend to no longer wait for backend APIs to make changes. Hasura reduced backend boilerplate and enabled real-time operational dashboards by automatically exposing database changes through GraphQL subscriptions, allowing our services to focus only on business processing while Hasura handled API generation and live data.

I used Hasura for the GraphQL APIs it provided and for RBAC, which would have otherwise taken a lot of time to implement manually and perfectly. The project I was building was meant to power both mobile applications and web applications, and GraphQL APIs are particularly suited for mobile-based applications. The RBAC is role-based access control, and there was a particular role hierarchy that the client wanted which I implemented using RBAC. When I used NeonDB, it was particularly easy to integrate with Hasura and the flexibility was great because we could extend it.

My main use case for Hasura is that my application is a GraphQL application, and since connecting to the database directly through my UI, Hasura gives very excellent access to directly reach the database and get the request back without any API or endpoint creation. With the same endpoint, we can get considerable data from the database directly. A quick specific example of how I use Hasura in one of my applications is that our application shows the cards in the wallet, indicating how many points and gift cards the user has. When a user logs into our application and clicks on their gift cards, the UI makes a call directly to Hasura, where we calculate the particular user's details and collect the amount of the entire gift cards to return back to them. While doing that, we have several payment groups because a user can have different gift cards, for example Domino's or Amazon. While mixing them and providing the exact user those details, not allowing other users to access this user's specific details, Hasura is very helpful.

My main use case for Hasura is for back-end data validation.A quick, specific example of how I use Hasura for back-end data validation is that we had an integration project from one tool to another tool to Epic and how that data is flowing. All data was integrated in Hasura database. From there I use the queries to fetch the data and find out how the data is integrated and how it is working. About my main use case with Hasura, I felt Hasura is a pretty user-friendly tool.

My main use case for Hasura is to create endpoints that I can use to create, get, or update endpoints to my database. My database is on-premise, so to protect it from attackers, we hide it and give access only to Hasura with all the connections from the application directed to Hasura, which connects to the database and returns the answers. A specific example of how I set up Hasura is as follows: first, for any table, I create the table in the database, then I come back to Hasura and reload the schema for the connected database. Once the database is reloaded, I go to the tracking section and track the table that was recently created. After that, once the table is tracked, I go to the GraphQL space and select the table as well as the columns I want, and it will generate the GraphQL query. I give the return type and save this with a particular name, which acts as the endpoint for my application to access that particular table.

My main use case for Hasura is for a backend that is made on Hasura.For one healthcare project, we have used Hasura as a full back end, and we have the database and all those things inside Hasura. We have created the APIs using GraphQL inside Hasura and the actions, triggers, and cron jobs, all using Hasura. We just need to define some query in the cron job, which we need to run on a particular schedule that we define. That can be defined in cron job and scheduled triggers according to our business logic use case need.

I have used MongoDB and MySQL, and for the last two years, I am using CockroachDB, which is better than these two. I have recommended it to two more of my colleagues who have also started working on CockroachDB, and they are building an application for the global market. They have started using CockroachDB because it has been very helpful. I am using Hasura just for the GQL, GraphQL. Hasura has connectivity with CockroachDB, and I am not directly calling CockroachDB, I am just calling Hasura. Internally, Hasura calls CockroachDB, gets the data, and populates it into our application. It serves as middleware. We have real-time subscription in Hasura. If I change anything in CockroachDB, it immediately impacts Hasura. For example, if I add new fields, it gets reflected in Hasura. Integrating microservice architecture with Hasura provides an endpoint to incorporate into your microservices. It works as a connection string, and that's its main role.