CodeIgniter vs. Laravel for Dating Script Development

[LaraDavies]

Hi all,

I've developed a dating script using CodeIgniter and am now considering building it with Laravel. I'd like your advice on which framework would be better for this type of project in the long term.

• Does Laravel offer advantages in scalability, modern features, or real-time functionality like chat and notifications?
• How do they compare in terms of security and performance for high-traffic platforms?
• Is Laravel's code structure easier for maintenance and future updates?

If you've worked with both frameworks, I’d appreciate your insights on the best choice.

Thanks

[gizmola]

As an aside, you should evaluate re-building with Symfony.  Laravel and Symfony are by far the best PHP frameworks at this point, and have many similarities.   Both frameworks are Dependency Injection frameworks, so you want to spend some time getting comfortable with what DI is, and how you would utilize that pattern with the code you write.   It also allows you to make use of things like autowiring and lazy loading (intelligently loading of classes when needed rather than kitchen sink loading of classes you might never use in a request) which will be handled by the framework for you, so long as you understand it.

Codeigniter is a fine, but very old and basic framework that is bare and simple in complexity.  Depending on the features of the app you may have had to write your own code to implement features that either of these frameworks may have provided support for.

They are also built upon component libraries so there is a bit of mixing and matching you'll see, as for example some Laravel developers prefer Symfony's twig templating system, and will integrate that instead of Laravel's Blade.  I personally prefer the Doctrine ORM for working with relational database code, as it's designed around the "Data Mapper" pattern, rather than Active Record, which is what Laravel Eloquent uses.   In either case, CI doesn't come with an ORM so that is new territory.  You don't have to convert to the use of an ORM, but in most cases you will want to.

5 hours ago, LaraDavies said:

 

• Does Laravel offer advantages in scalability, modern features, or real-time functionality like chat and notifications?
• How do they compare in terms of security and performance for high-traffic platforms?

Scalability is achieved through architecture.  No monolithic framework is scalable.  With that said you have to make decisions as to how you will achieve scalability.  As both Symfony and Laravel have been used to develop high traffic consumer sites and applications that are architected to support high transaction rates and the features you listed, there is ample support for implementing scalable architecture.  On the flip side, experience in these areas is harder to come by, and entire books have been written.  These days scalability of required infrastructure typically involves the expertise of DevOps engineers who along with developers are creating deployment infrastructure and features that allow for this scalability.  For example, one of the first issues one can hit (outside of an uncached database that has too much data and too many queries hitting it) is having enough frontend application servers to handle the request load.  So you need frontend application code that was designed to be 1 - of - N, and that was not designed or configured with a monolithic configuration. 

The simplest example of this is the question of session.  Using PHP sessions, the session files will by default be written to disk.  When user requests exceed the capacity of a single server what do you do?  Let's say you add a second server now.  This requires some form of load balancing or reverse proxying.  How do you handle sessions then?  There are a variety of approaches you can take architecturally.  The code will likely be the same, but configuration may need to be different to allow for scalability.

As for security, both Symfony and Laravel have been built with security in mind, and have features that encourage and support it.  With that said, one can always go around best practices or features that enable additional security.  If however, you work with what the frameworks provide you have a solid foundation.

