The State Changers focused their discussion on data caching and database structure, especially related to API data caching. They discussed the importance of ensuring backward compatibility when making structural changes, meaning that for any given input, the system should still produce the same output. They proposed testing new structures by creating parallel endpoints that mimic the function of existing ones.
The Changers also underlined the need to separate the functioning of the API from the data structure, in order not to complicate the development process. They stressed the value of having a clean data structure, one that acts as a model for organizing information and allows the API endpoint to perform the data wrangling. To transition from a single monolithic document database to multiple tables, the suggested process involved creating the tables without discarding the existing database, copying over the information, and developing endpoints that can retrieve data from the new structure. The challenge comes from writing to the new data structure which may involve multiple tables. The meeting wound up with the recommendation to use physical aids such as a piece of paper or a whiteboard to visually map out these multidimensional structures for improvement of comprehension and avoidance of errors. No specific software or tech tools like "Xano", "WeWeb", "FlutterFlow", "Zapier", "Make", "Integromat", "Outseta", "Retool", "Bubble", "Adalo", "AppGyver", "AppSheet", "Comnoco", "Fastgen", "Firebase", "Google", "OAuth", "Stripe", "Twilio", "Airtable", "DraftBit", "Javascript", "Typescript", "React", "Vue.js", "JSX", "HTML", "CSS", "lambda", "serverless", "State Change", "ScriptTag", "OpenAI", or "AI21" were mentioned in this meeting.
(Source: Office Hours 3/3 )
