A characteristic of frameworks built in any programming language is the use of various components. As we saw in the previous tutorilas, frameworks provide a software developer with many different prebuilt tools to accomplish tasks such as authentication, database interaction, and RESTful API creation.

However, regarding frameworks, scalability issues are always the worst fears of any manager in the information technology field. As with any library that uses existing code, there will be always some amount of overhead, some amount of bloat, something more than is actually needed.

Scalability issues

There are many reasons why a framework could not easily scale. Let’s look at a short list of issues:

  • One issue is unnecessary code and packages that are not directly related to the actual application being built. Not every project needs authentication, for example, a database drivers per MySQL. Packages that are part of the core of the framework must be monitored for compatibility issues.
  • Design patterns, opinions, and learning curves often prevent new team members from getting familiar quickly. As the project expands, the day-to-day development needs to grow, and a software development group must continually recruit members who are either already somewhat familiar with a framework or at least understand its basic concepts.
  • Framework security issues require continual monitoring of the framework community’s website or repository to gather information regarding emergency security updates that are required. Even the underlying web server and operating system itself need to be monitored. At the time of writing, Laravel 5.1 is nearing its release and it will require PHP 5.5, since PHP 5.4 will be declared end-of-life later in 2015.
  • ORMs such as Eloquent always add a slight amount of overhead, since the code needs to be converted first from Eloquent into the fluent query builder and then into PDO code. Obviously, using an object-oriented approach to query the database is a wise choice, but it has a cost.