Chat: Can be done different ways, but HTTP is inherently not designed for long running persistent socket connections.  Websockets is the leading alternative to support this, but it requires separate infrastructure.  For that reason, Platform as a service PAAS companies like Pusher exist to support this.  You could also self host something like a Mercure server (see https://mercure.rocks/) or you could use a company like Pusher (https://pusher.com/websockets/).

Both Symfony and Laravel have community support options (component libraries) that make working with these websocket wrapper platforms, and have been used by many companies.  There is also Twilio which provides both text messaging and general messaging api's that can be used as well as telephony features like masked calling.  I feel like I'm getting far afield here, but I've worked on several projects for a consumer service company that made extensive use of Twilio, although that company was profitable and well funded, so the inherent costs were the subject of contract negotiations and not a concern at the time.  Pusher and hosted Mercure both have free development tiers and in my opinion are reasonably priced when you consider the costs you would incur to self host this additional infrastructure, so that is what I would recommend. 

This should also tell you a lot about the possibility and the need for architectural planning and building to it.  Again I can only say that Symfony and Laravel have been used to create services and the backend for applications that serve large numbers of simultaneous users, while offering asynchronous processing of messaging, email etc.

6 hours ago, LaraDavies said:

 

• Is Laravel's code structure easier for maintenance and future updates?

 

Yes, although Symfony has a release process that offers LTS.  See https://symfony.com/doc/current/contributing/community/releases.html

With Laravel the window is 12 months (24 for security releases) so to be completely supported, you are looking at a fairly constant cycle of at very least minor version upgrades.  See https://laravelversions.com/en

My last comment on Laravel:  

What many people like about Laravel is that it has facades.  Initially facades are attractive to new developers because they are "magical" and appear to make things simple. They are a foundation for Laravel and probably one of the reasons it gained rapid popularity.  Essentially, what laravel facades do is add glue that makes any class look like its public methods are static, when in fact, this is an illusion and glue code that is part of Laravel.

 

You can read more about Facades here:  https://laravel.com/docs/11.x/facades

As I mentioned earlier, Laravel and Symfony are both Dependency Injection frameworks, so Facades are something different, as they plainly discuss in their documentation.  In practical use, facades and associated "helper" functions are ways to just use services that are built into Laravel.  So it encourages one not to use Dependency Injection, which makes the code less maintainable, and also harder to write tests for because you can't mock the parameters.  If you read the facades page you'll notice that their answer for this is that facades have a built-in method to get around this issue, so you basically have to write a test that works around the way you would have written the test if you just used the DI pattern and a constructor parameter in the first place.

 

So in their documentation they have this example where a Route handler (also a facade being used here, but nevermind that) is in the first example, returrning a Response object using the json() method, and then an example using this global "helper" function "response()->json".  

 

use Illuminate\Support\Facades\Response;
 
Route::get('/users', function () {
    return Response::json([
        // ...
    ]);
});
 
Route::get('/users', function () {
    return response()->json([
        // ...
    ]);
});

 

So whipping something out fast, I guess might appeal to someone, because they don't need to understand the details of how this all works, although of course, every feature like this comes with a runtime cost.  But the longer term question that has to be asked is:  when you can write standard DI code, and just not use facades or helpers, and that makes understanding code easier, and writing tests easier, why not do that instead.  Since Symfony doesn't have facades, it is not something you ever would concern yourself with, although you can just use Laravel and inject the parameters.

The reality is that if you go with Laravel, you will be encouraged through the documentation to make use of facades and or helper functions, and you should know that going into the project.  

[maxxd]

CodeIgniter 4 is leaps and bounds better than 3 - it was re-written from scratch to make use of modern development patterns. That being said, as gizmola mentioned it was still pretty bare-bones last time I used it, whereas Laravel is fully featured. Some may say too fully featured, but it's optimized very well and has a large and active ecosystem. For instance, if you don't want to pay for Pusher they just released Reverb, which is a Laravel-specific websocket package that isn't the easiest thing to set up, but once you do it's quite good. It has a robust queue system that allows the developer to do a lot of work asynchronously right out of the box. The learning curve is steep, but most frameworks have that problem. Just know going in that there is a lot of magic to Laravel, so making sure you're comfortable reading source code is important (although the docs are better than most, IMO).

I've not used Symfony specifically but - again as gizmola says - Laravel is built heavily on Symfony components. Best bet is to try building something smallish in all three and see which sings to you. Personally, even recognizing that Laravel has plenty of warts I prefer to work in it (though that may be Stockholm Syndrome as I've been working with it almost exclusively for about 6 years now).