Building a Dynamic Carousel System with Optional Schema Fields
TL;DR
- Designed a dynamic carousel tile system for post-cohort displays.
- Introduced a new endpoint for admin uploads of random tiles.
- Adapted schema to accommodate optional fields for enhanced flexibility.
- Ensured rigorous test checks to maintain existing functionality.
- Adjusted cohort content schema to switch validation from DB to application layer.
I’ve been working intensively to design a dynamic carousel tile system that integrates seamlessly with existing cohorts, allowing admins to upload random tiles for display after a cohort ends. Here’s a walkthrough of the process I used to tackle this engineering challenge.
My primary goal was to create a carousel tile system where admins could upload random sets of tiles that would be persisted in the database. These tiles are displayed after all predefined content for a cohort has been completed. The process required designing an endpoint for uploading new tiles, which I chose to store in an existing MongoDB collection.
To facilitate this, I needed to make some schema adjustments. Specifically, I updated the data structure by making several properties—cohort ID, start date, end date, and weekday—optional. This change required implementing test checks to confirm that existing functionality remained intact, ensuring the database schema could accommodate these new optional fields.
I crafted the endpoint within the admin routes, specifically targeting /admin/content/carousel while securing it with permissions. This approach allowed admins to upload a CSV file containing carousel data, which is then validated and uploaded through our system.
In the backend, I modified the return type to include a union bearing iCohortContent and iCarouselContentBase types to accommodate both existing and new data types. I ensured all modifications adhered to existing client-side constraints, primarily through specific endpoints handling client-side manipulations.
During the process, I encountered the need for potential deduplication logic for uploaded content. While not immediately necessary, it’s a consideration for the future. Importantly, I validated the database schema, ensuring it processed requests correctly with the use of JOI schema validation on the application layer rather than at the database layer—thus creating a minor potential area for bugs if anyone directly changes the application logic.
Through this strategic step-by-step approach, I’ve effectively extended our backend system to support a flexible, dynamic carousel tile system that promises to enhance user engagement in our post-cohort phases.
ryer.io