Developing SCRUM Poker with Hasura GraphQL Engine — A time cost comparison
In this article I will tell you about our experience with developing a simple app with Hasura from a time based perspective including planning, design and testing. I will try to compare our result using Hasura with other technologies that are available.
Host your own by downloading the source code @ GITHUB.
During lockdowns and shift toward home office most teams faced a variety of challenges. Since our team is used to SCRUM and doing estimates using SCRUM Poker we wanted to find an online tool for that. Our requirement was that we wanted to just start playing without the hassle of writing in stories and the names of the tasks that we are going to be estimating because that is all done via screen sharing and talking in Teams, Skype and Slack.
Planning Poker (or SCRUM poker) is a gamified technique for estimating stories in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. The goal is to get the same estimate for the whole team.
We were searching for online tools and none were suitable for our needs because they offered too much functionality which made the app unnecessarily complicated and less user friendly. As we always discussed our projects via conferencing tools we only needed a simple room where you can show the cards to your team and quickly start playing.The basics we needed were:
- Users can create a room (become admins) and other users can join that room using some sort of code
- An admin can reveal the cards manually and start new rounds
- When all estimates are thrown on the table the cards are automatically revealed to all room members
Because the game is simple in its nature, we decided we will build it for internal use. Being early adopters of GraphQL and also partners with Hasura which offers instant GraphQL API’s over PostgreSQL we decided to use the RHC stack (who doesn’t like abbreviations right?).
Because Hasura offers hassle free creation of CRUD (create, read, update, delete) operations and simple authorisation and authentication techniques we decided to keep track of the time spent in order to see what Hasura can actually bring us, time-wise. Next, an analysis follows in each segment (planning, design, development and testing).
PLANNING
Part of each project is the planning phase. 1 man-hour was used to sketch up ideas and draw up some prototypes. We also scheduled one meeting (1 man-hour) to discuss our ideas (this included two developers and the designer).
Because we knew which technologies we would be using, we made a sketch of the database model and defined our entities. For that we used 3 man-hours.
Total count: 5 man-hours
DESIGN
After an initial sketch was made, we had two design meetings. The initial one (where we were throwing out ideas) and the second one where we finalised the details.
Total count: 12 man-hours
DEVELOPMENT
Frontend
For the frontend part, with initial mockups we spent 8 man-hours for the first draft, project initialisation and then 8 man-hours for design changes. Afterwards when the backend models were built an additional 16 man-hours were needed for the logic and testing.
Backend
- Project setup — the setup of the local environment and dockerization was 3 man-hours (setting up docker compose, environment variables etc.) and setting up the NodeJS service which will handle room joining and creation
- Hasura — creating the models was easy — from the planning phase we took the model we built (which took 1/4 man-hour to implement in Hasura) and added permission schemas (1 man-hour). Later we added custom actions (that will be triggered on our service) which needed an additional 1 man-hour
- NodeJS — custom backend logic for adding and creation of the room and JWT token creation, 2 man-hours including manual testing
Infrastructure
We decided to use Caprover for our PaaS provider as it is intuitive and really easy to use. For Hasura we basically just needed to select their image and the deployment was done (including database setup and persistent storage).
TESTING
We didn’t write any tests (because of the scale of the app), we mainly did manual testing in smaller teams.
Total count: 8 man-hours
So, to sum it up the total time spent was 72,25 man-hours. Let’s check out a summary now comparing it to estimates by using a different backend stack (the estimates were based on the initial three features that we wanted to implement in our app).
Note that we are presuming that the planning, design and infrastructure phase would take us the same amount of time.
Using Hasura we reduced the time spent on developing the backend by 85.5%.
Using Hasura was 85.5% faster. Of course there are a lot of presumptions here, the estimates for other stack choices can not be entirely accurate.
We noticed that most of the reduced time comes from the auto generation of CRUD, ready to be used authorizaton mechanisms and having GraphQL as an API which simplified our frontend development efforts.
From our point of view Hasura saved us a lot of time and effort and frontend development was also easier because GraphQL was used as an API.
The source code is available on Github. It is licensed under Apache License 2.0. Feel free to add to it.
