Documenting code, one commit at a time.
We've been working on the Reimpact/platform project, and recently tackled a significant refactoring of our database schema. Our initial design had a mix of shared and module-specific tables within each tenant schema, which led to some challenges as the platform grew.
The primary goal of this refactoring was to improve modularity and maintainability by clearly separating module-specific data.
The Reimpact platform is undergoing a significant architectural shift, moving from a MySQL row-level multi-tenancy model to a more robust PostgreSQL schema-per-tenant setup. This post dives into the key considerations and steps involved in this migration, leveraging Laravel and Filament.
Row-level multi-tenancy in MySQL, while initially simpler to
Migrating data between different database systems can be a complex undertaking. Recently, the team working on the platform navigated a significant data migration from MySQL to PostgreSQL. This post outlines some key considerations and challenges encountered during the process. These insights can help you avoid common pitfalls when undertaking similar migrations.
Setting up a local development environment can often be a hurdle, especially when dealing with database credentials. Manually managing these credentials and ensuring they match the production environment can be time-consuming and error-prone. This is especially true for the Reimpact platform, where consistency between development and production environments is crucial.
When building multi-tenant applications with Laravel, managing database schemas for each tenant can become complex. We recently improved our tenant schema population process in the platform project to handle various edge cases and ensure data integrity across companies.
Our initial schema population process had several limitations:
When working on the Reimpact platform, a key aspect is ensuring data accuracy and efficiency. Recently, we addressed an issue within the generated reports functionality. The goal was to streamline data processing and eliminate redundant calculations, resulting in a more efficient system.
The initial analysis revealed that certain data points within the generated reports
After upgrading to Vite 6 in a Laravel project, you might encounter issues with the location of the manifest.json file. The laravel-vite-plugin version 0.8 expects the manifest in build/manifest.json, but Vite 6 outputs it to .vite/manifest.json. This discrepancy can break asset loading in your application.
When upgrading to newer
The Breniapp project has been undergoing UI modernization efforts, focusing on both the overall aesthetics and specific elements like the chat interface. This post will cover the key changes and their impact.
One of the primary goals was to refine the existing design system. This included subtle but impactful changes such as:
The landing project serves as a central hub for showcasing user portfolios and capabilities. A key aspect of this is guiding new users through the platform's features to ensure a smooth onboarding experience.
Recent updates focused on enhancing the portfolio tour, specifically highlighting the platform's AI-powered post generation capabilities. This involves:
When working with dynamic styling in Alpine.js, it's crucial to understand how attribute bindings interact with existing styles. A common pitfall is unintentionally overwriting existing style attributes when only intending to modify a specific style property.
The issue arises when using the :style binding in Alpine.js. If the expression bound to :style
