 I'm going to try and get these slides posted later. The biggest problem is probably going to be some of the screenshots and some of the screencast style recording. So hopefully those all come out OK online as well. So how many people have actually heard about Symphony Flex? OK, how many people have used it? OK, that's not a whole lot of people. So one of the things that I've noticed about Symphony Flex over the last year is that it seems to be difficult to really know what Symphony Flex is. A lot of people might look at it and think it might be a new Symphony version, but that's not really true. What Symphony Flex is, is a new way to manage and install Symphony applications. How many people are Symphony developers or work in Symphony projects? OK, so you're pretty familiar with how to manage Symphony applications, bundles and stalls and things like that. One of the things that Fabian looked at when he was working on creating Symphony 4 is how to build modern-day applications. Modern-day applications don't necessarily start with something like what Symphony Standard Edition starts with. The idea is that you want to start with small dependencies, just what you want, and then add as you go. And up until recently, the way that you would make that decision in the Symphony ecosystem would be to choose between Silex or Symphony. How many people are Silex users? OK, a handful of people. The problem with Silex is that it's Symphony-ish, but it's not quite Symphony. So you can't just take your Silex application and easily upgrade it to a Symphony application. It is, however, really easy to get running. Symphony, on the other hand, takes a little bit of work to get up and running on an application, especially if you start with the Standard Edition. You might have to remove some bundles. You have to look at a bunch of configurations that you might not need yet. There's all this stuff there. So trying to decide up front which framework you want to start with is kind of a pain. And really, the framework shouldn't be getting in the way. Within the Symphony ecosystem, it should just be easy to decide how to start an application. So about a year ago, when I saw somebody say, hey, should I try Slim or Silex? I don't have anything against Slim. But I thought, you know what? Why don't you try Symphony Flex? Use Symphony Flex to build your application. And with most things on Twitter, context is important, and being able to say the right thing and the right amount of characters is difficult. And I was quickly corrected and told, oh, but how can you compare Flex to Silex? It's really just a composer plugin. That is actually what Symphony Flex is. It's a composer plugin. So the pushback on this is correct and valid. But to say it's just a composer plugin sort of undersells how powerful Flex really is. If you read the documentation, the documentation is going to tell you that Symphony Flex automates the most common tasks of Symphony applications, like installing bundles and other composer dependencies. And if you're just reading that at a high level, you might be thinking, big deal. So what? We have composer for that, right? We can install bundles with composer. But if you think about the whole bundle install dance that you have to go through, it actually is a lot more complicated than just installing a bundle package. Typically, you're going to run composer require with the bundle. You're going to have to make sure and go in and register this bundle inside app kernel.php. You might have to add some routing. So you have to go into your routing configuration file and add the resources for the routes. You're going to have to go into the actual app configuration to potentially add some of the, I can't remember the word, but basically the semantic configuration language for that bundle. So you might have a top level key now with this bundle and different things that you need to set for it. Oh, and also if you have certain things that are install specific, like tokens and things like that, you have to go into parameters.yaml to try and update those. So you get this bundle all installed. And maybe you actually had several bundles that that bundle depended on. And now you've got all of those installed. Oops, you don't want it anymore. Do you want to remove it? How many people have tried to remove Symphony bundles before? How many people enjoyed that experience? Yeah, no hands, awesome. So the way you remove bundles is you do the same thing, but in reverse. You have to remember all of the configuration keys that need to be removed, because if you remove that bundle, Symphony is now no longer going to be able to parse your configuration files. If you leave the bundle in app kernel.php, that class no longer exists. So it's not going to be able to do anything with that. So your app may not work for a while while you try to remember all of the places that you have to go to remove that bundle. And this isn't really as rare as it might sound. If you look at all of the major bundles out there, they all have the same thing at the top, the same five or six steps of the things you need to do in order to install their bundle. So really what Flex was all about is trying to find a way to automate this. It really wouldn't make sense to automate Composer Require, because that's something that we're already doing already as developers. That should be maybe the only step that you have to do. Should we be able to automate bundle registration? Yes, we probably can, but it's going to require changing some of the ways that Symphony handles bundle registration. So these are changes that were put into Symphony 3334 and is now the default for Symphony 4. Similarly, route configurations are the same thing. These are things that can be automated if things change a little bit in the way that Symphony looks at how routes are configured. The actual service configurations, same story, and local configuration. Local configuration, in the case of Symphony Flex and Symphony 4, go into .emv. So it's following the 12-factor environment controls rather than doing things in the parameters at YAML file. So if we really wanted to still what Symphony Flex is going to have the most impact on for you, it's to automate the installation of removal of bundles. And it makes the whole process a lot easier to understand. And it's able to do this by leveraging the conventions and features from Symphony 4. If you have a Symphony 33 or a Symphony 34 application, you can start using Flex already. The only thing that you have to do is migrate the directory structure from Symphony 2 and Symphony pre-33 to the Symphony 4 layout. If you do that, then you can start using Symphony 4 for your Symphony 33 and 34 applications as well. A lot of the nice things that happen as a part of the whole developer experience behind Symphony Flex come from a lot of the features and conventions that came into Symphony 4. So we're looking at things like auto-configuring. How many people have used Symphony 4 auto-configuring? A couple of people. There's also some feature detection. There's auto-wiring, things like that. So there's a lot of stuff put into Symphony 4 that just go really well with the way that Symphony Flex is set up. So if we go back to this question of, is Sylex actually something that you could compare with Symphony Flex? Fabian actually spent a bunch of time working on a bunch of old Sylex applications that he'd built, things like the Twig website, things like some of the other specific Sensio Labs little project sites, were originally Sylex applications. And in order to dog food, Flex, and Symphony 4, he decided to move these applications to use Symphony 4 and Flex. And what he found was that he loved it. It felt just like Sylex, except it wasn't Sylex. It was still using the full stack Symphony framework. So really, the question no longer is valid. You don't really choose between Sylex and Symphony, depending on if you want a micro framework and you need to start smaller. If you have a huge monolith of an application, you can use Symphony Flex and Symphony for both. So really, we can say there's no Sylex. There really isn't. And if you want proof of that about just under a month ago, the Symphony team announced that Sylex is going to be end of life, I think, in June of this year. So there is not even going to be a question anymore about whether we're going to use Sylex or Symphony. It's all going to be Symphony. Another thing that people might think is that Symphony Flex is a new Symphony edition. If you have heard about the standard edition, there was this idea early on that there would be different editions of Symphony, or different distributions of Symphony. The Symphony standard edition was the primary one that people would start with. And if you look at the repository for the standard edition, you'll see that it looks like an application layout. It looks like what you expect from a Symphony application. If you look at something like the rest edition, you'll see that it looks very similar. There's a couple of things added, maybe some things removed. The big differences are the set of dependencies and the configuration that it's done up front for the things that are specific to the rest edition, as opposed to the standard edition. So Symphony Flex is all about starting small. At least that's what it can seem like. And if you look at the ecosystem that existed previously, it would be easy to say, oh, well, we already had the empty edition. The empty edition, of course, being something that doesn't have a lot in it. However, if you look at the way that the empty edition is set up, it looks identical to the others, almost, with a few differences. The big things are probably in the composer JSON file. It uses less things. But if you wanted to then upgrade your Symphony empty edition application to the rest edition, and then maybe the API edition, there's really no way to do that. And the problem is that these distributions, this notion of building a base application and then extending it as you go, is the wrong abstraction for what we really want to do as we're building up a project. What Symphony Flex does is promote composition over inheritance. This lets you actually build your application using pieces without having to just start in one place and then move on from there. And a really good example of this is to show the Symphony 4 skeleton. And the skeleton is probably the closest analogy there is to what we originally had as the standard edition. This is the whole project for a Symphony Flex-based Symphony 4 application. It's a single composer JSON file. And if we look at that file, it doesn't have a lot in it. It has the Flex extension, it has a console, it has Framework Bundle, and it has YAML. Those are the only really big applications that are going to be in there. Of course, those have additional dependencies, but at its core, this is what we're looking at for starting a brand new Symphony 4 application using Symphony Flex. In order to create a new project with Symphony Flex, you use Composer, just like you normally would for many other projects out there. You create a project, you specify a Symphony skeleton as the project that you're basing it off of, and then you give it a new name. So even though this project starts out with just a Composer JSON file, if you look at what you actually end up with in your project directory, you're gonna see something similar to what you would have seen from the standard edition. The directories are gonna be a little different because they're now based on Symphony 4 conventions, but it's pretty much the same thing that you would expect to see if you're already familiar with Symphony. The important thing, and I'm gonna mention this a few times, is that the files that you do see here are all created based on the packages that were installed using Symphony Flex. So the framework bundle, for example, you'll see there's the framework YAML file under config, that is there because the framework bundle was installed. If you didn't have framework bundle, that wouldn't be there. Framework bundle wouldn't not be there, but if it was another dependency, it wouldn't be there unless the bundle was actually in place. So the files that are created, all of the boilerplate, all of the overhead of installing bundles is now handled by Symphony Flex, and it's handled on an install by install basis as you install bundles. If you wanna build another kitchen sink style skeleton, you can totally do that. This is the website skeleton. Again, it's just a composer JSON file, and the only big differences here are that it has a bunch of new dependencies. We see things like the security bundle, we see the serializer, we see Swiftmailer added there, we see Webpack on core. So we're adding additional things to this. And the creation is the same way. You would specify website skeleton, and the project that you end up with has a lot more files in it. And these are all files that are created by Symphony Flex because these additional bundles have been installed. So for example, we see the Swiftmailer YAML, we see WebProbFiler, we see monologue, we see some doctrine things. So all of these things are depending on which things you add. And it's not just at creation time, if you add these bundles after the fact, or if you remove bundles, these configuration files will just start showing up and going away. So really what Symphony Flex does is it removes and replaces a Symphony installer. There is no such thing anymore. Flex is the installer, but it's just a composer plugin. It also replaces and removes the Symphony additions. So these are all really awesome things, but how does this actually work? Like what is Flex actually doing? Flex works with something called recipes and packs. These are the main things that we're going to be looking at. And recipes will be the first thing because they're the most important. Anytime you run a composer require and then some package name, if Symphony Flex is installed in that product or in that package, it's going to look at symphony.sh and it's going to look to see if that particular package has a recipe available. So if we go to symphony.sh right now, we can type in Framework Bundle and we'll see that Symphony Framework Bundle is indeed there. You can then go to the recipe, which takes you to the symphony slash recipes repository in the Symphony Framework Bundle directory. That top level 3.3 means that there's a recipe available for a minimum version of 3.3. So 3.3, 3.4, 4.0 are all going to use this same recipe. And within that directory, we're going to find a manifest.json. This is actually the recipe itself. So from this recipe, it defines all the things that need to be done within the symphony application to get this bundle working. The first thing at the top, you'll see bundles. You'll see that it says that it's going to install the Framework Bundle and it has all. All means it's going to be available for all environments. So whether it's prod, dev or test, this one's going to be available for all of them. If we look at the website bundle, if we look at the web skeleton-based project we've created, we'll see Framework Bundle at the top. And all of these bundles were added automatically by flex. So as bundles are added or created, if the recipe has a bundle's line in it, it will add the bundles appropriately. And we'll see some of these here have different things than all. So for example, debug bundle is only available for dev and test. So if you install this in production, the debug bundle isn't going to be there. So this is one of the major changes to the way that the bundle stuff is handled for Symphony 4 so that we're able to programmatically add and remove these things a little more easily. The next line we see copy from recipe. And what copy from recipe does is allows you to copy files from the recipe repository itself into the application once it's created. So here we see that we're copying files from config, public, and sourcer. So if we want to look at the Symphony 4 front controller and where that comes from, that ends up in public slash index.php. So if we look at the repository for the recipe, we see there's public slash index.php. So this file is copied into the applications index.php file in the public folder. And if we go into the project that was installed, we'll see that that is where index.php lives. So it lives in public slash index.php. Recipes can also include composer commands that can run after install or after update. So in the case of Framework Bundle, every time you do a composer thing, Framework Bundle is going to make sure that the cache is cleared and the simulates are updated. There's also the ENV section. So this defines the things that will end up in your .env and your .env.dist. If we see here, we see app.env is set to dev. So by default, the application is always going to be in dev mode. AppSecret has a special value there. If you don't know how easy that is to read, but it's a special string that says generate secret. And what that does is it will replace that environment variable with a unique ID. And if we look at the project and look at our ENV, we'll see here that at the top, we see Symphony Framework Bundle, app.env equals dev.appsecret, and then there's a randomly generated value. So the application is able to, or Flex is able to create the stuff for you so that you have a working, mostly working dev configuration environment without having to go in and update everything for you. And if you notice the little bits above and below each of these sections, this is how Flex is able to programmatically add and remove things as bundles come away. So for example, if we wanted to take the website bundle or the website skeleton, but we don't want to do anything with Swiftmailer, we can compose or remove Swiftmailer, and it's actually gonna remove the environment variables for us as well. Likewise, there's a get ignore section that does the same sort of thing for get ignore. So here we can see we're automatically ignoring the .env, public bundles, var, and vendor. If we look at the next one below is Symphony Webpack Encore. It's ignoring public builds and node modules. If we decide we don't want to do Webpack Encore anymore and we remove the Webpack Encore bundle, it will remove that from the get ignore for us, programmatically based on the recipes. Symphony Flex also adds a notion of aliases to composer require. With Symphony Flex, you're able to do composer require twig and it works. And the way that that works is that the recipes, if you look up the recipe for twig, you'll see that there's a alias listed for twig bundle. So if you require twig bundle, or if you require twig, it's actually gonna go get twig bundle for you. And if we look at the manifest JSON for it, we'll see that at the bottom it says aliases, twig, template, and templates. What the Symphony SH thing does, it also offers the Symphony core team some level of curation of projects. And the way that the packages are broken down are into official versus contrib. The official packages are packages that are endorsed by the Symphony core team. And the contrib packages are just those that aren't. So these are community packages that people want to register because they want to have flex recipes to install their third party bundles, but they aren't necessarily things that the Symphony core team has spent a lot of time working on or approve. So this lets the Symphony core team be a little more opinionated. And especially since the official bundles I think are the only ones that can define aliases, it means that we can do, or the Symphony core team can do things like composer require admin. So rather than having to go to packages and look for symphony space admin and find which one you want to install, if you want to install the one that the Symphony core team recommends, all you have to do is require admin. Same for things like ORM. If you want to get doctrine ORM, you can just do it by doing composer require ORM because that's the official project that Symphony is backing. Earlier I mentioned there were recipes in packs. Packs are really just metadata packages on packages. So if we want to look at the Symphony ORM pack, you'll see it just has a composer JSON and its whole job is to define the dependencies that are related to the ORM pack. So there isn't a whole lot else there that does that. If we look at ORM pack on Symphony SH, we can go check out its recipe and all it really has is aliases. So and its aliases are a little interesting. Its alias is ORM. What this means is that if you compose or require ORM, what it's really going to do behind the scenes is compose or require ORM pack, which behind the scenes is essentially going to require doctrine ORM, doctrine bundle, and doctrine migrations bundle. So by requiring just ORM, the pack allows you to do some interesting things. But it doesn't necessarily work the same way as other composer packages. So we're gonna take an example here of the composer JSON of a freshly installed Symphony IV application with no other dependencies. We're gonna require ORM and we can see right here at the top it says requiring Symphony ORM pack. So we can already see that it's resolved that. And now we're gonna look at the composer JSON after install and even though it installed like 30 packages or 20 packages, it only says Symphony ORM pack in composer JSON. If we remove, we're gonna see it's going to remove a bunch of these packages, all of the doctrine packages and some Zen framework packages. It removed them all. And if we look at the composer JSON, it's back to where it started. So if you start working with Symphony flex packages and you end up seeing things that don't really make sense sometimes, it might be Symphony flex doing this magic of creating these packs where the pack gets installed, it installs a bunch of stuff because of it, but it doesn't show you that. It's just showing you that you installed the pack. It can be a little confusing if you don't know what you're looking for. Another downside to the contrib recipes is that they are not installable by default. So even though you can search for them on Symphony SH, your application can't actually install them. In order to be able to install them, you need to set a configuration value to allow contrib to true. So once you do this, when you start trying to do recipes for these contrib recipes, it'll let you install them. An example of a contrib recipe would be for UUID doctrine. You can see by the little orange label there that that is contrib versus the green official label. So we've taken a look at this now, kind of like a high level, sort of what it's doing. So what I'd like to do is walk through coming up with a really simple Hello World app using Symphony flex to bootstrap a project. So we're gonna go ahead and get started by creating a project called My New Project. We're gonna create it based on Symphony Skeleton, so it's gonna be the minimal framework. One of the things that it's going to do here is install flex first. It's the first dependency that's going to get installed. And what we'll see is shortly after that, we're gonna have this prefetching thing that you might not have seen before. This is Symphony Flex's way to say it overrides the downloader for composing. Composer so that it can do asynchronous requests, so it's gonna do it like a curl multi-type thing. So it can download all of the packages before it actually tries to install them. So it can speed up that part quite a bit. Toward the top there, after it generated the autoload files, you're gonna see that it's found four recipes. So there were recipes for Symphony Flex, Framework Bundle, Console and Routing. So it's actually gonna do some configuration for those. And then it gives you a little bit of help. And this little bit of help comes from a file called postinstall.txt that lives inside the recipe. So this was inside the recipe for Framework Bundle. And this is actually where I get to do my first bit of deciding how I want to work with things. It's going to tell me that I can go ahead and go to the directory that I just created the project in, and I can use PHP's built-in web server. So I can do that pretty easily. Or if I want to, I can require the server. So I can do...Composer requires server in dev mode so that I have console commands for server start, server run, server stop. I think server status. But I don't need any of these things because I'm using Laravel valet. How many people are using Laravel valet? Okay, cool. So I have Laravel valet set up between all of my Sculpin projects, all of my Laravel projects, all of my Symphony projects. It's all going through the same place. So I don't need this. So I'm not going to actually do that. So I'm going to load up the directory structure next and see exactly what was installed visually. So I'm going to run the tree command, and I'm going to see that all together with excluding the var and the vendor directory, we've created eight directors and 13 files. So this is the bare bones Symphony application. And if I load this up through my web server, I'm going to see a debug error message that essentially happens if you hit a Symphony application in debug mode without any routes displayed. So I'm getting that sort of error message here, which makes sense. I don't actually have any routes anywhere. This application is empty. So I'm going to want to do something a little nicer than just working with strings. So I'm going to use twig. So I'm going to jump back to my project now and I'm going to require twig. And what we're going to see is that it's downloading. It's prefetching the dependencies again. Then it installs twig for me, twig bridge and twig bundle, and then it configures twig bundle. It's also going to warn me that files may have been added or edited. Every time we do these commands, if you look, it says some files may have been created or updated to configure your new packages. We know those are there. We're not going to take a look at them, that any time you do one of these things, there might be things that you need to add to get. So I have twig now. My next step is going to be to create a controller. I don't really want to go in and remember how to create a symphony controller right now. So I'm going to use the new maker bundle. It's just a simple package that lets you automatically create things like entities, controllers, twig extensions, that sort of thing. So I'm going to composer require maker, and everything's good to go. So what I'm going to do now is do console bin, make controller, home controller, and everything should be happy, right? But it's not. And this is getting to another sort of feature that is available now because of the way that Flex works, is that the symphony packages no longer have to be super strict about what things they actually depend on. So the maker bundle itself relies on the annotations bundle, or relies on annotations in the case that you need annotations for what you're making. So if I were to create a twig extension, I might not need annotations. So I would totally be able to use this without any other dependencies for some of the things that I can make. But for controllers, I actually need annotations. So I'm going to accept this. So I'm going to go ahead and run the command to require annotations. And here we can see annotations as an alias for sencio framework extra bundle. So that's at the very top, so we can see where that's actually resolving too. And it installed seven packages, installed a bunch of document things, and then sencio framework extra bundle. So now I should be able to hopefully create my controller. So once again, I'm going to do bin console, make controller, home controller. And what we get is a nice little success message, which is awesome. So we're going to go now to our project and open up the source directory. The controller directory now has home controller. And what I'm going to do right off is change the path on the route to just slash, because I actually want this to be the slash route. I'm going to leave the boilerplate body that they gave me that uses the maker demo page, twig template. And I just want to see what it looks like. So I visit the site now, and it works. It gave me the slash route actually renders something. It's rendering the demo HTML code, but it actually works. So the next thing I want to do is actually customize this output. And this is really going to be bare bones, hello world type stuff, but it should work. So we're going to hop back into the IDE. And we are going to change from the maker bundle to use a template called home HTML, our home HTML twig. Remove the other junk around there and create a file called home HTML twig inside the templates directory. If you're new to Symphony 4, the templates directory is where all of the twig stuff goes from now on. Previously it was in other locations, but this is just a top level templates directory. You'll see that also as soon as you install the twig bundle, it gives you a baseline base HTML dot twig. So that's there. So this little hello world thing is going to extend the application's base HTML twig, which I'm not going to do anything to right now, but that's where you would go build the shell of your application. So running this through the web browser gives you an incredibly awesome hello world, which might not seem super impressive, but we've done zero configuration. We've gone from nothing to templating to creating a controller and having everything work without having to actually do any Symphony configuration. Flex did everything for us to make this actually possible. And this can get you far. Maybe you're going to take this hello world application. Now you're going to build out a couple of, you know, splash pages, landing pages, something like that, up until you want to actually start building your database layer. Or maybe you want to build some sort of front-end that does some interesting stuff. What you would be able to do then is go into your application and require the ARM. And it's going to download everything that you need, configure everything with the exception of the... in the ENV of being able to choose the driver type that you want to use and making sure that the doctrine version is correct for the MySQL version. You can now start building your front-end application and start building, you know, entities. Now it would actually make sense to use the Maker Bundle to make an entity. You can go along like that until all of a sudden you realize you need some back-end stuff. So you don't want to build your own custom back-end just yet. So you want to use the canned admin functionality. So what you can do is composer require admin. And now it's going to create an application that lives in slash admin on your application. And it's installed, it's configured, everything is right. You'd have to go in and modify one configuration file to list the entities, but otherwise it should work out of the box. And once you get to the point where you've created your own custom back-end, all you have to do is remove it. Composer remove admin and now you no longer have to deal with the admin package at all. And you can move on with your own application. So Symphony Flex, it's really about making the developer experience a lot better for managing your application over time. It doesn't really do anything new or exciting except does some stuff that was probably really boring and error-prone automatically for you so you don't have to do it anymore. And a lot of this is possible thanks to the direction that Symphony 4 went in in terms of changing how some of the default structures were handled, how bundles were handled, that sort of thing. But again, Symphony 3-3 and 3-4 will support this as well. How many people have 3-3 or 3-4 applications that they're working on? How many might consider changing your directory structure to try Flex? A couple people? Cool. So yeah, definitely this is all the default for Symphony 4 right now. It is optional, but it is the default way to handle installing and managing Symphony 4 applications, and it is all possible to use in Symphony 3-3 and 3-4, but it does require more work. That part's not super easy right now. And that's all for now.