What I want to tell you about
- the effectiveness of Hasura
- Effect of reducing development man-hours
- High flexibility
- Secure
Challenge of "reduction of development man-hours"
Due to the recent shortage of engineers and rising unit prices, there is a problem that sufficient development man-hours cannot be secured. I think every company is taking various measures to reduce the development man-hours.
- Utilization of new technology
- Use of familiar technology
- Process review
- Thorough automation
- Review of scope
- Stop excessive quality
etc. This time, I propose that there is a possibility that the development man-hours can be reduced by "utilizing new technology" at the top.
Suppose you decide to make an app like this
Let's say you decide to make an app like this.
A simple online whiteboard tool that needs to have the following features:
- You can write on sticky notes
- You can move sticky notes
- Sticky note color will be user-specific
- You can erase sticky notes (only sticky notes you made)
- You can share the position and contents of sticky notes in real time.
- You can switch boards
- You can log in with Cognito
The development required for the backend is as follows
In order to develop the above functions, the back end needs to be developed as follows.
DB
- Table design (Board, Note 2 tables)
API
- Get a list of sticky notes linked to the board (deliver the latest value with websocket)
- Add sticky note (Create by linking with Cognito user ID)
- Update sticky note text and position
- Delete sticky notes (so that an error occurs except for the ones you created)
infrastructure
- Deploy to Fargate / ECS
- Cognito cooperation
How much man-hours do you estimate?
If you simply implement it and make something that works, saying "backend only + no testing required", how long would you estimate?
① 1 hour
② 1 day
③ 1 week
④ 1 month
Hasura can do it in an hour
In fact, when I developed the backend for the above app, it took only 1 hour to complete.
The reason whyI was able to reduce such dramatic man-hours is because I used Hasura.
Introducing four functions.
① API automatic generation
Hasura automatically generates GraphQL API from table definition.
Query methods that allow flexible search, Create, Update, Delete, etc. are also automatically generated, and simple but sufficient CRUD can be done.
② Cognito cooperation
Hasura provides a webhook and JWT authentication method.
Easily implement JWT authentication with AWS Cognito. Of course, it can also be linked with Auth0 and firebase authentication.
③ Access control
You can control the methods that can be executed for each Role of the API executor.
Access control can be described by referring to the user ID and group ID in JWT, and restrictions such as "Delete is possible only when CreatedBy matches the user ID" can be applied.
④ Subscription
Subscription is a Websocket-based real-time query that automatically delivers the latest values when the monitored resource is updated.
The interface is the same as Query, so it's very easy to use.
These functions greatly reduce development man-hours
This is the only work actually done in this development
- DB creation
- Cognito cooperation
- Access control settings
- Deploy to ECS using Copilot
If you get used to these, you can complete them in about an hour. Therefore, if it is a simple CRUD API, a significant reduction in development man-hours can be expected.
Concerns about Hasura
After reading the above, some people may have the following concerns.
① Where do you write the business logic?
② I don't want to use GraphQL on the front end. REST is good.
③ What will happen to the development environment such as version control?
Correspondence will be described for each.
① Where to write business logic
Hasura offers two options: Actions and Remote Schema.
As shown in the image above, Actions uses Websocket to pass through the process to another HTTP endpoint. You can write custom logic by preparing a web server or Lambda that processes custom logic.
Remote Schema creates a completely different GraphQL server by yourself and combines Hasura with the schema. You can build a GraphQL server that processes business logic with Apollo etc. and combine it with Hasura without any unnaturalness.
② I don't want to use GraphQL at the frontend
Hasura has a function to register a query and make it a REST API
Backend can be developed with GraphQL, front with REST
③ What will happen to the development environment?
Since all Hasura metadata (access control, etc.) is stored in the DB, developers should look at the DB in the same development environment.
Hasura will be placed in ECS and will have ELB IP restrictions so that only developers can access the console.
Since the metadata can be exported, it can be managed on Github / can be applied to the production environment.
Conclusion: Hasura is worth considering for practical use
Hasura is, in a nutshell, a "SQL client that can be called from the front"
In fact, Hasura uses an internal implementation to model the GraphQL tree structure and convert it to SQL.
In short, this is equivalent to skipping the old backend.
If you leave simple CRUD to Hasura, it will be possible to significantly reduce development man-hours.
Top comments (0)