When development began a few weeks ago, we had just moved the Laravel proof-of-concept into our main repository. My fist order of business was to clean up the codebase, removing unneeded Laravel bloat and making sure the application had a lean foundation. Laravel is great, but the initial scaffolding included some features and files that our project didn’t need, so I spent some time trimming unnecessary components and simplifying the configuration. Because some team members aren’t as experienced with web development, I wanted to make the codebase as straightforward as possible.
Initially, some team members were having problems deploying the application via Docker. This turned out to be an issue with where npm run build was creating manifest.json inside of the application container; the file was sometimes being created in public/build/.vite/ and sometimes in public/build/. It was a seemingly simple issue, but none of the available configuration options were resolving it, and it was unclear why it was behaving differently on different systems. In the end, I wrote a post-build script to make sure the file is available at the expected location. With this, all team members are able to deploy the application without issue. While doing this, I also made general improvements and optimizations to our Docker configuration.
After cleaning up the codebase and resolving the deployment issues, I decided to finish setting up the core application infrastructure, including routes, models, controllers, and the database schema. Because these elements are fundamental to the project and will be used by everyone on the team, I wanted to establish a consistent foundation upfront. My goal was to create a shared framework that would streamline development and minimize potential merge conflicts. My hope is that the early establishment of these elements will make it easier for everyone to work on their respective features without worrying about conflicting changes to the fundamental structure of the application.
Specifically, I established a consistent pattern for endpoint organization, mapped out the main endpoints based on the application requirements, and included placeholders for future features. This pattern involves keeping all endpoint methods in associated controllers and grouping endpoints logically by resource. To do this, I needed to create all of the controllers in advance. For planned features that have not been implemented, I included placeholder methods within the controllers. This should allow team members to simply update the methods in the controllers corresponding to the features they own and update the routes to map to those endpoints.
When I created the proof-of-concept, I had only created a user table, but our schema requires a couple of additional tables. Because the database had already been designed, will be used by everyone on the team, and only needed to be implemented, I added migrations to create the additional tables. I also added a factory and seeder to fill the database with fake users. During our next development period, I want to add some unit tests for the authentication and access control systems, and then get started with some penetration testing.