complexity of the code of Laravel and its performance

Questions:

• is it ok for php world have 37 calls of functions at stack trace for such not hard task as checking user info at db??
• for example - for db query call there are 13 levels of function calls at stack trace..

Laravel isn't a lightweight framework. You should however be caching most large database pulls. You think that path is "hard" for PHP?

• about time spent by db - this is simple db select query, usually mysql did it for 1 ms, most time is taken by preprocess of sql than by real query, this is no problem.

• For me more surprised is complexity of inner part of Laravel. Just complexity of code has such results as harder development when you go away from standard cases of using of code. Poor performance as for me is not so important for not heavy loaded sites, than time used for developing when you step away from standard situations.. ..

btw - I like Api of Laravel at top level ( some questions are for top static objects, but for me this is not important).

but 37 levels of calls mean that underhood all is hard enough..

I understood about 10% of that, sorry.

English is not my native, sorry

You are over thinking. Play with laravel, have fun.

just when i read The Art of Unix Programming, by Eric Steven Raymond there are many ideas about KISS..

for example idea that: "Rule of Simplicity: Design for simplicity; add complexity only where you must."

have 37 calls for logic like:

• route
• handle
• action
• db query...

is this ok???

Laravel is a top notch php framework. What is your point ?

@justtest if you really need simplicity you probably shouldn't be using a framework. A framework by it's nature hides much of the complexity of mundane/repetitive tasks under the surface.

The offset to the hidden complexity is it's much easier/faster to put together most systems.

Only you can decide if any framework suits your project/purpose.

2 Graham, agree of course

• frameworks are very usefull even for highload tasks, just need select the one that will be usable at specific situation..
• i like laravel top level user api.. but underhood... I really little shocked..

ps. I worked with many frameworks, zend 1,2; symfony; yii; cmf/cms..

may be will be very curious read somewhere about ideas of developers of Laravel why they uses such decisions when developed framework.. will try find such somewhere..

Overthinking ? :)

if you have specific questions we can answer. If you just bumb here to say laravel seems "too complex" under the hood, what do you expect us to say ?

@justtest a CTO once said to me (symfony 1.2 back then since you've tried it), don't worry much about performance, we can upgrade the servers... +1 @pmall ! have fun dude, it is the most developer-friendly framework

2 elieandraos:

yep, performance is not big issue; but when software is too complex - and you make one step away from standard cases - simple tasks require much much much more time than they should. This my main "bumbing".

This is main point why I go away from zend 2 and symfony.

There are a lot of components in Laravel. It's not just getting data from a database but also checking auth, any middleware, settings on your routes and validation. As well as being secure with CSRF and binding SQL queries etc, it also provides easy to pick up syntax/code.

Go elsewhere if you don't like it.

The amount of function calls mean very little to complexity I think. There might be 30 function calls to do something, but if each of those functions have a very specific and clear role/responsibility, then that's better than having only 5, but bloated and complex, function calls.

And of course, being a framework, for us as users of the framework it matters little how complex the code in the framework itself is. For us as developers building apps with the framework, what matters is:

• how easy is it to build things
• does it perform well

@justtest just try it dude. what do you expect us to answer

already trying :)

hmm, may be usefull question - do someone get in trouble with inner complexity of laravel or dont? if yes - at what situations? if not - pls mention too - this is will be very useful answer too

The point of a framework is it includes much of the common functionality, surely if your product requires lots of non-standard functionality you will get little advantage from using any framework.

The whole point of a framework is you don't have to put you hands on the "inner complexity" and only work with the surface.

@justtest it's been iterated few times hare from @pmall and in a crasser way from @bashy and others that you're overthinking this. Why are you counting the function calls to begin with?

Laravel is not lightweight. No one, ever, has said it was. What it is, is well structured, complete, clear, adherent to modern web development standards in the year 2015.

Here's some benchmarking https://github.com/kenjis/php-framework-benchmark

If you think your application needs a better throughput on 71 requests per second, then you are asking the wrong question in the wrong place. A good, framework is not necessarily "simple", but it makes it very simple to work with for a variety of projects and requirements if you study it well.

It could be that ppl here got a little worked up because of the language barrier, but fact is you are in fact at a Laravel-centric forum having this conversation.

@vedmant "For example, try to remove remember_token field from users database table, and it will stop working" ? Seriously? Show me another function, anytime anywhere, where you remove fields from the db, expect it to write, fail silently and call that good practices. How does that make sense?

