When I first started developing “Closet Conscious,” I quickly realized that building a sustainable app requires more than just a solid front end.
The backend is the engine that powers user experiences, and its design is crucial for maintaining a scalable, secure, and efficient application. Here’s how my journey through backend development has shaped “Closet Conscious” into more than just a virtual wardrobe—it’s an experience designed to promote mindful fashion choices.
SQL Over ORMs: Simplifying the Backend for Sustainability 🗃️
One of the early decisions I faced was whether to use Object-Relational Mappers (ORMs) or stick with SQL for database interactions. After weighing the pros and cons, I decided to leverage the direct power of SQL.
By sending all relevant data from the app to PostgreSQL functions via Supabase, I kept data manipulation inside the database, which improved performance, enhanced security, and simplified the frontend code. Much like a well-organized closet simplifies getting dressed, this approach streamlined development and ensured efficient workflows.
Transitioning from Void to JSON Responses: The Value of Feedback 📊
Initially, I designed my PostgreSQL functions to return void, thinking this would reduce complexity. But it quickly became clear that without feedback on operations, the app was left in the dark.
Transitioning to JSON responses brought immediate benefits—real-time feedback for users, easier debugging, and more efficient workflows. This shift was like ensuring every piece of clothing has a place in your closet—it makes everything easier to find and use.
Getting the Data Model Right: Building a Strong Foundation 🏗️
One of my biggest challenges was structuring the achievement tables in Supabase. A bloated schema and incorrectly populated data led to significant issues, forcing me to drop the Row Level Security (RLS) and rebuild the tables from scratch.
This experience taught me the importance of getting the data model right from the start—just like how a well-planned wardrobe prevents future clutter and chaos.
Embracing the Single Responsibility Principle: Streamlining Backend Functions 🔄
In the beginning, I tried to create all-encompassing functions to handle multiple use cases. This quickly became a maintenance nightmare. Embracing the Single Responsibility Principle allowed me to ensure that each function addressed a specific piece of business logic. This made the codebase cleaner, more modular, and easier to maintain. By organizing the backend this way, I ensured that “Closet Conscious” could scale and evolve without sacrificing stability.
The Importance of Thorough Testing: Ensuring Data Integrity ✅
Trust in the backend relies on the accuracy and integrity of data. I learned this the hard way when a logic error allowed an impossible value (-1) to be entered for the number of items worn in an outfit.
This forced me to meticulously test the backend, reviewing 46 different test scenarios over six hours. This process reminded me that thorough testing isn’t just about catching bugs—it’s about ensuring the app delivers reliable results in every scenario.
APIs vs. RPCs: Choosing the Right Tool for the Job 🔧
Understanding when to use APIs versus RPCs (Remote Procedure Calls) was another key lesson. APIs are great for reading data—they offer flexibility for dynamic queries and fetching only the necessary information. On the other hand, RPCs excel in handling complex data manipulations.
Knowing when to use each approach keeps the backend clean and efficient, much like choosing the right clothing for the right occasion ensures comfort and confidence.
Choosing the Right Database for the Right Functionality: PostgreSQL & Beyond 📊
While PostgreSQL has been fantastic for managing transactional data—such as user interactions and outfit tracking—I encountered a roadblock when thinking about real-time analytics. For features like real-time outfit recommendations, I realized PostgreSQL alone wouldn’t cut it.
I began exploring OLAP (Online Analytical Processing) databases for rapid processing of large datasets. This experience taught me that not all databases are created equal, and choosing the right one depends heavily on the specific functionality required.
Handling Database Quirks: Adapting to ClickHouse’s Requirements 🏎️
In my search for a high-performance OLAP database, I found ClickHouse, which seemed perfect for real-time analytics—until I hit its quirk with NULL fields. Unlike PostgreSQL, which handles NULL values smoothly, ClickHouse struggles with them, especially in large datasets. To meet ClickHouse’s requirements, I had to restructure my schema, replacing NULL values with a placeholder—”cc_none.” This taught me that each database has its quirks, and adapting to these nuances is essential for maintaining performance.
Next Article
How I use Generative AI in my coding journey
If you want to try Closet Conscious App, feel free to give it a twirl in iOS and Android.
Leave a Reply