How to deal with large data collections in Symfony Doctrine Entity

When we learn to use Doctrine's ORM correctly, we can have a very powerful tool that allows us to get things done in very short time.

Before continue, you may want to check on this previous posts:

 Lets suppose you have Customers, and each Customer has Bills associated to it:

How to call a Controller from a Service in Symfony 5+?

Sometimes you need to call a Controller from a Service class in Symfony Framework. To do that, you can call a controller from a service by injecting the Symfony\Component\HttpKernel\KernelInterface interface into your service, and then using it to create a sub-request to the controller.

Here are the steps to follow:

1. Inject Symfony\Component\HttpKernel\KernelInterface into your service:

Mini Services Architecture Part 1

Part 1. I think the best solution for most organizations thinking on distributing their systems, is a pattern that i define as Mini Services Architecture. This pattern may or may not use Docker containers and may or may not be orchestrated by Kubernetes. These are the key aspects of this pattern:

  1. Turn into a Mini Service each part of the monolith that is not going to be part of a Transaction.
  2. Use the same PHP Framework as template for each one of these.
  3. Communication between each Mini Service is through REST Api calls.
  4. Use DTOs (Using DTOs in PHP Symfony) as contract between each part involved to ensure data consistency and integrity.

 

I. As I explained in the past Article: Microservices Architecture Transaction processing is key for having a robust, highly trusted, stable system.

If we consider the example in this past article, this transaction for the purchase order:

Strategy to determine how to distribute a system

Intro.

In the past post i ended it up mentioning the key benefits of a particular Distributed System set up gave us at that time. We had a big monolithic ERP System running in a very old computer. It was running pretty well, but it was falling very short for the current needs of the Company . Then I pushed for modernizing our System adopting a new philosophy, in this case, a System made up of smaller Applications, running in different machines.

Since then, most of those enterprise applications are fundamentally the same, only difference is that thanks to the Internet, we can interact with them in many other ways and also, we can add some more functionality.

In current times, what i have seen is that as every body can post online,there are a huge amount of posts referring to Distributed Systems directly, or naming them as "Service Oriented Architecture" or the most sticky one "Microservices".

Every body has its own opinion and point of view on how these implementations should be done, and of course, we all are bombarded by marketing strategies that their ultimate goal is selling you over complicated versions of the same thing, but at the end, much more expensive.

In your Organization, most likely you are already working in a Distributed System Environment as Accounting is running its own Application, HR its own as well or Sales or Marketing, etc. and most likely each one of those Apps are running in different machines, either physical or virtual cloud instances.

Determining the Strategy to follow to achieve Distributed System.

A brief story of why we need distributed systems.

Intro.

Most Organizations that started in the early 2 thousands or before, have their Systems implemented as big Monolithic code bases.

Most likely the Application is running in one computer that works as Application Server, and other computer that works as Database Server.

In many cases, both Application and Database are running in the same machine.

Also, it is very common for these Organizations to have more than one Application running in the same machine. As the Database Server is only one, the Database is made of Schemas, each schema serving each of the Applications. For many years IBM has dominated this market, providing not only the hardware, but the software to run these Systems. 

In this setup, the mainframe computer acts as System Server and all users across the organization, work in basic computers called client terminals. Is from here that the term client-server architecture was taken.

Prehistoric times.