"So that means if you need to change some small things in existence module you'll better write your own from scratch, otherwise it just will not work" - proper oop concepts knowledge solve that problem rather easily.

Well at least laravel doesn't take 2.7 billion lines of code to query a database and return one record like z--- does.

@sid405 You didn't get at all what I'm talking about, I'm talking about complexity of code, and even if you need just to edit one small line in code class, you will need to copy or rewrite half of existence module. For example in Kohana Framework, I worked before, all you need is just place a file, extend needed class and method and that's all, you can extend any core method just in few minutes. In case of Laravel I was debugging it for hours until I found how needed me Class is instantiated and how many other files and classes I need to rewrite just to extend one method in one class.

If to speak about interfaces and own package instead. For example I wanted to make it use single users tokens table for multiple purposes, like email confirmation, remembered tokes, reset passwords, change email, so on. And starting from this point it's up to impossible to extend existence Auth package. For instance if you try to extend UsersTokenRepository that uses TokenRepositoryInterface that in its turn defines other interfaces for methods properties, so I need to extend this interface because it's type hinted in PasswordBroker class, then the same way it linked to other classes and interfaces. So what I'm talking about, that I need to extend and replace almost each of package classes, interfaces. It will be or just almost full copy of original package with only some parts changed, or I just need to create my own new one. It means that this is just not extendable code.

If you know something about oop concepts, just tell me how to extend method in UsersTokenRepository::create, and make $user nullable (just remove CanResetPasswordContract). I can already tell you that it will require to replace interface and class itself, replace service provider and use new created class in it. And this is just one method, try to extend Guard class from Auth package.

I wish I knew how to remove some components I don't always use, I've been afraid to try, may break something. An example is Authorization, one site I completely wrote a custom class for it. I do wish laravel came with less, but still made it available if wanted via composer. I hope you get what I mean. I like laravel, but I am sure not everyone uses all that comes with the install for every site.

If you want less check out lumen. Also I not source of the point of this thread. You can use Laravels components or not. Really is that simple. I don't use the default auth controller or any part except the facade and have never had an issue.

If you can read php and understand the basic concept of oop Laravel really isn't that complex compared and easy to track down methods etc. seems to be an issue for some of the newer devs as it seems if there isn't a video or an explaination in the docs it can't be done. They seem to forget it's just php you can use raw php too. You filter down the methods for the helpers like array_add() it's just a wrapper for array_merge under the hood. Or to merge objects it's (object) array_merge() under the hood.

Dang no mobile edit. Phones auto correct got me again

@vedmant

You didn't get at all what I'm talking about, I'm talking about complexity of code, and even if you need just to edit one small line in code class, you will need to copy or rewrite half of existence module.

The thing is you don't need to edit one small line of code. Auth is pretty well designed : you can easily add any auth provider you want and register it. Same for filesystem, sessions, cache, queue, ... or any other component of the framework. If you dont like this way of extending components then you wont be happy with laravel.

I don't get your remember token problem. I quickly looked at EloquentUserProvider and I think it would be easy to create a new auth provider erasing the retrieveByToken and updateRememberToken method :

class EloquentWithoutRememberTokenUserProvider extends EloquentUserProvider
{
    public function retrieveByToken($identifier, $token)
    {
        // Return a dummy user if this method ever get called
        return new \Illuminate\Auth\GenericUser();
    }

    public function updateRememberToken($identifier, $token)
    {
        // Do nothing
    }
}

Then register it somewhere in a service provider boot method :

public function boot ()
{
    Auth::extend('eloquent_without_remember_token', function($app) {

        $model = $app['config']['auth.model'];

        return new EloquentWithoutRememberTokenUserProvider($app['hash'], $model);

    });
}

Then set the driver as eloquent_without_remember_token in config.

This design allow to share new drivers through packages and the end user just have to add the package service provider and change a line in config to use it.

This is digging up an old one! :P

@pmall That works, but you can't disagree that this approach is quite complex and different for each component, there is no one solution to extend any package. All packages are written differently and require different approach, most of them will require replacing with own service provider, digging into whole package code and extend all dependable classes, this takes hours. That's why for me Laravel looks not like framework, but more like container for different packages. In my understanding, framework means working in some specific frames so any component should be written with particular and only one structure, in this case each component is more like own application, that provides some connectors to work with Laravel.