On a hot summer's day, there's nothing better than jumping into a beautiful blue pool to cool off. There's also nothing worse than wanting to jump in but seeing the pool is slime green, laden with algae and not at all suitable for swimming. Even more bothersome still is the need for manual testing, understanding how to fix the PH level, calibrating the amount of chemicals to add, and so on.
This is where iopool comes in. They provide a complete pool management solution for private pools, jacuzzis and hot tubs, starting with a sophisticated pool sensor and mobile app, and including all the products needed to keep your pool clean and safe.
In 2020, iopool's engineers realized they were facing some serious technical debt challenges that put the future of the company's tech stack at risk. Luc Matagne, iopool's Lead Software Engineer recognized the seriousness of these technical challenges. In his words, "it was a developer's nightmare".
There were 16 microservices in the project. There were a lot of differences in file structure, code structure, and tools. All the data was stored in a NoSQL database with "fake relations". The cherry on the cake was that you couldn't run all the services locally on your own machine. Each service needed to be deployed to the cloud to test it.
Knowing that this architecture would be problematic for iopool's future growth, Luc pitched a set of sweeping changes for a new version of iopool's backend. It included ripping out the individual microservices, switching to a relational database, and at the core of it all, implementing Prisma.
Luc didn't see version 1 of iopool as a failure. Rather, it showed their commitment to the LIT (Learning, Iterating, and Testing) approach, allowing them to see this as a learning and start to refactor the app design, backend, and code from scratch.
Many development teams would cringe at hearing "refactoring", and rightly so given the time and effort needed, but iopool had an additional obstacle: they needed to refactor a product that had taken them two years in less than six months. They also had to do it in time for the next high season which was to start in June.
iopool architecture before Prisma
iopool had five requirements when choosing their ORM:
Speed → There should be little to no learning curve and it should be implemented as quickly as possible. In one week, they had a database running and type safe access to all their data. By using the Prisma Schema to build their database, they were able to quickly iterate between different structures to get the best database possible from the start. "Without Prisma we would never had iopool 2.0 ready on time".
Flexibility → They had to release many new features to remain competitive. The combination of Prisma and Nexus made the management of resolvers a breeze. Everything was always easily accessible.
Ease of use → They removed the complicated paths between microservices needed to understand where the data was going (or not going). Prisma was very helpful to get the data the way that they needed easily.
Reliability → Something that they missed during the first 2 years of development was unit testing. They were finally able to add unit testing to each process in the backend. Getting the Prisma Client into the testing process was very easy and made the code base so much more reliable. "We can now sleep soundly after each new commit, with Prisma the margin error is so very small".
Comfort & Productivity→ They were now able to use a local server to live test their features and it was out of the box with Prisma. It was such a productivity gain for them.
With their requirements identified, iopool got to work on version 2 of their backend using a brand new tech stack.
The new stack relies on popular technologies such as React Native, GraphQL (using Apollo), Postgres, and DynamoDB. At version 2, Prisma plays a pivotal role.
iopool architecture after Prisma
The substantially upgraded version 2 of iopool makes extensive use of serverless functions through AWS Lambda. Nexus is used to provide a GraphQL API which is called from the React Native app. Prisma Client is used to access the Postgres database that iopool uses for everything aside from water quality data. For the enormous amount of water quality data collected, DynamoDB was chosen because of its ability to easily handle this kind of data at massive scale.
The move to use TypeScript and, in particular, Prisma and Nexus at version 2 has paid off handsomely. Instead of releasing once every two or three weeks in their previous microservices architecture, iopool is now able to release two or more times per week. Features that previously took weeks of development time have been reduced to days.
Because we found Prisma, we decided to start the refactor for the full project. We knew that Prisma would help us to go faster and be more confident, especially as we had a limited time to do the refactor.
The improvements in the development cycle are due, in large part, to the type safety that Prisma provides. The ability for iopool's developers to get intellisense, autocompletion, and type checking when making database access calls with Prisma Client has been crucial for the speed gains.
Prisma Migrate has also been key for iopool in their version 2 upgrade. Migrate has given the team confidence in their approach to database schema changes, allowing multiple developers to collaborate on a central schema and have the changes applied seamlessly across environments.
When we're editing or making a change to the schema, we know that if we're using Prisma, it's going to work.
iopool has had a smooth experience developing version 2 of their backend thanks in large part to Prisma being at the center. Prisma has allowed their developers to move faster, implement new features that would have been difficult to achieve in version 1, and has enabled new possibilities for the company's future.
To find out more about how iopool was successful with Prisma, and to learn more about Prisma itself, check out the following resources: