ORMs are useful tools that help us save our objects to the database. However, there are some pitfalls, so it is important to know the tools we use. In this article, I want to focus on the poor performance of reading a lot of data using ORMs.
Imagine an engineer tasked with updating a feature who makes changes across the entire codebase without a clear plan or structure. Instead of committing small, focused updates, they introduce a massive set of changes at once, touching numerous files and modules. Without TDD or incremental commits, tracking all these modifications becomes overwhelming, making even simple tasks like code reviews or context switching costly and confusing. This disorganized approach, known as shotgun surgery, increases the likelihood of bugs and errors, making the code harder to maintain. In this article, we’ll explore how to avoid this pitfall and improve both productivity and code safety.
In the evolving landscape of software development, modular monolith architectures have gained significant traction. This approach offers a balanced middle ground between traditional monolithic applications and microservices. However, choosing the right PHP framework for building modular monoliths is crucial, as it can have a profound impact on the application’s performance. The container performance, which is critical for dependency injection and managing service lifecycles, varies significantly between frameworks such as Symfony and Laravel. Despite the rise of framework-agnostic practices, the reality is that switching frameworks can be prohibitively expensive. It’s crucial to make an informed decision when choosing a framework. This article explores a comparative analysis of container performance in Symfony and Laravel within modular monolith architectures, offering engineers valuable insights to guide their framework selection.
Having a profiler and performance monitoring is crucial for maintaining the efficiency and reliability of any application. Profilers help engineers identify bottlenecks by providing detailed insights into the application’s performance, such as memory usage, CPU load, and execution time of various functions.
In the landscape of software testing, the choice between a do-it-yourself (DIY) approach to mocking or utilizing mocking frameworks is a pivotal decision for programmers. While mocking is indispensable for code reliability, its overuse or incorrect implementation can introduce complexities and fragilities within test suites. This article navigates the balance between leveraging mocks effectively and avoiding common pitfalls, including the dangers of writing mocks in a suboptimal manner.
While unit tests are known for their speed compared to integration tests, the latter offer heightened confidence in the system’s functionality. Thus, avoiding integration tests is not advisable; instead, it’s crucial to strike a balance by writing tests at an appropriate level to ensure high confidence in the codebase. Achieving this equilibrium between time efficiency and confidence is paramount. Rapid feedback is essential for a smooth workflow, and today, I’ll share concise tips to enhance the efficiency of your integration tests. The effort invested is worthwhile, as swift feedback is indispensable for seamless operations, and each minute of improvement is magnified by the frequency of executions and the number of developers in the company.
Last time I’ve been analyzing the performance of Laravel’s container. I’ve encountered that the application spends a lot of time building dependencies, especially for heavy endpoints. That was strange because I would rather expect the relevant logic should be the heaviest part of the request.
Some time ago I started wondering about the long bootstrap time of an application based on Laravel. I’ve started debugging and have figured out that this problem was related to the lack of deferred providers. It was strange because we’ve used a lot of deferred providers. After more debugging, we’ve found that AggregateProviders doesn’t respect deferred providers.
Read More
What do you expect from the framework if the dependency cannot be created? Sure, it should be an exception, but I had an unpleasant surprise.
During modeling a business logic we have often a problem with properly highlighting a relevant future action. I mean relevant from a domain point of view. The most popular solution will be using a CLI command which will be executed by cron at a specific time. I think that this solution often hides a lot of business logic in an inappropriate place. Perhaps, there is a better way?