5 ms·

I'm just now learning (week 2) Laravel after coming from using other custom frameworks for years. For the record I have my own framework with a fully featured O

I'm just now learning (week 2) Laravel after coming from using other custom frameworks for years. For the record I have my own framework with a fully featured ORM of it's own and 99% unit test coverage for said ORM which is a fork of one my friend started 15 years ago and I have contributed to for several years. We started it before Laravel existed and in many ways it's exactly like Laravel. [https://github.com/Divergence/framework https://github.com/Divergence/framework] But anyway..... So far what I like: - Migrations - The ORM is pretty good - Query writer is aight - Blade - Mixx - built in CLI So far what I don't like: - All routes defined in one single file instead of procedurally in each controller (performance wise this is terrible cause you're running a bunch of regular expressions on each and every request. augh) - File structure doesn't adhere to PHP league standard [https://github.com/thephpleague/skeleton https://github.com/thephpleague/skeleton] All PHP code should be in src directory or tests directory. - [php artisan] - each project should have a file in bin folder with a PHP shebang [#!/bin/env php] with +x on the file and linked globally so instead of writing php artisan you would write $projectName instead. Link it globally even. - .env file - just use PHP files for configs which opens many possibilities like inheritable config setups. Instead of just dev or staging or prod you would instead have main, dev, production where main is env variables that don't change between environments. - Docs aren't great. Eloquent needs a PHP.net -like page where I can see every single member function but instead I google and get the getting started docs which gloss over the best features. I have to manually sit down and read the source code.

jonwinstanley 5y ago
I doubt the routes are evaluated with regular expressions on every request, more likely it’s matched based on an explode of /
- philo23 5y ago
  I think quite a lot of the PHP routers are based on regexes, for better or for worse. One of the most famous is FastRoute by nikic that (from memory) merges all your routes into one big regex and then tells you which route to dispatch based on some index that comes back in the match. I don't know how widely that specific library is still being used though or if it's since been replaced by something better. https://github.com/nikic/FastRoute https://github.com/nikic/FastRoute
fendy3002 5y ago
> - .env file - just use PHP files for configs which opens many possibilities like inheritable config setups. Instead of just dev or staging or prod you would instead have main, dev, production where main is env variables that don't change between environments. Uh what, .env is standard practices for many languages even in docker. And Laravel doesn't prohibit you to extend the config folder with your custom settings. You can easily do both. And for anyone who don't know yet, don't commit your configuration to the repo.
- hparadiz 5y ago
  That's actually kind of why I don't like it. Combining a Laravel project with docker makes you end up with multiple env files and it gets a little confusing.
  - fendy3002 5y ago
    You're getting it wrong. PHP's (and Laravel) getenv is getting the system's environment variable. .env is a helper that overrides them. It just helping you setup different env var for each project in same system. If you're using docker, it's fine to just use docker's env_file or environment value, or use Laravel's .env only if you prefer it.
lowercased 5y ago
> "All routes defined in one single file instead of procedurally in each controller (performance wise this is terrible cause you're running a bunch of regular expressions on each and every request. augh)" Have you timed it? And do you have a flexible alternative measurably faster that can drop in/ Are you taking in to account route caching? Not everything has to be in one file. RouteServiceProvider gives you a place where you can programmatically determine which route files, if any, you want to process. > File structure doesn't adhere to PHP league standard So what? And... "all php code should in in src or tests..." That doesn't even seem to be documented anywhere. PHP code could live in /config (like... you seem to want above?) - but 'config' isn't /src or /tests.
- hparadiz 5y ago
  This article has and it's pretty bad https://voltagead.com/laravel-route-caching-for-improved-performance/ https://voltagead.com/laravel-route-caching-for-improved-per... A good routing framework would not need to use a cache at all. Mine doesn't and I've built huge platforms with it. I say platforms cause my last big one was a website, 3rd party api, and mobile app back-end all integrated into one thing.
yurishimo 5y ago
I'll admit I'm not an expert, but using `php artisan route:cache` does provide some performance boost. About 5x in real world scenarios when dealing with very large route files. Article with more info: https://voltagead.com/laravel-route-caching-for-improved-performance/ https://voltagead.com/laravel-route-caching-for-improved-per...
laristine 5y ago
> File structure doesn't adhere to PHP league standard [https://github.com/thephpleague/skeleton https://github.com/thephpleague/skeleton] All PHP code should be in src directory or tests directory. The PHP League Skeleton is only for packages. On the other hand, you use Laravel to create full applications so it's not applicable. Even if somehow the Skeleton is so good its structure might be used for applications, we're under no obligation to follow PHP League's rules because they're just a private organization, not an authoritative source for standards such as PHP itself or PSR standards.
- hparadiz 5y ago
  It's totally a preference thing which I admit. Personally however I think that all namespaced PHP code should go into src/$namespace. Config and tests directory not withstanding.

jonwinstanley 5y ago

I doubt the routes are evaluated with regular expressions on every request, more likely it’s matched based on an explode of /

philo23 5y ago
I think quite a lot of the PHP routers are based on regexes, for better or for worse. One of the most famous is FastRoute by nikic that (from memory) merges all your routes into one big regex and then tells you which route to dispatch based on some index that comes back in the match. I don't know how widely that specific library is still being used though or if it's since been replaced by something better. https://github.com/nikic/FastRoute https://github.com/nikic/FastRoute

fendy3002 5y ago

> - .env file - just use PHP files for configs which opens many possibilities like inheritable config setups. Instead of just dev or staging or prod you would instead have main, dev, production where main is env variables that don't change between environments. Uh what, .env is standard practices for many languages even in docker. And Laravel doesn't prohibit you to extend the config folder with your custom settings. You can easily do both. And for anyone who don't know yet, don't commit your configuration to the repo.

hparadiz 5y ago
That's actually kind of why I don't like it. Combining a Laravel project with docker makes you end up with multiple env files and it gets a little confusing.
- fendy3002 5y ago
  You're getting it wrong. PHP's (and Laravel) getenv is getting the system's environment variable. .env is a helper that overrides them. It just helping you setup different env var for each project in same system. If you're using docker, it's fine to just use docker's env_file or environment value, or use Laravel's .env only if you prefer it.

lowercased 5y ago

> "All routes defined in one single file instead of procedurally in each controller (performance wise this is terrible cause you're running a bunch of regular expressions on each and every request. augh)" Have you timed it? And do you have a flexible alternative measurably faster that can drop in/ Are you taking in to account route caching? Not everything has to be in one file. RouteServiceProvider gives you a place where you can programmatically determine which route files, if any, you want to process. > File structure doesn't adhere to PHP league standard So what? And... "all php code should in in src or tests..." That doesn't even seem to be documented anywhere. PHP code could live in /config (like... you seem to want above?) - but 'config' isn't /src or /tests.

hparadiz 5y ago
This article has and it's pretty bad https://voltagead.com/laravel-route-caching-for-improved-performance/ https://voltagead.com/laravel-route-caching-for-improved-per... A good routing framework would not need to use a cache at all. Mine doesn't and I've built huge platforms with it. I say platforms cause my last big one was a website, 3rd party api, and mobile app back-end all integrated into one thing.

yurishimo 5y ago

I'll admit I'm not an expert, but using `php artisan route:cache` does provide some performance boost. About 5x in real world scenarios when dealing with very large route files. Article with more info: https://voltagead.com/laravel-route-caching-for-improved-performance/ https://voltagead.com/laravel-route-caching-for-improved-per...

laristine 5y ago

> File structure doesn't adhere to PHP league standard [https://github.com/thephpleague/skeleton https://github.com/thephpleague/skeleton] All PHP code should be in src directory or tests directory. The PHP League Skeleton is only for packages. On the other hand, you use Laravel to create full applications so it's not applicable. Even if somehow the Skeleton is so good its structure might be used for applications, we're under no obligation to follow PHP League's rules because they're just a private organization, not an authoritative source for standards such as PHP itself or PSR standards.

hparadiz 5y ago
It's totally a preference thing which I admit. Personally however I think that all namespaced PHP code should go into src/$namespace. Config and tests directory not withstanding.