DrawBack in Laravel
- Thread starter tarunap
- Start date
The quality of Laravel is mixed. Some components are well-designed, others are a mess. Dependency injection is unnecessarily complex. Documentation quality also heavily varies - there's certainly a lot to learn before you can 'correctly' build applications, and it's not always obvious where to start. It's very easy to build something the wrong way and think it's right, but that's a bit of a PHP issue in general.
All that being said, Laravel has been improving (make sure you use Laravel 5 or newer!), and there's probably not really any better options around in PHP. The PHP ecosystem just generally kind of sucks
All that being said, Laravel has been improving (make sure you use Laravel 5 or newer!), and there's probably not really any better options around in PHP. The PHP ecosystem just generally kind of sucks
Last edited by a moderator:
tarunap
New Member
I have been working on October CMS which uses a Laravel Framework.. I haven't used any Backend coding so had asked if there are any drawbacks in the framework..
It is originally based on Symfony. I don't really like projects forking instead of just working together.
But Symfony like Zend is built for the enterprise (Laravel too since it is a fork). Thus if you need raw performance- you have to look elsewhere. Phalcon (micro) is the framework we used before.
check here for performance
https://www.techempower.com/benchmarks/
We use Golang now with Negroni framework + lots of docker for devops and deploment + mongodb is the choice for db.
But Symfony like Zend is built for the enterprise (Laravel too since it is a fork). Thus if you need raw performance- you have to look elsewhere. Phalcon (micro) is the framework we used before.
check here for performance
https://www.techempower.com/benchmarks/
We use Golang now with Negroni framework + lots of docker for devops and deploment + mongodb is the choice for db.
These kind of benchmarks are really rather pointless. Not only do they not represent real-world applications or workloads, the entire point of performance is generally completely irrelevant - servers are cheap, manhours and bugs are not.
The correct order of concerns for an application is security > maintainability > performance.
Also, you probably don't want to use MongoDB (which, ironically, is very slow anyway).
Yep.
Performance is usually only important if its very bad, or in a high performance area (kernel modules, networking code, games) not web frameworks. Web frameworks are rarely a bottleneck in themselves. How much of your application CPU is spent on Routing the request, managing controllers, views etc? Probably not much in the overall scheme of things.
The exception to this is probably the Model layer if you are not careful, but even then - most ORM's are pretty moderate in their performance. Another exception may be APIs, although it could be argued (and regularly is the case) that web frameworks are not used in/suitable for hosting these.
Dont forget scalability in your order of concerns, or it will bite you
Performance is usually only important if its very bad, or in a high performance area (kernel modules, networking code, games) not web frameworks. Web frameworks are rarely a bottleneck in themselves. How much of your application CPU is spent on Routing the request, managing controllers, views etc? Probably not much in the overall scheme of things.
The exception to this is probably the Model layer if you are not careful, but even then - most ORM's are pretty moderate in their performance. Another exception may be APIs, although it could be argued (and regularly is the case) that web frameworks are not used in/suitable for hosting these.
Dont forget scalability in your order of concerns, or it will bite you
Last edited by a moderator:
Honestly, the biggest performance characteristic for ORMs is probably whether or not it uses JOINs. Beyond that, it rarely matters. And even without JOINs, most applications are never going to run into any limitations.
Dont forget scalability in your order of concerns, or it will bite you
Good one. I usually roll this one into "maintainability", but I realize that that's probably not a common way of thinking
Maintainability and scalability are very closely related, as one part of maintainability is how easy it is to split off parts of code. A big factor there is loose coupling, which also helps a great deal for scalability (as it makes it easier to have a cluster of servers dedicated to a particular task).Bit of advice to developers in general: scalability is not determined by the tools you use, but by the architecture of your application. Anybody telling you that their tool is magically 'scalable', is trying to sell you fluffy clouds.
Having just spent some time optimizing the ORM we use in our applications due to running into some performance issues I can say there are alot more critical areas than this. For example High overhead on each field/property access can add up quickly, as Model getters/setters can easily be the most used methods in an entire application. How larger result sets (i.e 10,000-100,000 small rows) are handled can also be important, both as a scalability problem (will my application continue to work when I have 1,000 locations?) and for general usage (some ORMs can easily require 100mb+ ram for this may rows).
These factors are probably more important in interpreted language compared to compiled ones (where the ORM models are themselves generated and compiled statically) as the overheads are higher.
Do you mean things like a property access over a foreign key causing a query? A good ORM should let you optimise by joining.
It is a problem with a lot of ORMs if you need to do it, but not something most web apps need - usually you only fetch what you are displaying on the page and you do not often display 10,000 things on one page. If you are calculating aggregates that is usually better done in the database. This leaves things like aggregates your database cannot handle, which are not typical.
I have started feeling frustrated that the natural way of working with an ORM tends to move too much from the database to the application layer - e.g. writing application code when I should be using a check constraint or a trigger.
I imagine that depends on the language and the framework. I imagine it would be a problem with PHP (at least used in the mod_php type config which is all I know) as everything is recreated on each request. I know the ORM I use, which runs in a persistent process, creates the model classes when you start the app.
I do not think it is a fork. It uses Symfony components, and it is listed on the Symfony site as a project using symfony: http://symfony.com/projects/laravel