Bundles, No Bundles and AppBundle in 10 Steps

Hey Andreas!

You also make a really solid point, and one that I also agree with. Haha, funny how that can happen :). In fact, I *do* think that your point is the biggest potential risk of the new structure. But - as I think we both point out - the benefits/goal of this conversation is aimed at lowering the learning curve (and I think those "minor" benefits are not so minor for them), and so far, I've seen - in my totally subjective experience - the advantages to the AppBundle out-weigh the disadvantages. If that's true, it may be because by the time you are creating or digging into 3rd party bundles, you've comfortable enough to pick up on the small changes easily. Regardless, I'll have my "ear to the pavement" on this (and I hope everyone else will), and we can shape things going forward.

And yes about 3.0! That's our chance to make this be as natural as we really want it to be. But we should nail that down. Do you have some specific things that would make "app" feel more native in 3.0? Is it that the controllers and resources should be "closer"? Is it the missing bundle shortcuts (e.g. _controller, entity auto-aliasing, etc) if you only had an app/? Let me know - I've been thinking about this lately, and you have to answer me before you nice holiday :).

Cheers!

I don't care much about directory structure, as long as things belonging to a single context are not mixed with other contexts. /app/src and /app/resources would be fine, or /src and /resources, whatever...

For me it's mostly about various shortcuts and conventions, some examples:

• Make the ControllerResolver/ControllerNameParser capable of handling a format like "MyController:index" for "application level controllers"

• Streamline template reference syntax to work cleanly with and without bundles (using Puli?)

• Fixing Doctrine shortcuts, possibly using a reserved prefix, or better: no prefix if they don't belong to a bundle (from the top of my head, I don't know if this is easily possible)

• Fix the TemplateGuesser to be able to work with the @Template annotation outside of bundles (I know you discourage the annotation, but still ;))

• Create an equivalent to a DI Extension class for the application as a point to manipulate services. While you could do that in the kernel, this would IMO be more clean and simple. Should also be entirely optional, since not required for all use cases.

@Andreas This is a *wonderful* list - I hadn't put this many ideas into my head yet this clearly. Now you've got me thinking! :D

Thank you!

Hey Mauricio Escudero

Thanks for your kind words :)
I just want to inform you that the app structure changed considerable in Symfony4, but it comes with a lot of handy tools, like services auto-registering & auto-configuring

If you want to know more, you can check our series on Symfony4 (the first course is totally free) https://knpuniversity.com/t...

Cheers!

i will for sure give it a read, i'm at the moment migrating from 2.8 to 3.4 so this is right up my alley right now, thx a lot!

That's a fine way to do it indeed - especially once you know what you're doing (but if beginners follow high-quality bundles like Sylius stuff, they may over-engineer things). You can also use sub-directories inside Entity in the one bundle if you like that better. Your call :).

Hi Stefan!

Of course the answer is, it doesn't matter! Ok, but more usefully, I have created a structure like "assets/sass" before (at the root) and logically, "app/assets/sass" makes even more sense to me (though it's a little bit deeper to make your frontend developer dig, if you have one). For me, the "app/" directory is my "application", not src - so I'm putting more and more stuff there, and less and less in src/ (except PHP classes of course).

Cheers!

Hi Dragan!

Ok, great questions! We don't (in the documentation) cover *how* to make decoupled, re-usable bundles very much, mostly because it affects a very small number of people. There is an article about the best practices, which isn't a "tutorial", but might help: http://symfony.com/doc/curr.... For your specific questions:

A) "treat it like a true, decoupled bundle" *basically* means that everything should live *inside* that bundle/directory. If you follow this completely, you'll naturally end up doing all the right things. Practically speaking, this means: put your templates in the bundle, put a routing file in your bundle and force your app to simply import it, add a DependencyInjection/**Extension class that automatically imports any service configuration (e.g. services.yml/xml) that your bundle has. Generally speaking, I add decoupled bundles in src/ first for simplicity, then move them to their own separate repository later. But you can do that in whatever order.

B) You *can* use the bundle generate if you want (it asks you if this is a reusable bundle, and makes different decisions). If you're not too comfortable with what a bundle needs/doesn't need, do this. But generally, your bundle doesn't *need* anything, besides the bundle class and - for a re-usable bundle - the DependencyInjection/**Extension setup, which I believe the generator will give you :)

C) Yes to using the vendor namespace! We use KnpU for our bundles (shorter than KnpUniversity) - using your GitHub name or some other handle (if this isn't for a specific company) is very common :).

D) And yes, following existing examples is the best way - and pretty much any open source bundle is a good example. Our KnpUOAuth2ClientBundle is a *small* example, which might be helpful: https://github.com/knpunive.... It shows off the most important "special" thing about re-usable bundles: the DependencyInjection/**Extension setup that loads a services.xml file: https://github.com/knpunive.... It also has a "functional" test - in case you want to test your standalone bundle: https://github.com/knpunive...

I hope that helps - good luck!

Thank you so much for your reply. I ended up following the current best practices, your knpu oauth bundle, and your tutorial on composer packages. You guys are awesome at KnpU. Keep up the excellent work!

Hey Fabien!

