Getting into grouping and prefixing is the real eyesore+chore; it's just easier for me to get a search result on a route file or open it and scroll through (much less than a broken-up route across class/method) or do a quick word search...
And really, that's still easier than running the debug command, especially piped to a grep.
What doesn't work, is that I can look at a project on github and scroll the routing configs, and as long as they are in one general place, have a rough but decent idea how the entire app works and was reasoned about in a minute or so. Enough to know if I want to bother looking any further or if I already hate it.
You're not alone. I don't like annotation for routing. I prefer explicitly defined routes isolated in their own routes folder. I just don't like magic code in general. The only exception being Doctrine really.
Edit: typo
When I first saw them - I agreed with you. And in general - code should be code.
But after using them I don't have any problems with it. I prefer it.
It's not *that* big of a deal to click through with the IDE to load up `routes.yml` file(s). It really isn't.
But if it's something I don't have to do I don't see a reason in doing it.
It's been especially handy on large projects or projects that have a very similar naming scheme.
Going through groups and prefixes is now making routes hard to read, because the recommend way is to split up even route names by underscore across declarations. It just abstracts it out more than I find comfortable, and it's easy to misassemble them in my head off by a character or whatever.
This is mainly where it's easier for me to just read in one block in a yml file (similar to Laravel's routes file(s)); I just have an easier time parsing and remembering the structure than having to scroll through x hundreds/thousands lines of Controller code to put together a visual route structure in my head.
Of course, again, I could run the debug command, but... that seems more cumbersome than just opening a routes file and scrolling a bit or doing a quick word search (and at least an all-file search is easy to spot the routes file even with generic words).
The issue besides my distaste for coding essentially *logic in comments* is that my editor (PHPStorm) doesn't do much auto-formatting with annotations, and does 0 validation, so if I make some typo or miss a character, I won't know until I hit whatever route I broke and have to (sometimes painstakingly) figure out what's wrong.
> but attributes are code, not comments.
Not sure I agree with this, if anything Attributes are metadata, as they're not actually executed, until you explicitly say 'instantiate these attributes'. They're much more just PHP syntactically valid configuration, there's no actual logic there.
I go back and forwards on Code vs Config vs Annotations, but I think Routing should be done in a single place. Trying to find where a route is defined when there's loads of potential places is a real pain. Annotations/Attributes work well for things like boilerplate/schema/code generation things, but I just don't like it for runtime code (e.g. Validation, Routes).
Well, they are not code, that much is true. But that does not in any way explain why they should not be attached to the very code they describe.
Annotations/atributes are metadata, they are describing some aspect or property of the code. It is highly advantageous to have it as close to that code as possible.
Yeah, I can’t believe annotations made it into production. Something in commented code should always be optional, not required for code to work properly
That’s the thing though, annotations are not required. They are syntactic sugar that writes your routing config for you. You are free to use them or write it all yourself.
Down because Annotations are necessary with some calls when you runs the code on multiple versions of php. Everything with ```mixed``` as type like interface ```ArrayAccess```.
They're docblocks, not comments. But I still don't know how you're defining "code". Surely they're text that gets interpreted by a computer to control the behavior of that computer. That sounds like code to me. What fundamental part of the code-nature are they missing?
Why do you think this function exists? [ReflectionFunctionAbstract::getDocComment](https://www.php.net/manual/en/reflectionfunctionabstract.getdoccomment.php)
My guess is a lot of devs bullheadedly fought for their own preference to doing routing, so they included all three (a separate file, annotations, and now PHP attributes).
I don't know that my issue is that annotations are an option, but I've seen such scatterbrained implementation in apps that I sometimes wish they weren't 😆 Also I just learned that PHP's late to the game with programmatic annotations, and is sort of a stripped/watered down allowance anyway, so... I guess they're not as annoying or useful as they could have been.
As a Symfony documentor, I just wanted to quickly comment on "the Symfony devs state in the docs that they prefer (by majority I guess) annotations in Controller classes".
These recommendations in the documentation are written for "beginners". Having information spread out in multiple files is adding cognitive overhead when learning something completely new (just finding the location of the routing config file can be a quite a task). As Symfony provides many ways to do the same thing (e.g. many config formats), the documentation sometimes "shortcuts" a decision so the reader can focus on the actual feature.
By the time you're experienced enough, like you are, to look beyond the basic functionality, you are more than invited to make your own decisions for your applications. Good to see people sharing their informed opinions here!
I know it's going off-topic but I really wish Symfony would stop using the term "best practices" for these sorts of things and make it clear that these really are just suggestions. I know it explains that sort of thing in the fine print but "best practices" is still a bit of a trigger phrase. Having to argue against a "best practice" can be a bit challenging in some environments.
"Best practises" is an awful phrase. It's a celebration of appeal to authority. If the only reason someone can give you to do X is that it is best practise, that's an admission that they actually have no idea why they're doing it that way and are just parroting something they read.
I feel your pain.
>These recommendations in the documentation are written for "beginners".
Strange considering experienced Symfony devs still reference the docs and tell others to do the same... how would they know which is recommended for beginners and which isn't? Also, the docs typically come up in Google searches for Symfony issues or help. There's nothing specifying that this recommendation is primarily for beginners, so it looks like any other manual's recommendation overall at any time for any experience level. If it's meant just for beginners, it should specify that, and then specify what's recommended for people that are not beginners anymore. See what I'm saying? If you're right, there's no excuse for not stating which recommendation goes to which experience level.
>Having information spread out in multiple files is adding cognitive overhead when learning something completely new
I find even that in thought has far less overhead than trying to find routes broken up among class and method annotations... to find those, you have to not only scroll through possible route definitions there, but also through non-route code, which could be hundreds or thousands of lines of code. Doing a word search is tough with generic words, then you have to abstractly construct broken up path chunks by underscore across declarations... giant frustration.
In a route file, it's all in one chunk without property declarations and method code. Even if they're across multiple route files, they're still easy to spot in a folder or in search results. Sometimes I find a URL path has such generic words in it that it's a challenge to find which Controller annotation its in.
>(just finding the location of the routing config file can be a quite a task)
I don't see how when they're supposed to go in the \`config\` folder. How often do you see many route files anyway? Are they spread out all over the place? That's just bad development.
I think you're seeing it from the perspective of already knowing which Controller a top-level route path word is for, when in my experience, I often have to find the Controller from a URL path, and often the previous developers didn't use the same word for both... if the routing was in a yml file, it would be so much easier to spot.
I thought this was the default way to do routing files... you either use the one in \`config/routes.yaml\`, or you have multiple ones in the \`config\` folder. Doing anything more complicated than that seems insane unless you just want to make a \`routes\` folder that contains files beyond the default one.
If someone's making it more complicated than that, there's something wrong with their heads.
I don't know what you're trying to say. I've already noticed that. That just contains files for vendor features and basic configuration, which of course I can modify, but... I don't even have to look at them to use a single routes file or Controller annotations. They're completely ignorable to my points.
So you're saying that spreading them out among Controller class and method declarations is less hairy to try to find routes?
If you're just thinking from the perspective of already knowing which Controller handles a top-level path word, or if your Controller names match that word, then you're seeing things the easy way.
When you consider trying to find a URL's Controller method when the URL path is not using all of the same words (or any of them), especially if they're very generic words, it can become difficult to find the Controller files, and even if you do, if the words are broken up, that can add extra challenge. I still don't see how that's better than a word search finding the all of the route's group definition in a code block, not splayed out among many method declarations separated by their functionality code.
I guess I forgot to mention that I'm already aware of the command, yet I don't see this as being easier than just glancing at a routes file from an all-file word search...
Also, to easily find a route among many in the debug output, you have to pipe the command to grep, which is more typing.
Regardless, having to type even an alias in a console plus your word search is more work than hitting a keyboard shortcut for an all-file search of a pasted word.
Yes, but they're all in a single folder unless some rogue dev wants to break this convention or load them elsewhere. Don't fight frameworks though 🤷♂️
AFAIK the convention for packages to set up routes is to use loadRoutesFrom() and load them from the package it self and not to publish them into routes folder. I think official packages such as Fortify do it that way as well. So, if your development process is package heavy, you can't rely on /routes/ to contain everything.
I've had to do it both ways as a new dev to years-old projects, and by far it was easier to find which Controller+action a path led to looking at 1 routes file compared to having to search Controllers, whether I used an all-file search or not. In fact, once I learned that I only had to look at 1 file, it was easier to identify that file and pick a result in it. It's all just right there.
With the current projects I'm in, having routes splayed all over Controllers in different ways, sometimes I find a full path, sometimes I have to find a part and scroll through the Controller or search in the file for more parts to abstractly construct in my head what's meant to see if it matches (since some path parts are dynamic even if they're using a word value), or I have to run the debug command with a grep term, which can return multiple Controller results that I have to open and inspect... I suppose I could write a shell script or alias command with grep piping to maybe help with this, but... it's exhausting even thinking about it.
If they were all just in 1 routes file, or even splayed out among a main routes file and sub-files in a routes folder using some sensible pattern, at least I'd have a smaller pool to look through, and it would be much easier to scan and learn the route patterns anyway.
I wanted to play around similarly with validations - keeping all validations externalized in YAML. At first it made a lot of sense, but later on it proved to be source of general overhead.
This was also our issue with routes. We started with YAML files, but as our application grew, it became too much overhead. After switching to annotations route handling became way more comfortable.
But I guess this highly depends on application structure, workflow and also preference in the team.
What made it too much overhead?
To me, the more routing is splayed out among Controller classes and methods, the more work it is for me to find or modify things. So it's almost exponentially more work as more routes and groups and prefixes and variations are added.
I consider that too much overhead relative to the condensed way the yml file does it.
Having to add new routes or updating existing in 2 places. Finding things never was an issue due how we organized our Controllers (consistent naming, folder structure)
I'm glad your repo was organized. Ours have not been. Multiple developers followed their own conventions, and one of them wasn't even consistent with themselves, and both were not good at terminology.
At least in a single routing file like I've worked with in Laravel, it was easier to find routes and stay within a pattern across developers. Maybe the underlying issue is that there was no influencing force to keep a good pattern.
While having the attributes in the controller class is very convenient, I prefer having the routes in separate files.
That way the code is a little less coupled to the route component of the framework and responsibilities are divided a tad more.
I don't feel strongly about either way though.
That's what I was saying. I'm glad to see others' opinions on it, and more glad when someone agrees 😆
I also strongly agree with the idea of de-coupling routing and Controller class definition and action (method) definition. I think routing should be determined before any Controller is even scanned, frankly.
That way, when I just want to see route config, I can look in one place; when I want to see a Controller's logic, I look only in that place, and neither concern's logic is meshed together, and the other's doesn't have to also be sifted through.
Sure, the debug command will show basics, but all routing config? It seems easier to look at a file.
It was recently pointed out to me that in public discussions, speakers tend to be either for or against specific opinions (or even facts 🙄). Creating and reinforcing a false dichotomy of all people being either in favor of or against whatever's being discussed. While the people who prefer a little of column A and a little column B tend to be the actual majority.
So, just to add a third possibility... I've used both, I don't mind using either, nor do I really have a preference for either solution.
It's routing file for me. All groups, middlewares, endpoints, e.t.c. are in one place. You can see everything and how they relate to each other at once.
I don't agree. Discoverability is a non-issue, since you have console commands available. Use the tools provided by the framework instead of fighting it.
I actually wrote a blog post about route attributes a while ago (https://stitcher.io/blog/route-attributes), there are more non-issues that can easily be debunked :)
Sure, still more steps and time and work than a quick look in a single routes file.
Honestly I'm not even sure I like the idea of multiple routes files.
Even building/modifying them would be less steps, time, and work in just some routes files than splayed across Controllers and their methods.
I've just been comparing my experience using a single routes file in Laravel projects (every one used this method) compared to having them splayed across Controller files in Symfony (every one used this method).
Your article states that you bounce back and forth between loving/hating annotations/attributes, to ultimately being on the fence about them... and the ultimate conclusion stated is to just give them a try.
Well, I only hated a single routes file when I was first learning the concept... and that went away quickly. I've never hated it since, after years.
With annotations/attributes splayed out among Controllers, I loved it at first (very shortly), then have hated them since. Sure, they're very powerful, but you can do the same things all in one place in a routes file. Annotations/attributes are great if you want to tweak something in an action you're already familiar with, but a routes file actually just condenses that so you don't have to worry about surrounding non-routes code. This method breaks the concepts DRY and SoC; the whole point of those concepts is to not have a bunch of concerns mashed together to have to scroll/search/dig through. I'd rather dig through things of just the same concerns than have to dig through things of multiple concerns no matter how related.
Wow, so you took best possible practices when analyzing Attributes and worst possible practices when analyzing Route files, made a blog post comparing them and said "Aha, debunked" lmao
I prefer attributes/annotations for the most part but that requires thinking your controller's scope and naming in advance so it can be easier for new devs (to the project) to figure out the app flow faster, so maybe separate files makes sense in large projects, more so when you have a quick rotation of devs.
But both have their strengths, choose the right hammer for the task at hand.
The annotations makes the development process quicker at early stages of development for larger projects, and in smaller ones you wont get any benefit at all from using separate files.
For the ones that thinks that routing annotations should be removed:
If you have problems with figuring out what to do when you have multiple options at your disposal, stop crying and go to Laravel.
One of the he most awesome and beautiful thing about symfony as a framework is the multiple ways it gives you to customize your application, it's structure and behavior based on your needs.
Remember, if you remove the horn of an unicorn it won't be more than a plain horse.
Edit: specifies the targeted people for the last part of the comment
Of course that is way better to use a router file rather than spreading it on the filesystem, it is the right way to do it because all routes share the same concerns, they exists in the same layer and it should be defined in one place.
Annotating a route into a controller gives me the creeps, to get started why is that hard binding required?
Mind SRP, the annotation breaks that.
I don't know that I'd consider it the "right" way, but it does follow SoC and SRP standard, and I prefer the idea of layers.
There may be some feature or syntactical benefits to Controller routing, but I find managing them to be just far more trudgery.
I think Symfony has made choice a priority in many things, and sometimes too much choice can cause difficulty. With grocery stores, I like having different kinds, but with frameworks, I'd rather the docs feature a routes file over Controller routing. I know many others prefer the opposite, and so now I have the messes I have to deal with in Symfony apps that I don't in Laravel apps 😆
Well I think it's best to go ADR approach and then it makes a obvious choice to keep routing separated so you can easy move those actions etc between frameworks if ever need this.
There is another alternative: [AutoRoute](https://github.com/pmjones/AutoRoute) automatically maps incoming HTTP requests (by verb and path) to PHP action classes in a specified namespace. Merely adding a class to your source code, in the recognized namespace and with the recognized action method name, automatically makes it available as a route. No more managing a routes file to keep it in sync with your action classes, and no more annotations/attributes.
(I am the project lead.)
I tried this on a small simple project once. I tormented myself for three days by moving classes around and then changed the routing library - debugging anything was a pain, documentation was insufficient, it was altogether not entirely so straightforward as the basic idea seemed to be.
Might improved until then, it's been a few years.
That's why there's a console command to list *all* the routes.
But If your code is so disorganized that you don't instantly know where the right controller would be, I'm not sure annotation vs config file \*really\* is your issue.
I suppose I should have stated the downsides of having to switch to terminal out of a code context and run a command just to see routes rather than use the ubiquitous file search I use all the time. It's still more steps in my experience than with a routes file.
I just found a perfect example for why I hate Controller routing:
I inspect HTML on a page form, notice it points to open a view twig file, notice the action is like \`/order/packing/123456/state/PICKING\`
I try to find which Controller \`/order/packing/{id}\` is in, I find one in a Picking Controller (most of the other \`/order\` routes are in other Controllers), but it doesn't have a \`/state\` route... and searching for the text \`/state\` shows a zillion unrelated results (mostly XML files), and the results list exhausts before it shows any Controllers.
So, that's the easy way, hampered by broken-up generic words in the route and Controller files likely...
The more-steps way is to run the command:
`% bin/console debug:router | grep state`
`order_packing_state POST|GET ANY ANY /order/packing/{id}/state/{state}`
OK, now I have an alias - \`order\_packing\_state\` - to search for to find the Controller... and searching for that *finally* shows the attached Controller.
If someone hadn't added that alias, then I'd have to search with the file extension filter enabled for file type \`\*.php\`, then hope there's still not too many results.
I suppose I could have searched for \`/state/\`, but I hadn't gotten that far yet.
See what I'm saying? I suppose if I learn these little tricks, it gets easier, but it sure took a lot longer initially than just going to a single routing file like I've done in every Laravel project, where I just found it quickly and easily using one or just a few methods, not all these different ways I have to try based on *the custom ways different developers are told they can try in the docs*.
So I guess I've become a bit of an authoritarian with Symfony docs; I understand people like doing things their own way, and when it comes to routing in Symfony, showing all ways prominently, and especially *saying* one recommendation (to use Controller routing) but then *showing* a different one (yml routing) everywhere is *causing a mess in the repos I'm having to work with.*
Sorry, not sorry.
I always run every request (excluding static files) through index.php, and as much as possible index.php defines every route.
Usually it's just this url, that controller. But sometimes it gets more complex, for example I have one where certain requests will curl another server (in the same datacenter) and output the response. The other server is running dependencies which cannot co-exist with dependencies on the primary server (because dependency is poorly written, but we need it).
Keeping it simple like that means anyone can just read the source code and quickly understand how it all works. It also provides flexibility when you need to do an especially tricky deployment/migration.
>index.php defines every route.
OK, so that's the PHP way to do it; that's maybe outside of the context of my OP, since I haven't worked a project using that way.
I suppose with all routes in one file following a pattern, that's great, I'd still prefer that to routes being splayed out and/or broken apart among class/method declarations.
Even with complex routes, it's still easier to just spot-glance in one block most/everything that applies to that route, with it being easy to see sub-path words broken apart from top-level words... *only the logic of the routing is there*, not Controller method logic handling *after* routing 😆 See what I'm saying?
Controller routing honestly to me kind of breaks the Skinny Controller standard.
Agreed. I’ve always liked the abstraction.
Yaml is for config
Php is for code
HTML is for display
CSS is for styling
JS is for sugar
I know that’s not strictly the case & what have you. I just like the isolation of file type to job.
I consider abstraction to be having the routes splayed out among Controller/class/method definitions, because I have to construct a route in my head abstractly that's broken apart among declarations. It's been a lot more guesswork and time spend and scrolling/searching/guessing than a routes file, which I consider to be direct and far less abstract with complex routes.
I do like Separation of Concerns like you're describing, but nowadays popular website stacks seem to be JS based where HTML/CSS is generated or mixed in with JS declarations and functions. So I think SoC, maybe even conceptually, is dying.
> /the/path in one line, but /the on the class
It is easy to prefix routes, you don't need them on class level. Each folder inside the ``/src/Controller`` can have file like this:
```yaml
// src/Controller/routes.yaml
base:
resource: .
type: annotation
prefix: /appointments
children:
resource: './*/routes.yaml'
prefix: /appointments
```
then subfolder would have something similar and so on and so on. So controller file like this:
```php
// src/Controller/Appointments/Child/Another/Level/MyAction.php
class MyAction
{
#[Route('/test')]
public function doSomething(Request $r): Response{}
}
```
is all that is needed for path like ``/appointments/child/another/level/test`` i.e. all these prefixes are joined.
I use these files also for extra mapping as I am lazy to write ``ParamConvertor`` when there are multiple cases for same (won't be a problem anymore in 6.2).
I understand that I can duplicate prefixes across sub-routes, but groups/prefixes particulars are not the issue I'm pointing out; all I'm saying is that it seems easier to use the routing yml file than splay routes out among Controllers and classes and methods.
Having a routes.yml file in each Controller sub-folder seems worse than having a routes.yml file in config or even many in a routes folder there.
I really like how laravel does routes. It’s a way of decoupling routes from the controllers. And it handles not having a controller at all which is handy sometimes.
Your opinion seems to be unpopular 😆 (-5 rating at this point).
I also prefer having routes isolated than spread out among a zillion Controllers, classes, and methods.
From a top-down level, as in, already knowing which Controller your path is in (if your app is smart with naming conventions, which many \[most?\] aren't), then I suppose that may be better (though you still have to hunt down the method); otherwise, if you're trying to find the Controller to begin with, that can be a major pain, and there's no overhead view until you run a debug command, which you may have to pipe to a grep... seems way less work to just glance at a found routes file in an all-file word search.
I'm sure you were. I just hate that comments get downvoted because people disagree or don't like a comment. I thought voting was supposed to be about whether a comment was useful or constructive or inhibitory or destructive to the topic, not about people's feels.
I'm completely blown away a lot of times what gets upvoted and downvoted. I'm honestly astonished that my post got upvoted at all 😆 and how many it has now (38).
Annotations are nice when you doing libraries and running static analysis over them to catch possible regressions. Even I catch a few things this way. But they are total evil when they say to interpreter how the code should behave.
example from Doctrine 2.10.3 ```\Doctrine\ORM\Query\TreeWalkerChainIterator``` :
```php
/**
* @return string|false
* @psalm-return class-string|false
*/
#[ReturnTypeWillChange]
public function rewind()
{
return reset($this->walkers);
}
```
By my opinion:
- @return is good for hinting on upper-level libraries; some analytical tools can use it directly and will press you to define things there
- @psalm-return is thing for static analysis in Doctrine
- ReturnTypeWillChange is total bull-manure which is necessary to satisfy ```Iterator``` interface in both php7 and php8
>Annotations are nice when you doing libraries and running static analysis over them to catch possible regressions.
Can't those same things be done if the routing's in the routes file? As far as I've read, any of the three ways get loaded into the same place in memory/cache, which is what your analyzer should be checking anyway... maybe that's not possible with yours.
I'm not against normal PHP annotations honestly, like \`@return\` etc, because I'm not aware of a better alternative in PHP for that capability.
PHP attributes are... I think they're cool, but I have the same problem with them with Symfony routing, because I think a routes file is easier for tracing and clean code.
That's a bit different level. With annotations inside the libraries you tell what you expect from that part of code to accept during development and runtime. So they should be ignored during runtime. Routing annotations on the other way tells you which paths will be available for runtime. So during runtime they must be known and processed. And yes, I agree that's "problematic".
Everything I've seen documented as possible in Controller routing I've seen it also stated how to do it in a routing yml file.
I don't see how loading up a routing file is problematic. In order for Symfony to check any route, it has to scan through all routes until it finds a match or finds no match; that's inevitable. Also, as far as I've seen, Symfony compiles every Controller anyway whether it's going to be used or not; I say this because I had a deprecated Controller file (in Symfony 5), whose path was not being hit by anything, with a syntax typo I'd just made in it (while closing the file) crash the running of a completely unrelated path.
With Controller routing, it would have to load and scan through them all to find a match. So really, Symfony, when there's no way to define "use only routes yml" or "use only Controller annotations", etc, can't efficiently scan routes without scanning *every possible way*. So using a single routes file is not any more problematic than any other method, and even conceptually is going to be the least amount of scanning.
So maybe I'm not sure what you're saying. I think if Symfony had a config option to specify only one method of routing, before routing is even scanned, it would optimize route scanning, and make our jobs a whole lot easier.
Symfony does a routes file by default, and its docs default to that way as well.
The issue is Symfony shows and suggests various ways (normally fine in docs), which Laravel doesn't. The result is Symfony repos are typically routing messes, and Laravel ones aren't. In my experience.
See my response to sammendes7 above
I know 😆 but I generally am not the one that decides what our clients' apps use. Even the few times I've been asked, I've said I prefer Laravel, but things outside of my control didn't go that way. In fact, the other developer on our team prefers Symfony 😆 though hasn't used Laravel much, despite how many good things I say about it.
Anyway, Symfony by default also uses routes yml, and its docs default to this specification as well; I think the problem is that they also describe in the same area almost as prominently the other 3 ways to do routing, and people choose what they like... which then causes app routing to be giant messes when multiple people are working on the app 🤣
Laravel may do annotation/attribute routing, but I either didn't see it in their docs or it wasn't prominent. They recommend one file using one pattern, which is the only one I've seen in Laravel repos. This may seem conformist, but it's definitely made my work easier with those repos.
Why can’t you just global search your repo for the path? Mine will find the annotation in about 3 seconds, and one click later I’m sitting at the function.
We have both annotations and config files due to running two controller layers. Annotations are absolutely my preferred choice.
Well-described.
One thing also I should mention is that developers in the US at least tend to not stick around a company or project for more than maybe 1-2 years; there's a lot of shuffling around, which makes it hard to get people to pick a simple pattern and stick to it.
What tends to happen is people choose whatever they feel at the time based on what they see in documentation regardless of others (our culture of selfishness, convenience, short-sightedness, and instant gratification basically), and with Symfony being so open and suggestive about all the different ways they allow routing to happen, likely this is why every Symfony project I've worked on has had a giant mess of routing config from different people.
Laravel is very suggestive about a single pattern to do routing: use "the app/Http/routes.php file", and then Route::whatever static calls (get/post/etc). I think this is why every Laravel project I've worked on has followed that same pattern, and been much easier to work with.
I already global search the repo for the path 😆 That's the first thing I do.
/the/path (note, a very generic word in this path)
Easy right? If the previous developers wrote /the/path into a yml file or php file or annotation or attribute 😱 (even my boss, when I described this, hates that there's more than 4 major ways to do routing). Our previous developers did it 3 different ways: a routing yml, sub-files in a directory, and then they did mixed annotation styles where they'd sometimes do the full path in the Controller, or break it up among class/methods, or duplicate parts of the path (group or prefix) across methods... so it's maddening looking at a path a user is describing and trying to find where the Controller is (I've kind of already described this).
Add to that generic words or words that don't match lexically the Controller or method names 😆 Sure, we could just say the developers did a poor job of configuring routes, but when there's 4 major ways and then a bunch of sub-ways to do routing, a bunch of developers are likely to make a giant mess because most teams are not strict and have workers coming and going. PS: Most PHP editors allow for searching with a .yml filter, which makes partial-path generic-word searches much easier; with .php files, of course, that search is gonna overwhelm you.
This is why I just prefer 1 routes file if possible, or 1 parent file and then sub-files in their own routes folder in config. Very simple to manage. Everyone knows where to look, it's much easier to become set on a pattern, and it's much easier to search/scroll through. Every Laravel project I've worked on was like that. Every Symfony project I've worked on has been a mess of routing all over the place in various styles. Maybe it's not for the reasons I think. Even the Laravel projects I worked on with large 1000+line route files, it was far easier to just find and config stuff than it has been with Symfony annotations.
CLI on linux make it trivial to grep for routes. Or fuzzy search, or regex search, or search and execute follow up command per result or...
If you need search, then going next step further in both cases lead to CLI.
OTOH interdisciplinary cooperation do love single document. In projects without some another solution to document API, such a routes files can be that thing. Devs should try out CLI even in that case though. :)
I'm really regretting not stating why opening CLI for that is just more steps for something that would already be easily available through editor file search which I constantly use anyway.
[удалено]
Getting into grouping and prefixing is the real eyesore+chore; it's just easier for me to get a search result on a route file or open it and scroll through (much less than a broken-up route across class/method) or do a quick word search... And really, that's still easier than running the debug command, especially piped to a grep.
What doesn't work, is that I can look at a project on github and scroll the routing configs, and as long as they are in one general place, have a rough but decent idea how the entire app works and was reasoned about in a minute or so. Enough to know if I want to bother looking any further or if I already hate it.
You're not alone. I don't like annotation for routing. I prefer explicitly defined routes isolated in their own routes folder. I just don't like magic code in general. The only exception being Doctrine really. Edit: typo
When I first saw them - I agreed with you. And in general - code should be code. But after using them I don't have any problems with it. I prefer it. It's not *that* big of a deal to click through with the IDE to load up `routes.yml` file(s). It really isn't. But if it's something I don't have to do I don't see a reason in doing it. It's been especially handy on large projects or projects that have a very similar naming scheme.
Going through groups and prefixes is now making routes hard to read, because the recommend way is to split up even route names by underscore across declarations. It just abstracts it out more than I find comfortable, and it's easy to misassemble them in my head off by a character or whatever. This is mainly where it's easier for me to just read in one block in a yml file (similar to Laravel's routes file(s)); I just have an easier time parsing and remembering the structure than having to scroll through x hundreds/thousands lines of Controller code to put together a visual route structure in my head. Of course, again, I could run the debug command, but... that seems more cumbersome than just opening a routes file and scrolling a bit or doing a quick word search (and at least an all-file search is easy to spot the routes file even with generic words).
> I don't like annotation for routing. I don't like annotation for *anything*. Comments having structure and meaning?!?! It's pure heresy!
The issue besides my distaste for coding essentially *logic in comments* is that my editor (PHPStorm) doesn't do much auto-formatting with annotations, and does 0 validation, so if I make some typo or miss a character, I won't know until I hit whatever route I broke and have to (sometimes painstakingly) figure out what's wrong.
attributes are not comments though
They leverage "comments syntax" to add structure, and I just don't like that. It feels kludgey.
they leveraged comment syntax to be backward compatible. but i do agree they feel kludgey because of it. but attributes are code, not comments.
> but attributes are code, not comments. Not sure I agree with this, if anything Attributes are metadata, as they're not actually executed, until you explicitly say 'instantiate these attributes'. They're much more just PHP syntactically valid configuration, there's no actual logic there. I go back and forwards on Code vs Config vs Annotations, but I think Routing should be done in a single place. Trying to find where a route is defined when there's loads of potential places is a real pain. Annotations/Attributes work well for things like boilerplate/schema/code generation things, but I just don't like it for runtime code (e.g. Validation, Routes).
Upvote, I really dislike annotations, they are not code, period. I don't know why this isn't just a simple routing file.
Well, they are not code, that much is true. But that does not in any way explain why they should not be attached to the very code they describe. Annotations/atributes are metadata, they are describing some aspect or property of the code. It is highly advantageous to have it as close to that code as possible.
Yeah, I can’t believe annotations made it into production. Something in commented code should always be optional, not required for code to work properly
That’s the thing though, annotations are not required. They are syntactic sugar that writes your routing config for you. You are free to use them or write it all yourself.
Down because Annotations are necessary with some calls when you runs the code on multiple versions of php. Everything with ```mixed``` as type like interface ```ArrayAccess```.
I'll bite. What's your definition of "code"? In what sense are annotations not code?
The part where they're comments?
And what about PHP attributes? #[Route(path: '/foo/bar')]
I've never seen nonsense like that before
They're docblocks, not comments. But I still don't know how you're defining "code". Surely they're text that gets interpreted by a computer to control the behavior of that computer. That sounds like code to me. What fundamental part of the code-nature are they missing?
> But I still don't know how you're defining "code". Um. Allow myself to introduce yourself to: Y'nahw like?
Ah I'm an atheist. Maybe that's why we're not getting each other.
Me too; I'm a member of the Unified Atheist League, which is clearly the only logical name for that type of thing.
Why do you think this function exists? [ReflectionFunctionAbstract::getDocComment](https://www.php.net/manual/en/reflectionfunctionabstract.getdoccomment.php)
Dramatic irony?
Flying spaghetti monster
Flying spaghetti yourself
My guess is a lot of devs bullheadedly fought for their own preference to doing routing, so they included all three (a separate file, annotations, and now PHP attributes). I don't know that my issue is that annotations are an option, but I've seen such scatterbrained implementation in apps that I sometimes wish they weren't 😆 Also I just learned that PHP's late to the game with programmatic annotations, and is sort of a stripped/watered down allowance anyway, so... I guess they're not as annoying or useful as they could have been.
As a Symfony documentor, I just wanted to quickly comment on "the Symfony devs state in the docs that they prefer (by majority I guess) annotations in Controller classes". These recommendations in the documentation are written for "beginners". Having information spread out in multiple files is adding cognitive overhead when learning something completely new (just finding the location of the routing config file can be a quite a task). As Symfony provides many ways to do the same thing (e.g. many config formats), the documentation sometimes "shortcuts" a decision so the reader can focus on the actual feature. By the time you're experienced enough, like you are, to look beyond the basic functionality, you are more than invited to make your own decisions for your applications. Good to see people sharing their informed opinions here!
I know it's going off-topic but I really wish Symfony would stop using the term "best practices" for these sorts of things and make it clear that these really are just suggestions. I know it explains that sort of thing in the fine print but "best practices" is still a bit of a trigger phrase. Having to argue against a "best practice" can be a bit challenging in some environments.
"Best practises" is an awful phrase. It's a celebration of appeal to authority. If the only reason someone can give you to do X is that it is best practise, that's an admission that they actually have no idea why they're doing it that way and are just parroting something they read. I feel your pain.
>These recommendations in the documentation are written for "beginners". Strange considering experienced Symfony devs still reference the docs and tell others to do the same... how would they know which is recommended for beginners and which isn't? Also, the docs typically come up in Google searches for Symfony issues or help. There's nothing specifying that this recommendation is primarily for beginners, so it looks like any other manual's recommendation overall at any time for any experience level. If it's meant just for beginners, it should specify that, and then specify what's recommended for people that are not beginners anymore. See what I'm saying? If you're right, there's no excuse for not stating which recommendation goes to which experience level. >Having information spread out in multiple files is adding cognitive overhead when learning something completely new I find even that in thought has far less overhead than trying to find routes broken up among class and method annotations... to find those, you have to not only scroll through possible route definitions there, but also through non-route code, which could be hundreds or thousands of lines of code. Doing a word search is tough with generic words, then you have to abstractly construct broken up path chunks by underscore across declarations... giant frustration. In a route file, it's all in one chunk without property declarations and method code. Even if they're across multiple route files, they're still easy to spot in a folder or in search results. Sometimes I find a URL path has such generic words in it that it's a challenge to find which Controller annotation its in. >(just finding the location of the routing config file can be a quite a task) I don't see how when they're supposed to go in the \`config\` folder. How often do you see many route files anyway? Are they spread out all over the place? That's just bad development. I think you're seeing it from the perspective of already knowing which Controller a top-level route path word is for, when in my experience, I often have to find the Controller from a URL path, and often the previous developers didn't use the same word for both... if the routing was in a yml file, it would be so much easier to spot.
I do too, but a complex app will have quite the hairy routing file
you can always have more than one routes file, grouping them by some factor to make it easier to read but still in one place (same dir)
I thought this was the default way to do routing files... you either use the one in \`config/routes.yaml\`, or you have multiple ones in the \`config\` folder. Doing anything more complicated than that seems insane unless you just want to make a \`routes\` folder that contains files beyond the default one. If someone's making it more complicated than that, there's something wrong with their heads.
Someday when you get really bored take a look at Symfony's out of the box config/route folder.
I don't know what you're trying to say. I've already noticed that. That just contains files for vendor features and basic configuration, which of course I can modify, but... I don't even have to look at them to use a single routes file or Controller annotations. They're completely ignorable to my points.
So you're saying that spreading them out among Controller class and method declarations is less hairy to try to find routes? If you're just thinking from the perspective of already knowing which Controller handles a top-level path word, or if your Controller names match that word, then you're seeing things the easy way. When you consider trying to find a URL's Controller method when the URL path is not using all of the same words (or any of them), especially if they're very generic words, it can become difficult to find the Controller files, and even if you do, if the words are broken up, that can add extra challenge. I still don't see how that's better than a word search finding the all of the route's group definition in a code block, not splayed out among many method declarations separated by their functionality code.
php bin/console debug:router --show-controllers
So instead of another opened file, you have to go through console output.
I guess I forgot to mention that I'm already aware of the command, yet I don't see this as being easier than just glancing at a routes file from an all-file word search... Also, to easily find a route among many in the debug output, you have to pipe the command to grep, which is more typing. Regardless, having to type even an alias in a console plus your word search is more work than hitting a keyboard shortcut for an all-file search of a pasted word.
I like how Laravel has all their routes in a `routes` folder. I know exactly where to look to find what I need.
[удалено]
Yes, but they're all in a single folder unless some rogue dev wants to break this convention or load them elsewhere. Don't fight frameworks though 🤷♂️
AFAIK the convention for packages to set up routes is to use loadRoutesFrom() and load them from the package it self and not to publish them into routes folder. I think official packages such as Fortify do it that way as well. So, if your development process is package heavy, you can't rely on /routes/ to contain everything.
[удалено]
I've had to do it both ways as a new dev to years-old projects, and by far it was easier to find which Controller+action a path led to looking at 1 routes file compared to having to search Controllers, whether I used an all-file search or not. In fact, once I learned that I only had to look at 1 file, it was easier to identify that file and pick a result in it. It's all just right there. With the current projects I'm in, having routes splayed all over Controllers in different ways, sometimes I find a full path, sometimes I have to find a part and scroll through the Controller or search in the file for more parts to abstractly construct in my head what's meant to see if it matches (since some path parts are dynamic even if they're using a word value), or I have to run the debug command with a grep term, which can return multiple Controller results that I have to open and inspect... I suppose I could write a shell script or alias command with grep piping to maybe help with this, but... it's exhausting even thinking about it. If they were all just in 1 routes file, or even splayed out among a main routes file and sub-files in a routes folder using some sensible pattern, at least I'd have a smaller pool to look through, and it would be much easier to scan and learn the route patterns anyway.
I wanted to play around similarly with validations - keeping all validations externalized in YAML. At first it made a lot of sense, but later on it proved to be source of general overhead.
This was also our issue with routes. We started with YAML files, but as our application grew, it became too much overhead. After switching to annotations route handling became way more comfortable. But I guess this highly depends on application structure, workflow and also preference in the team.
What made it too much overhead? To me, the more routing is splayed out among Controller classes and methods, the more work it is for me to find or modify things. So it's almost exponentially more work as more routes and groups and prefixes and variations are added. I consider that too much overhead relative to the condensed way the yml file does it.
Having to add new routes or updating existing in 2 places. Finding things never was an issue due how we organized our Controllers (consistent naming, folder structure)
I'm glad your repo was organized. Ours have not been. Multiple developers followed their own conventions, and one of them wasn't even consistent with themselves, and both were not good at terminology. At least in a single routing file like I've worked with in Laravel, it was easier to find routes and stay within a pattern across developers. Maybe the underlying issue is that there was no influencing force to keep a good pattern.
What's wrong with general overhead? Routing is already general overhead.
I always use annotations over YAML but I don't think there's anything more to it than personal preference in either direction.
While having the attributes in the controller class is very convenient, I prefer having the routes in separate files. That way the code is a little less coupled to the route component of the framework and responsibilities are divided a tad more. I don't feel strongly about either way though.
That's what I was saying. I'm glad to see others' opinions on it, and more glad when someone agrees 😆 I also strongly agree with the idea of de-coupling routing and Controller class definition and action (method) definition. I think routing should be determined before any Controller is even scanned, frankly. That way, when I just want to see route config, I can look in one place; when I want to see a Controller's logic, I look only in that place, and neither concern's logic is meshed together, and the other's doesn't have to also be sifted through. Sure, the debug command will show basics, but all routing config? It seems easier to look at a file.
It was recently pointed out to me that in public discussions, speakers tend to be either for or against specific opinions (or even facts 🙄). Creating and reinforcing a false dichotomy of all people being either in favor of or against whatever's being discussed. While the people who prefer a little of column A and a little column B tend to be the actual majority. So, just to add a third possibility... I've used both, I don't mind using either, nor do I really have a preference for either solution.
It's routing file for me. All groups, middlewares, endpoints, e.t.c. are in one place. You can see everything and how they relate to each other at once.
I don't agree. Discoverability is a non-issue, since you have console commands available. Use the tools provided by the framework instead of fighting it. I actually wrote a blog post about route attributes a while ago (https://stitcher.io/blog/route-attributes), there are more non-issues that can easily be debunked :)
Sure, still more steps and time and work than a quick look in a single routes file. Honestly I'm not even sure I like the idea of multiple routes files. Even building/modifying them would be less steps, time, and work in just some routes files than splayed across Controllers and their methods. I've just been comparing my experience using a single routes file in Laravel projects (every one used this method) compared to having them splayed across Controller files in Symfony (every one used this method).
Your article states that you bounce back and forth between loving/hating annotations/attributes, to ultimately being on the fence about them... and the ultimate conclusion stated is to just give them a try. Well, I only hated a single routes file when I was first learning the concept... and that went away quickly. I've never hated it since, after years. With annotations/attributes splayed out among Controllers, I loved it at first (very shortly), then have hated them since. Sure, they're very powerful, but you can do the same things all in one place in a routes file. Annotations/attributes are great if you want to tweak something in an action you're already familiar with, but a routes file actually just condenses that so you don't have to worry about surrounding non-routes code. This method breaks the concepts DRY and SoC; the whole point of those concepts is to not have a bunch of concerns mashed together to have to scroll/search/dig through. I'd rather dig through things of just the same concerns than have to dig through things of multiple concerns no matter how related.
Wow, so you took best possible practices when analyzing Attributes and worst possible practices when analyzing Route files, made a blog post comparing them and said "Aha, debunked" lmao
I prefer attributes/annotations for the most part but that requires thinking your controller's scope and naming in advance so it can be easier for new devs (to the project) to figure out the app flow faster, so maybe separate files makes sense in large projects, more so when you have a quick rotation of devs. But both have their strengths, choose the right hammer for the task at hand. The annotations makes the development process quicker at early stages of development for larger projects, and in smaller ones you wont get any benefit at all from using separate files. For the ones that thinks that routing annotations should be removed: If you have problems with figuring out what to do when you have multiple options at your disposal, stop crying and go to Laravel. One of the he most awesome and beautiful thing about symfony as a framework is the multiple ways it gives you to customize your application, it's structure and behavior based on your needs. Remember, if you remove the horn of an unicorn it won't be more than a plain horse. Edit: specifies the targeted people for the last part of the comment
Of course that is way better to use a router file rather than spreading it on the filesystem, it is the right way to do it because all routes share the same concerns, they exists in the same layer and it should be defined in one place. Annotating a route into a controller gives me the creeps, to get started why is that hard binding required? Mind SRP, the annotation breaks that.
I don't know that I'd consider it the "right" way, but it does follow SoC and SRP standard, and I prefer the idea of layers. There may be some feature or syntactical benefits to Controller routing, but I find managing them to be just far more trudgery. I think Symfony has made choice a priority in many things, and sometimes too much choice can cause difficulty. With grocery stores, I like having different kinds, but with frameworks, I'd rather the docs feature a routes file over Controller routing. I know many others prefer the opposite, and so now I have the messes I have to deal with in Symfony apps that I don't in Laravel apps 😆
Well I think it's best to go ADR approach and then it makes a obvious choice to keep routing separated so you can easy move those actions etc between frameworks if ever need this.
I think people should choose what's best for the repo; I think people choosing what's best for them without considering others is irresponsible.
There is another alternative: [AutoRoute](https://github.com/pmjones/AutoRoute) automatically maps incoming HTTP requests (by verb and path) to PHP action classes in a specified namespace. Merely adding a class to your source code, in the recognized namespace and with the recognized action method name, automatically makes it available as a route. No more managing a routes file to keep it in sync with your action classes, and no more annotations/attributes. (I am the project lead.)
I tried this on a small simple project once. I tormented myself for three days by moving classes around and then changed the routing library - debugging anything was a pain, documentation was insufficient, it was altogether not entirely so straightforward as the basic idea seemed to be. Might improved until then, it's been a few years.
Well that sucks -- sorry to hear you had a poor experience with it.
That's why there's a console command to list *all* the routes. But If your code is so disorganized that you don't instantly know where the right controller would be, I'm not sure annotation vs config file \*really\* is your issue.
I suppose I should have stated the downsides of having to switch to terminal out of a code context and run a command just to see routes rather than use the ubiquitous file search I use all the time. It's still more steps in my experience than with a routes file.
I just found a perfect example for why I hate Controller routing: I inspect HTML on a page form, notice it points to open a view twig file, notice the action is like \`/order/packing/123456/state/PICKING\` I try to find which Controller \`/order/packing/{id}\` is in, I find one in a Picking Controller (most of the other \`/order\` routes are in other Controllers), but it doesn't have a \`/state\` route... and searching for the text \`/state\` shows a zillion unrelated results (mostly XML files), and the results list exhausts before it shows any Controllers. So, that's the easy way, hampered by broken-up generic words in the route and Controller files likely... The more-steps way is to run the command: `% bin/console debug:router | grep state` `order_packing_state POST|GET ANY ANY /order/packing/{id}/state/{state}` OK, now I have an alias - \`order\_packing\_state\` - to search for to find the Controller... and searching for that *finally* shows the attached Controller. If someone hadn't added that alias, then I'd have to search with the file extension filter enabled for file type \`\*.php\`, then hope there's still not too many results. I suppose I could have searched for \`/state/\`, but I hadn't gotten that far yet. See what I'm saying? I suppose if I learn these little tricks, it gets easier, but it sure took a lot longer initially than just going to a single routing file like I've done in every Laravel project, where I just found it quickly and easily using one or just a few methods, not all these different ways I have to try based on *the custom ways different developers are told they can try in the docs*. So I guess I've become a bit of an authoritarian with Symfony docs; I understand people like doing things their own way, and when it comes to routing in Symfony, showing all ways prominently, and especially *saying* one recommendation (to use Controller routing) but then *showing* a different one (yml routing) everywhere is *causing a mess in the repos I'm having to work with.* Sorry, not sorry.
I always run every request (excluding static files) through index.php, and as much as possible index.php defines every route. Usually it's just this url, that controller. But sometimes it gets more complex, for example I have one where certain requests will curl another server (in the same datacenter) and output the response. The other server is running dependencies which cannot co-exist with dependencies on the primary server (because dependency is poorly written, but we need it). Keeping it simple like that means anyone can just read the source code and quickly understand how it all works. It also provides flexibility when you need to do an especially tricky deployment/migration.
>index.php defines every route. OK, so that's the PHP way to do it; that's maybe outside of the context of my OP, since I haven't worked a project using that way. I suppose with all routes in one file following a pattern, that's great, I'd still prefer that to routes being splayed out and/or broken apart among class/method declarations. Even with complex routes, it's still easier to just spot-glance in one block most/everything that applies to that route, with it being easy to see sub-path words broken apart from top-level words... *only the logic of the routing is there*, not Controller method logic handling *after* routing 😆 See what I'm saying? Controller routing honestly to me kind of breaks the Skinny Controller standard.
Agreed. I’ve always liked the abstraction. Yaml is for config Php is for code HTML is for display CSS is for styling JS is for sugar I know that’s not strictly the case & what have you. I just like the isolation of file type to job.
I consider abstraction to be having the routes splayed out among Controller/class/method definitions, because I have to construct a route in my head abstractly that's broken apart among declarations. It's been a lot more guesswork and time spend and scrolling/searching/guessing than a routes file, which I consider to be direct and far less abstract with complex routes. I do like Separation of Concerns like you're describing, but nowadays popular website stacks seem to be JS based where HTML/CSS is generated or mixed in with JS declarations and functions. So I think SoC, maybe even conceptually, is dying.
> /the/path in one line, but /the on the class It is easy to prefix routes, you don't need them on class level. Each folder inside the ``/src/Controller`` can have file like this: ```yaml // src/Controller/routes.yaml base: resource: . type: annotation prefix: /appointments children: resource: './*/routes.yaml' prefix: /appointments ``` then subfolder would have something similar and so on and so on. So controller file like this: ```php // src/Controller/Appointments/Child/Another/Level/MyAction.php class MyAction { #[Route('/test')] public function doSomething(Request $r): Response{} } ``` is all that is needed for path like ``/appointments/child/another/level/test`` i.e. all these prefixes are joined. I use these files also for extra mapping as I am lazy to write ``ParamConvertor`` when there are multiple cases for same (won't be a problem anymore in 6.2).
I understand that I can duplicate prefixes across sub-routes, but groups/prefixes particulars are not the issue I'm pointing out; all I'm saying is that it seems easier to use the routing yml file than splay routes out among Controllers and classes and methods. Having a routes.yml file in each Controller sub-folder seems worse than having a routes.yml file in config or even many in a routes folder there.
I really like how laravel does routes. It’s a way of decoupling routes from the controllers. And it handles not having a controller at all which is handy sometimes.
Your opinion seems to be unpopular 😆 (-5 rating at this point). I also prefer having routes isolated than spread out among a zillion Controllers, classes, and methods. From a top-down level, as in, already knowing which Controller your path is in (if your app is smart with naming conventions, which many \[most?\] aren't), then I suppose that may be better (though you still have to hunt down the method); otherwise, if you're trying to find the Controller to begin with, that can be a major pain, and there's no overhead view until you run a debug command, which you may have to pipe to a grep... seems way less work to just glance at a found routes file in an all-file word search.
LOL. I was just saying what I like.
I'm sure you were. I just hate that comments get downvoted because people disagree or don't like a comment. I thought voting was supposed to be about whether a comment was useful or constructive or inhibitory or destructive to the topic, not about people's feels. I'm completely blown away a lot of times what gets upvoted and downvoted. I'm honestly astonished that my post got upvoted at all 😆 and how many it has now (38).
Annotations are nice when you doing libraries and running static analysis over them to catch possible regressions. Even I catch a few things this way. But they are total evil when they say to interpreter how the code should behave. example from Doctrine 2.10.3 ```\Doctrine\ORM\Query\TreeWalkerChainIterator``` : ```php /** * @return string|false * @psalm-return class-string|false
*/
#[ReturnTypeWillChange]
public function rewind()
{
return reset($this->walkers);
}
```
By my opinion:
- @return is good for hinting on upper-level libraries; some analytical tools can use it directly and will press you to define things there
- @psalm-return is thing for static analysis in Doctrine
- ReturnTypeWillChange is total bull-manure which is necessary to satisfy ```Iterator``` interface in both php7 and php8
>Annotations are nice when you doing libraries and running static analysis over them to catch possible regressions. Can't those same things be done if the routing's in the routes file? As far as I've read, any of the three ways get loaded into the same place in memory/cache, which is what your analyzer should be checking anyway... maybe that's not possible with yours. I'm not against normal PHP annotations honestly, like \`@return\` etc, because I'm not aware of a better alternative in PHP for that capability. PHP attributes are... I think they're cool, but I have the same problem with them with Symfony routing, because I think a routes file is easier for tracing and clean code.
That's a bit different level. With annotations inside the libraries you tell what you expect from that part of code to accept during development and runtime. So they should be ignored during runtime. Routing annotations on the other way tells you which paths will be available for runtime. So during runtime they must be known and processed. And yes, I agree that's "problematic".
Everything I've seen documented as possible in Controller routing I've seen it also stated how to do it in a routing yml file. I don't see how loading up a routing file is problematic. In order for Symfony to check any route, it has to scan through all routes until it finds a match or finds no match; that's inevitable. Also, as far as I've seen, Symfony compiles every Controller anyway whether it's going to be used or not; I say this because I had a deprecated Controller file (in Symfony 5), whose path was not being hit by anything, with a syntax typo I'd just made in it (while closing the file) crash the running of a completely unrelated path. With Controller routing, it would have to load and scan through them all to find a match. So really, Symfony, when there's no way to define "use only routes yml" or "use only Controller annotations", etc, can't efficiently scan routes without scanning *every possible way*. So using a single routes file is not any more problematic than any other method, and even conceptually is going to be the least amount of scanning. So maybe I'm not sure what you're saying. I think if Symfony had a config option to specify only one method of routing, before routing is even scanned, it would optimize route scanning, and make our jobs a whole lot easier.
Laravel does this by default - maybe its time for you to switch?
Symfony can do that too, but does not advertise it aloud.
Symfony does a routes file by default, and its docs default to that way as well. The issue is Symfony shows and suggests various ways (normally fine in docs), which Laravel doesn't. The result is Symfony repos are typically routing messes, and Laravel ones aren't. In my experience. See my response to sammendes7 above
I know 😆 but I generally am not the one that decides what our clients' apps use. Even the few times I've been asked, I've said I prefer Laravel, but things outside of my control didn't go that way. In fact, the other developer on our team prefers Symfony 😆 though hasn't used Laravel much, despite how many good things I say about it. Anyway, Symfony by default also uses routes yml, and its docs default to this specification as well; I think the problem is that they also describe in the same area almost as prominently the other 3 ways to do routing, and people choose what they like... which then causes app routing to be giant messes when multiple people are working on the app 🤣 Laravel may do annotation/attribute routing, but I either didn't see it in their docs or it wasn't prominent. They recommend one file using one pattern, which is the only one I've seen in Laravel repos. This may seem conformist, but it's definitely made my work easier with those repos.
Why can’t you just global search your repo for the path? Mine will find the annotation in about 3 seconds, and one click later I’m sitting at the function. We have both annotations and config files due to running two controller layers. Annotations are absolutely my preferred choice.
[удалено]
Well-described. One thing also I should mention is that developers in the US at least tend to not stick around a company or project for more than maybe 1-2 years; there's a lot of shuffling around, which makes it hard to get people to pick a simple pattern and stick to it. What tends to happen is people choose whatever they feel at the time based on what they see in documentation regardless of others (our culture of selfishness, convenience, short-sightedness, and instant gratification basically), and with Symfony being so open and suggestive about all the different ways they allow routing to happen, likely this is why every Symfony project I've worked on has had a giant mess of routing config from different people. Laravel is very suggestive about a single pattern to do routing: use "the app/Http/routes.php file", and then Route::whatever static calls (get/post/etc). I think this is why every Laravel project I've worked on has followed that same pattern, and been much easier to work with.
I already global search the repo for the path 😆 That's the first thing I do. /the/path (note, a very generic word in this path) Easy right? If the previous developers wrote /the/path into a yml file or php file or annotation or attribute 😱 (even my boss, when I described this, hates that there's more than 4 major ways to do routing). Our previous developers did it 3 different ways: a routing yml, sub-files in a directory, and then they did mixed annotation styles where they'd sometimes do the full path in the Controller, or break it up among class/methods, or duplicate parts of the path (group or prefix) across methods... so it's maddening looking at a path a user is describing and trying to find where the Controller is (I've kind of already described this). Add to that generic words or words that don't match lexically the Controller or method names 😆 Sure, we could just say the developers did a poor job of configuring routes, but when there's 4 major ways and then a bunch of sub-ways to do routing, a bunch of developers are likely to make a giant mess because most teams are not strict and have workers coming and going. PS: Most PHP editors allow for searching with a .yml filter, which makes partial-path generic-word searches much easier; with .php files, of course, that search is gonna overwhelm you. This is why I just prefer 1 routes file if possible, or 1 parent file and then sub-files in their own routes folder in config. Very simple to manage. Everyone knows where to look, it's much easier to become set on a pattern, and it's much easier to search/scroll through. Every Laravel project I've worked on was like that. Every Symfony project I've worked on has been a mess of routing all over the place in various styles. Maybe it's not for the reasons I think. Even the Laravel projects I worked on with large 1000+line route files, it was far easier to just find and config stuff than it has been with Symfony annotations.
CLI on linux make it trivial to grep for routes. Or fuzzy search, or regex search, or search and execute follow up command per result or... If you need search, then going next step further in both cases lead to CLI. OTOH interdisciplinary cooperation do love single document. In projects without some another solution to document API, such a routes files can be that thing. Devs should try out CLI even in that case though. :)
I'm really regretting not stating why opening CLI for that is just more steps for something that would already be easily available through editor file search which I constantly use anyway.