• Announcements

    • MannDude

      Current state of vpsBoard   02/04/2017

      Dear vpsBoard members and guests:

      Over the last year or two vpsBoard activity and traffic has dwindled. I have had a change of career and interests, and as such am no longer an active member of the web hosting industry.

      Due to time constraints and new interests I no longer wish to continue to maintain vpsBoard. The web site will remain only as an archive to preserve and showcase some of the great material, guides, and industry news that has been generated by members, some of which I remain in contact to this very day and now regard as personal friends.

      I want to thank all of our members who helped make vpsBoard the fastest growing industry forum. In it's prime it was an active and ripe source of activity, news, guides and just general off-topic banter and fun.

      I wish all members and guests the very best, whether it be with your business or your personal projects.

      -MannDude
tarunap

DrawBack in Laravel

12 posts in this topic

What is the Major Drawback in laravel framework compared to others. 

Share this post


Link to post
Share on other sites

It seems to be quite popular, I've played around with it for a while, couldn't find any drawbacks though... if you want to start using a php framework then Larvel is a good place to start.

Share this post


Link to post
Share on other sites

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 :)

Edited by joepie91

Share this post


Link to post
Share on other sites

do you have used laravel before? how do you feel? 

or you just want to increase post?

Share this post


Link to post
Share on other sites

do you have used laravel before? how do you feel? 

or you just want to increase post?

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..

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

Dependency injection is unnecessarily complex.

Seconded.

Other than that its quite nice.

Share this post


Link to post
Share on other sites

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.

 

 

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).

Share this post


Link to post
Share on other sites

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 :)

Edited by splitice

Share this post


Link to post
Share on other sites

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.

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.

Share this post


Link to post
Share on other sites

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.

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.

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.

1 person likes this

Share this post


Link to post
Share on other sites

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 a lot 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.

Do you mean things like a property access over a foreign key causing a query? A good ORM should let you optimise by joining.

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).

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.

 

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.

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.

It is originally based on Symfony. I don't really like projects forking instead of just working together.

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


 

Share this post


Link to post
Share on other sites