More or less, yes :). Almost 4 years later, Symfony has gone from multiple bundles per app to 1 bundle to app (AppBundle) to *zero* bundles in Symfony 4. A lot of the arguments here are still relevant, and are the reasons why that change has been made over time.

Cheers!

Hey Kevin!

You know, the location of the views folder is one of those silly, subjective things, but I also think it's a bit buried! One thing (in 3.0) that we could do it - at least - remove the app/Resources directory to simply app/, so we have app/views, app/translations, etc. Of course, you can already do this, but you get what I mean - recommending this approach is bigger. Moving it all the way to the top level is in many ways even more interesting. But I'm worried that we'll run into resistance due to multi-kernel projects. Then again, since those users are more advanced, you *could* start with a directory structure with everything in "app/" at the root, and *then* tell multiple-kernel people (it would be an easy doc) to create sub-directories for kernels and move those few things into it (views, config, the kernel class, etc).

Thoughts on that?

I would be in favor of moving the contents of `app/Resources` to just `app/`. For bundle overrides, I even think something like `app/bundles/TwigBundle/views/...` would be better. I can never remember if it is `app/Resources/TwigBundle/views` or `app/Resources/views/TwigBundle` or `app/Resources/TwigBundle/Resources/views`.

I feel the app folder is like the "metadata" for my app and I don't feel views fall into that category.

I thought multi-kernel projects were rare but after talking to some people in NY it is not as rare I thought... But, I wouldn't say it is common and it requires some advanced knowledge. What I don't know is if views are shared between kernels. If even one view is shared, it makes sense to move the views to the project root.

I went one step further. I wanted my controller code and templates to be in the same directory so I would not have to switch back and forth. So I have a master Action directory with sub-directories for each individual action. The sub-directories contain the action controller code, the templates as well as any other helper classes that belong to an individual action such as form types. Works for me.

"action controller code" - I'm curious how you have this. Is each action in a class by itself?

Yep. Not as bad as it may sound since many different routes end up using the exact same controller action. All done with services.

I didn't think it sounded bad :)

Are you using __invoke()?

I tend not to use invoke mostly because I still have 5.3 servers and because I like to use meaningful names even if I only have one action method in a class.

Hey Adam!

I agree with some of your points here for sure. And yet, I still think that if we put everything into bundles, we end up with a more-easily-organized, but more complex project. I want things to be organized *and* have the "wins" of the AppBundle idea. I think there are a number of problems - like how to organize a single bundle / no bundle in a way that's just as nice as multiple bundles - to solve cleanly and publicize. Basically, I want us to "have our cake and eat it too". And afterall, the way we use bundles means that they really are basically just directories. We need to find the final directory structure that avoids the situation you're talking about. I think we need to be asking those questions right now (meandmymonkey has some good points on this) and getting a nice, final solution for 3.0. Right now, I will agree that we don't have a perfect solution (so the preference is subjective). I want to find the structure that's a win for everyone.

Thanks!

Hi Philipp!

I don't know if there's a best practice, but it's a *great* question and use-case. Heck, I would like to hear what other people think. I would say:

A) Separating between multiple repositories and sharing via Composer is probably not realistic for most people - it's just too difficult to manage. I do know one HUGE company that actually releases bundles/libraries internally like this, but they have an entire team that just works on those "internal open source" libraries.

B) For *how* to architect this, I see 3 options (and maybe you see some more):

1) One big project (and one kernel) - that has CLI stuff, backend stuff and frontend stuff. It's the most monolithic, but probably the easiest.

2) One big project, but multiple kernels. It's easy to manage like (1), but has some slightly less overhead because of the multiple kernels.

3) One big project (like 2), but separated even more into totally different directories. For example - backend/, which holds configuration, source code, web directory (e.g. backend/web) for everything in the "backend" app - then console/, which holds everything for your console app. For shared things, you could put them into a shared src/ directory. So, the root structure might be backend/, console/, frontend/ and src/. This is kind of a mixture of (2) and totally different projects.

4) Totally separate projects (microservices like you said). This is probably the best-practice, but the hardest to manage. I use this a bit with KnpU, but I'll admit I have problems sharing code between them (lack of time to properly isolate things into a Composer package).

I'd love to know your (or others') ideas on this :).

Cheers!

Hi Ryan, thanks for your suggestions and hey, it does not seem to be that easy ;-)
From the dev perspective, I would love to have a single project, but a) I need to do independant releases of all applications to different enviroments b) I only want to deploy what's actually needed, so the deployed CLI code should only be for the CLI.
I see there is some discussion going on on Twitter, thanks!
But I've also seen a project having the model stuff in a separate repo manged via Composer and yes, that's a big mess. Changes need to be done in 2 repos at the same time, other devs need to be informed, versioning becomes a pain etc.

Indeed - not so simple :). For others, here's the relevant conversation on Twitter: https://twitter.com/weaverr... - with Jon's tweet being particularly helpful (and summarizing what many people said): https://twitter.com/jwage/s....

In summary, option (3) seems to be what people favor, though some people recommend going all the way to (4) if you can manage it.

Cheers!

Option (3) sounds interesting. Some questions remain about how to deploy separately to different environments (depending on traffic and 3rd party software) but this should be solvable. And if possible, I'll also consider option (4) next time.

Thanks Ryan for promoting this discussion!