Wata Games was a very interesting project. We tried out a number of approaches to interpreting our client's requirements. We helped him optimize the order flow and gave advice on the business logic for the service.

The back-office business processes are not trivial at all. We needed to create a tool for six different specialists who work on each order in the sequence.

Our client was involved in the process, so we were able to highlight the six personas operating within the service after several interview sessions. After that, we wrote user tasks and rounded them off with user scenarios that looked like flowcharts. We worked on the interface in a rather linear way. Each persona could start their work when the preceding one finished. We worked thoroughly on each persona’s interface separately, taking into account our client’s requirements and requests. Then we moved to the next persona’s interface. Finally, we prepared comprehensive wireframes and gave them to our client for approval.

Node.js fit our goals perfectly for the backend of this project. It’s fast, secure, and flexible. Node.js allowed us to share code and libraries between the frontend and backend, reducing time spent on development.

We chose Typescript for its type safety and popularity and because it’s modern. Typescript brings a type system to JavaScript, which helps avoid a number of bugs at the development stage. It also helped us write self-documenting code. All JavaScript code can be run in Typescript, so there’s no problem when someone on the team doesn’t know Typescript or when you need to integrate old libraries that are written in JavaScript.

We needed to make isolated modules and ensure ease of testing, so we settled on nest.js. It’s a modern backend framework that repeats the ideas and approach of the Angular frontend framework. Nest.js allowed us to implement dependency injection and isolation at the module level.

Since TypeORM integrates perfectly with nest.js and is written in Typescript, we chose it to store data in a structured way. We also made use of a PostgreSQL database.

We found no better alternative to the Swagger OpenAPI, so we used it to document REST APIs.
 

This project was quite small and we had a strict deadline, at least for the client side of the app. Therefore, we decided to use the Mobx architecture with Mobx-State-Tree (MST), which required less code than Flux or Redux. MST helped us keep models structured and get all the advantages of mutability and immutability.

A lot of calculations had to be done on the frontend before sending data to the backend. We chose Mobx in order to do these calculations in models instead of in view components. This helped keep views as pure as possible and keep business logic in models and stores.

On the back-office side, we created a system for marking issues on video game boxes. It’s a simple graphics editor based on Canvas that lets users draw lines and points and delete them. We created it with a flexible graphics library called FabricJS.

We developed a cross-platform mobile app (Android and iOS) using a new reactive framework from Google called Flutter. The mobile app is for scanning the QR codes of items and syncing data with rich web applications. We used the Flutter material package for UI implementation and the WebSockets dart library for all network communications including signing in and out. We also used the WebSocket dart library to sync QR code data with the backend. We implemented the barcode_scan library for scanning QR codes with a device camera. There weren’t any platform-specific needs, so the Android and iOS apps have a 100% shared code base. This nearly halved the time spent on mobile app development.