As mentioned in previous posts, the primary technology that we are using for our application is Laravel. We had initially planned to build on top of OWASP’s Vulnerable Web App, which is written in PHP and uses a traditional LAMP stack. After exploring the codebase, I realized that modifying it to meet our requirements would likely take more effort than starting fresh. This led me to explore Laravel as an alternative, and I’m very glad that I did.
My background is primarily in backend development, working with Go and PostgreSQL, and while I’ve been involved with some full-stack development in the past, most of those experiences involved working on small parts of larger systems. What I particularly appreciate about Laravel is how it provides powerful abstractions that make building full-featured web applications approachable, even for someone with limited frontend experience. In less than a day, I was able to create a proof-of-concept with a landing page, navigation bar, authentication system, and role-based access control, which would have taken significantly longer without Laravel’s built-in components.
As our development has progressed, I’ve been learning a lot more about Laravel’s architectural patterns and best practices. Recently, we’ve been focusing on improving our code quality by applying these principles throughout our codebase. For example, we were initially implementing all of our logic inside of controller classes (validation logic, business logic, database queries, etc.). This approach violated the single responsibility principle and made our controllers difficult to maintain and test. We’ve since started breaking these responsibilities apart into more focused classes. Business logic now lives in service classes, validation rules in form request classes, and data transformations in presenters. This has made our code much more organized and testable.
Docker has been another key technology in our stack, though it has presented some challenges. We had to spend some time ironing out issues with our local containerized deployment setup, and while this took some effort to get right, the investment has proven worthwhile. Team members can now reliably spin up identical development environments regardless of their local setup.
For the frontend, we chose to use Laravel’s Blade templating system for its simplicity and ease of use. While Blade has served our needs well, I sometimes wonder if we should have opted for a more modern frontend framework like React. When setting up a Laravel project, you can choose between different frontend stacks including Blade templates, React, or Vue.js. Given my limited frontend experience, Blade templates seemed like the safest choice, but React’s component-based architecture might have made it easier to build more interactive and dynamic features.
For styling, we are using Tailwind CSS. Since none of us have extensive experience with frontend styling, we would have faced a learning curve regardless of which styling solution we chose. Tailwind has proven to be a reasonable choice, offering a straightforward way to create consistent layouts.
We’ve been using PHPUnit for our testing needs. It took a bit of effort to figure out how to properly use the framework, but now that we’ve gotten the hang of it, it seems relatively straightforward. I think it will be very valuable for verifying our application’s behavior and making sure we aren’t introducing regressions as we continue to build out and improve the codebase.
We’re getting very close to having all of the major features of the application finished and well-tested, at which point we will start to focus on identifying and documenting various vulnerabilities in our application. We will likely use tools like OWASP ZAP, SQLmap, and Metasploit in this process. I have no experience with tools like these, so I am looking forward to learning how to use them.
All-in-all, I’m pleased with the technology choices we’ve made. Laravel has been particularly enjoyable to work with, and while the containerized deployment with Docker took some time to get right, it’s proven to be very useful in our development process. The only change I might consider would be using React instead of Blade templates for building more interactive features, but that’s a minor consideration given how well everything has worked together.
