 There might be some ways to do things different, but don't get too much grief there. It works, it works very well. All right, yes, this is on. Hello, guys. We're getting started. There might be a few more people that come in. Yeah, there was a wave. That was excellent. Hey. Hey. Welcome to... Well, you guys have been here all day. Welcome to DrupalCon. This is especially nice for me because I used to live in Nashville, so it's like coming back home, seeing all the new cranes that are going up. How many people have been to Nashville before? How long ago? 15 years ago. 15 years ago. Yeah, yeah, yeah. So it was probably like a one block by one block radius 15 years ago. And now it's like 100 times bigger. So yeah, it's kind of crazy. How many people are staying downtown? Good. Okay, cool. I'm actually really happy about that. It sounds where you want to be, hotel space is kind of hard. So I'm glad that you guys figured that out. We're like a lift ride away. Anyways, let's kind of get rolling here. And actually, you know what? Total speaker foul. Give me one second because I have my remote and I was sitting up here forgetting to put on that in there. When I say something significant, I like to move around. So this will make everyone's life a little bit more interesting if I can. Yes. Okay. All right, back to it. Okay. So hello, my name is Ryan. As you know, I used to live in Nashville. I come from the symphony world. So like my Drupal skills are so, so I know a lot about how Drupal works because of all the symphony pieces in there. My day job is I'm a writer for campuniversity.com. How many people have heard of that? Oh, quite a few. Awesome. So we're like, we're in the symphony world primarily. So I say like the Drupalized me of the symphony world. So apparently I'm not doing such a bad job at marketing because you guys have found us. That's great. I'm also a total symphony fan boy, evangelist for them. And much more importantly, I'm the husband of the much more talented and beautiful Liana who normally comes to Drupalcon because she actually works with me and she loves it here and she has more friends here than I do, but she is not here this time. Although if you want to tweet at her, you totally should. If you have your phone with you, that's her Twitter right there. You want to tweet and just say hi from Drupalcon. That would be awesome because two things. First, she designed the slides. They were horrible when I sent them to her and she made them pretty. So it's all, it's good for all of us. It's going to be much more entertaining. The second thing is the reason she's not here is because she's at home with that guy. So that's the real work. I get to come here and like talk to you guys and do fun stuff. She is being a mom this week. So she's hanging out with my son Beckett. This is where I get to show pictures, right? There's another picture and that's really the one that sort of encompasses him. And actually now he's a little older and that's him enjoying the spring flowers. We actually came to Nashville last week for spring break. And so there's some flowers from Nashville we were smelling. And then I flew back and I flew back here. All right. Anyways, and there's Liana's Twitter handle. You're still typing that down so you can harass her. That would be excellent. Okay. So you guys Drupal crowd, you guys have a superpower and that is that you know Drupal. That is no small feat. Most people that don't know Drupal would be like, whoa, I do not want to learn Drupal. That is a big thing. So there's a lot of knowledge in this room right now. And that is going to unlock us in a lot of ways to be able to do other really cool stuff. So Drupal 8 and I put this as an intermediate level. So hopefully you guys have some knowledge about, you know, some of the Drupal 8 symphony isms in there. I'm going to introduce those. Drupal 8 leverages a lot of modern stuff, OOP, namespaces, and a lot of pieces that come directly from symphony. So the routing and controller layer, the service container, these are literal things that are run by the symphony components. Which means if you went into a symphony project, they would look exactly the same. So there's many places in a Drupal project where you could like copy and paste a file and do a symphony project and it would just work. So this is symphony with a question mark because I want to clarify real quick what symphony is and what symphony is not. You may already know this, but what symphony really is is a collection of small libraries. I did a talk last year about some of the more interesting symphony libraries. The library solves one little problem and that's it. So there's like 45 of them or something like that. And you could be in a flat PHP project or in a Joomla project or something. Something that doesn't use any parts of symphony and you could pull in one little piece and use it. That's symphony. We call them the components. They're the little libraries. So there's also the symphony framework, which is when we take all of those components and we glue them together so that you have a coherent experience of building a web application that uses all of those components. It's a project. So what's interesting is Drupal is also sort of a glue that ties all the symphony components together. So what exactly is the difference between Drupal and symphony? Where are the similarities? What are the differences? Other than horrible technical debt, which is being worked off actively. And we have our own technical debt, but yeah. So one of the goals of this presentation is to be able to draw the parallels between Drupal and symphony. So when you go into a symphony project, you're like, oh yeah, I've seen this exact thing in Drupal. I understand the concept. I'm able to bring it over. So Drupal, from my perspective, what it is is it's a route and controller system. How many people have created a route and a controller in Drupal 8? Perfect. I was hoping most hands would go up. Yeah, because I'm not going to explain routes and controllers. It's a route and controller system, aka hook menu in Drupal 7, basically. And then it's a container full of services. Services are useful objects. So it's a container full of objects that are tools. And that's it. And those services, those are really what do everything. They are services for talking to the database, translating things, resolving aliases back into nodes, the theming layer, the thing that processes render arrays. Those are all services. So every single thing that really makes Drupal a CMS and adds all the CMS features are these service objects. And in a default to Drupal install, I think there's like 700 of them floating around. And they're like little robots that are all doing different things to bring the whole experience together. So Symphony is actually the same thing. It's a route and controller system. And it has that exact same container, except when you start a project, it's basically empty. So Symphony is a route and controller layer. That's it. So imagine that's the only thing you can do in Drupal is like create a route and create a controller and then go have a sandwich. That's basically Symphony in the beginning. So yeah, another way to say it is imagine Drupal where you were able to uninstall every single module, including core modules. And there would be absolutely nothing left except for that route controller system. That is Symphony. So Symphony, the nice thing with Symphony is, again, the pitch here is when you have that project that doesn't need a CMS behind it, that Symphony is going to be a really good fit because of all the things that you already know. So one of the nice things about Symphony when you have those projects is it's very small. It's lean and mean. It's fast. And there's not a lot of files to look at. So as far as trying to figure out what the project doesn't, doesn't, you're not looking at a giant project. You're looking at something very small. And the key difference, and you're going to see it over and over and over again in this presentation, is that with Drupal, you have all these features out of the box. With Symphony, you have nothing. And then every time you need a feature, you're just going to install it. So again, imagine Drupal, we had no modules. And so whenever you needed something, you're like, well, let's install this module. Let's install the node module. Let's install all these other modules so you actually piece your system together as you need to. All right, so let's code. By the way, I do have the code for this down in the bottom. That's a bitly link, dcon18-symphony. And I'll have another link on the end for, to the, to the, to all that link again at the end. But if you want to like check my work as we're going along, that's how to do it. So the way that you start a project in Symphony is a composer create-project. How many people have used that command in composer before? Okay, yeah, yeah, a decent number of people. It's a, it's a glorified command that basically clones a repository. So symphony slash skeleton is literally github.com slash symphony slash skeleton. It's just a github project. It just clones that down, moves into it and runs composer install. So it's just a way to clone a project. So there's nothing super interesting going on with that command. And of course, this is what it looks like. It downloads of all the dependencies that are already in that project. Okay? The, no, no, no, no, no. Actually, let me, let me go, let's go this way. The interesting thing and really weird thing about that symphony skeleton is that this is what it looks like. That is a symphony, a brand new symphony project. It is exactly one file in it. And it's composer.json. Weird, right? But you'll notice something else that's special. This is back from the composer install command. So yeah, download stuff, yay. But at the very end, you see it kind of gives you this like nice message about what to do next. So one of the key things that's in that composer.json file is a special composer plugin called symphony flex. And symphony flex powers the symphony for experience. It's a composer plugin that does, well, we'll talk about what it does later. But for right now, it at least gives us nice fancy message at the end. And it's going to do other important things later. Actually, I'll tell you what one of them are, one of those things is now because here's the mysterious thing. We went from one file and after we ran composer install, we suddenly had about 15 files. So that's actually a superpower of symphony flex. When you install a package with composer, some of those packages have recipes. Think of them as like little installation scripts. And so as you install a library, if that library has a recipe, flex will actually add, like install that recipe in your system, which does things like create directories, create configuration files. So the idea is that we start with nothing and then as you install packages, the package is going to take care of adding any configuration that's needed so that you can just use it immediately. So the trick with making symphony for start so small was that when you start with nothing, it's really annoying to add new stuff because you're like, oh, we'll just install that package and then configure this file and create this directory and do these other things that are needed to pull that into your project. So flex just automates that process for you so you can just install stuff and it just works. So anyways, we do start really, you know, there's one file, but in reality you end up starting with 15 files. Fun fact, if you remove a package, it also undoes the recipe. So you could actually, you could actually one by one composer remove the packages and compose it at JSON and it would undo those things until you got back to just a single lonely file and actually uninstall the recipes. So at this point we have 15 files and that's counting random files like get ignore files. 15 files and no database because there's nothing in symphony, routing in controller layer. So we're going to start the built-in PHP web server just for simplicity, you can use Nginx or whatever. So we have a built-in web server running at local host colon 8000. We can go to local host colon 8000 and just to make people feel really nice, we have a cute little welcome page in development mode. But really we have nothing. All right, so let's start building stuff. I want to create an API endpoint. That's a really common thing to do with symphony. You know, you have this little internal project. You need a couple API endpoints. Let's just use something simple for it. So there's a two-stop process for building a page and guess what, since most hands went up when I asked if you had built a routing controller in Drupal, it's copy and paste the same in symphony. So we're actually going to create the controller first. That's the function that builds the page and I'm sorry, that's a little bit difficult to read. Hold on one second, one second, one second. No, no, I was thinking about inverting the colors, but they'll make everything else look weird. So we write a function that builds the page. I'm using a JSON function that's a shortcut that comes with symphony. Pretty obvious what that does is just going to JSON, you know, return that string or that array down there as JSON. So that's the function that builds the page. Look at the location for this. It's in the SRC controller directory. I'm going to show you guys where I'm modifying the files in a second. Yeah, I'll come back to that in a second. So anyways, we have this controller, it's song controller, and the method is API write song. Okay, I'm just making those names up. The second thing is we're going to create the route and we're doing this in a routes.yaml file. Almost exactly like you would do in a custom Drupal module. In fact, it's exactly the same. It's just a different file name that you're putting this into. And there's the path slash api slash songs and the controller is just the class name app slash controller slash song controller colon colon api write song. And that's it. These are the two files that we just modified. And looking at the directory structure, I want you to think of a symphony project as basically a module. So like almost like pretending you're zoomed into a custom module and we're doing everything inside of that. So in fact, you can see in a custom module there's a source directory and that's where you put all of your PHP classes. It's the exact same inside of symphony. There's a source module and that's where you put all your classes. In Drupal 8, your namespaces need to be Drupal slash the module name slash whatever else you have. In symphony, it's just app. So you'll notice that like my namespace was app slash whatever directory I'm in. So a little shorter, but same basic idea. And really, the other thing is the routes file that's in a config directory. So in a Drupal module, that would be what? Like the module name dot routing dot yaml. Inside of here, it's config slash routes dot yaml. Just the file names different, but the concepts are exactly the same. And that's basically it. There's a couple other directories, but we're going to do everything in source or config. If it's a PHP class, it goes in source. If it's a config file, it goes in the config directory and that's what we're going to do pretty much all of our work. All right. Oh yeah. So of course, I was so busy to explain things. I forgot to tell you about our awesome project, our country music song generator. So this is our first generated song here. There's some mud. It's very inspiring. And we're going to basically keep hacking on this idea. Oh, fun fact. I did not need to rebuild any cache. So that's a great reason to use symphony. There's no rebuilding of cache, no cache rebuild, no Drush stuff. You just, there's no hidden things going on. I modified one file. I modified another file. I refreshed the page. It worked. All right. So our project is still very small. We have the service container. We have the routing system and we have about 50 services that support that system. But there's like, I've been saying there's nothing else inside the project at all other than that. So there's no templating, no database, no logging, no Koopa Troopas. There's absolutely nothing. All right. So the mantra on symphony four is if you need something, you just install it. Okay. Oh, and also Drupal modules, you know, you install contrib modules in symphony. They're called bundles. They basically serve the same purpose. The main reason, the main thing that installing an external bundle gives you is it adds more services to your container, adds more tools. It's kind of the same thing with the Drupal module. When you install an outside Drupal module, Drupal modules can give you a lot of things. They can give you like new menu links and new forms and routes and things like that. But one of the other main things they give you is they oftentimes give you more services in your container, a new tool to use or some new event listener that causes some magic to happen inside of Drupal. So that's a really good analogy there. Modules and bundles are really the same idea. All right, so the first feature that I want to install is annotation support. How many people know what annotations are? Okay, good, good, good. Most hands again. You'll see them in a second so don't panic if your hand didn't go up. So I'm going to run Composer Require Annotations. Does that look weird to anybody? It's not namespaced. It's not namespaced. Yeah, it's like, shouldn't it be something slash annotations, like symphony slash annotations? Yes-ish. All right, so we'll send Koopa Troop over here. He's going to run that command. So Composer Require Annotations, that's the second superpower of Flex. The first superpower, and we're going to see a couple examples of it, is that recipe system. You install a package, and it actually configures some files and adds some directories for us. The second one is the alias system, which is basically a way for us to give shortcut commands. So here it says Composer Require Annotations, and right under there though it says updating version 5.14, sencio slash framework dash extra dash bundle. That's actually the package that's being installed. There's just a little shortcut resolution system. And the idea is basically that we want there to be one, I want there to be like an easy way. If you need a feature, like a logger, you just say Composer Require Logger. And whatever one is the one that symphony thinks is the best one that's going to work, then that's the one that's going to install. If you want to install a different one, great. But you can just say Composer Require Logger and it works. Question? Ah, good. What directory am I running Composer from? Everything's happening at like the root of my project. And so I said, think of my project like a custom module. Yeah, yeah, yeah. And so in that custom module also, when you have a custom module, your custom module can also have a Composer.json file. So it's the same thing here. Application as a Composer.json file. So we're running this from the absolute root of our application. So the alias system, so there's a website, it's called symphony.sh. And you can go there and actually they'll show you all the packages that exist in the symphony sphere and it'll tell you the aliases. So you can see there's apparently one called API Platform slash API Pack. And below it's a little small, but you see it has an alias called API. We're actually going to install that package later. So it's kind of just a nice cute feature, but it's not that important. The second thing is the recipe system. And so after it installs the packages, on the bottom you can see it says, like symphony operations, two recipes. And it says configuring some library and configuring another library. And that's it actually taking care of whatever the recipe needs to do for those packages. And we're going to see a couple examples of that. All right, so once now, the reason I installed the annotations library is that in symphony, instead of you doing YAML routes, you can choose to use annotations for routing. It's actually the way that we do it most of the time. So instead of there being two steps to create a page, there's actually just this one step. You just go to your controller. This is the existing controller. And you add annotations above your controller that say that the URL is slash API slash songs. And that's it. So you don't have to touch the YAML file anymore. You're good to go. All right, so let's go up. Now we decide that we want to render a template. Well, we know there's no templating system. So we do compose a required twig. Now we know that that is a alias for something. We don't really care. Something twig-related. It's going to install twig for us. And it's probably going to configure a recipe. And in fact, yes, we can see there's one recipe being installed below. Now here's the twig is a really, really good example of how useful the recipes are. Because one of the things that the recipe did is it created a configuration file, config packages twig.yaml. And in there, it configured the twig package. And don't worry about the specifics too much. But like from space, what you can see is happening here is actually configuring twig in our project and telling the twig system that our templates are going to live in a templates directory at the root of our project. So this is a really cool thing because like somewhere, no matter what system you're working with, like a templating system, someone has to decide where the templates live or where the translation files should live. And this is either going to be some configuration that's like hard-coded deep in the heart of Symphony or deep in the heart of Drupal. Like there's some line that says translation files will live here. Templates will live here. If you dig deep enough in Drupal's core or Symphony's core, you can find that. Or the other alternative is you force the user to configure this. That has the advantage of like clarity, right? Like I don't have to wonder why my templates live in the templates directory because I created a configuration file and I specified where they live. The downside of that one is it sucks to install stuff because it means when I install something, then I need to go create a configuration file. You know, it's the whole convention over configuration. Well, Symphony basically does the opposite. We do configuration over convention. We want things to be explicit in your project, easy to change. But fortunately, because of the recipes, it's not a pain in the butt to set up because the recipe is going to do it for you. So every time I install a package, I look and see what the recipe did because the recipe is almost like a tutorial for how to use that particular library. In this case, I can see it created this configuration file and it also created the templates directory. So suddenly, I didn't have a templates directory before, but now I have a templates directory and pretty easy for me to look in the project and figure out where I should put the templates. So I'm going to go back and create another page. So I'm going to go back to my same controller class, create another public function in there. I'm using the annotation routing. So my at route slash another dash song. And this time there's a render shortcut. That's how you render templates in Symphony. This arrow render and I have the file name there, which I'll show you on the next slide and I'm passing in a variable. Or actually show you right here. So I'm sorry that that purple is not the best to see. So I'm rendering a template called song slash another song dot html dot twig. And that's going to map to templates slash song slash another song dot html dot twig and then I have some twig code. Not going to go into the specifics of the twig code there, but this is basically me just using that feature. So in this case, I touch the controller and I touch the template and the templates directory. And see that base dot html dot twig. That's the default base layout file that you can customize and add styles and all that too. And that was also installed when we installed the twig recipe. So basically said, okay, here's your starting base layout and now you can customize it. So you didn't have to try to create that on your own. Oh, and then of course it works. So we can go directly to local host colon eight thousand slash another song. No cash rebuilding and our, you know, our message shows up. Cool. All right. So let's keep drawing concepts to each other. So Drupal console. I assume everybody has used Drupal console at this point. Yeah. Okay. How many people have used Drupal console? Yeah. Okay. Good. Yeah. I asked it in the, in the wrong way. And I only saw a couple of hands. I got, I got worried there. So Drupal console is awesome. We have been console. It's already installed. It's literally a direct directory called bin. There's a file called console. So bin slash console and it is just like Drupal console. It's full of debugging stuff. It's full of well later code generation stuff. So we can run bin console debug colon twig. This is kind of cool. Cause it shows us all the custom functions and filters that exist inside of twig. Cause twig has like a core set of functions and filters, but when you use it in Drupal or when you use it in symphony, like more are added that are specific to symphony or Drupal. So this is like just a running list of all the custom functions and filters. Debug router. That's a Drupal console is the same thing. It gives you a list of all the routes in the system. And there's several other debug commands. So that same exact concept exists. It's used the same way and you get it out of the box. All right. So what about like, let's talk about debugging, better debugging tools. So I assume that a lot of you guys use Devel, use Kent something inside of there. So we have, well, it's a little bit different, but basically we have something similar to develop. It gives you a lot of the same tools. And we can install it with just composer require debug. And this is just going to install a suite of debugging tools. Now two important things. Actually, I'm going to fast forward here. As soon as you install this, so composer require debug, you refresh the page and you have the web debug toolbar on the bottom. See that black thing along the bottom? That just boom shows up. And that's, first of all, that's like the best thing ever. Web, there's a web profiler module in Drupal 8. A lot of you probably already use it. If you haven't look up the web profiler module in Drupal 8. It's a sub module under Devel. It's that for Drupal 8. It's awesome. So this is like full of debugging information, performance information, database queries, all kinds of information right there at your fingertips. What I wanted to highlight was, this is back when we ran the composer command, composer required debug, is the package it actually installed on the second line there is called symphony slash debug dash pack. And that's not a super important concept, but it's a new concept inside of symphony. And it's basically the idea that sometimes we want people to be able to run one composer require command and install like eight different libraries. Because debug is not actually installing just one library. It's us basically saying, well, if you want debugging tools, you probably want these five libraries. Like this installs logging, it installs the web profiler, it installs a few other things. So it's a super simple composer trick. You just create a new repository that's empty and it's a composer.json file. Make it require those five libraries. And then from people's projects, they can just require that one library and they get five different libraries in reality. We call them packs. So that's what's going on behind the scenes here. Fun fact, like the only tricky thing with packs are they're like, you can't handle versioning. This is giving you version 1.0, but since it's downloading five libraries, you might be downloading this one at this version and this one at this version, this one at this version. And later, what if you want to kind of control the version of those specific things? Well, the only thing in your composer.json file is just, you know, symphony slash debug pack at version 1. So there's another command that Flex gives you into composer. You can run composer unpack and then say composer unpack debug. And what it does is it replaces that one line in your composer.json with the five independent libraries at their versions. So today you can just composer require debug, but then later when you actually care and want to control the individual versions, you can basically have it explode the lines in composer.json so then you can control the versions yourself. All right, cool. So I mentioned this earlier, you know, like our containers started very small and as we install more things, we're getting more services. So one of the services that we just got was the logger service. We did not have a logger at all before. It's part of the debug pack that we got the logger service. So in Drupal 8, the way that we fetched services, the cheating way that we fetched services is with Drupal colon colon get container and then we can say get and we can provide the machine name for the service and get that service object back. Or you can do it the proper way. You use dependency injection. I'm not going to go into that. You know, you touch a YAML file usually to do that. But the point is like there's this container and you kind of like fetch the service out of the container by the machine name of the service. Symphony doesn't do that anymore. We have changed our tactic a little bit. We have the exact same container where we get things out of it in a different way. And the way we do it is whenever we want a service, we just type in an argument. This is actually normally done in construct functions of services, but it also works in controller functions. But normally this would be like the normal dependency injection where you have the public function construct. So you can just say logger interface logger and symphony will just give you the logger. And that's it. And you can just immediately call something on it. This is awesome because it lets you code super fast. You just type in what you want. It gives it to you. And guess what? Because you're type-inting it, you're writing good code, and your IDE is giving you auto-completion on logger interface. Or on the logger object. So how did I know logger interface was like the magic word? Because that's the thing, right? Like did I just sit down and cross my legs and think about that long enough? So you can't just know that that's the right thing. So we have a debug auto-wiring command. And this is awesome because this is basically going to list all of your tools. So you run debug auto-wiring, and it just gives you a list of types that you can use to type in just to get stuff. So you can see our logger interface right there in the middle, like that's how we get the logger. To above that, it's got a horrible name. That's not that guy's fault, but it sort of is. It's a cache item pool interface. That's the type that you use to get symphonies cache object, which is awesome. It's just got a terrible name. Yeah, that is your... No, that's not your fault. No, no, it's not your fault. I'm saying the guy who built the symphony cache component is sitting in the back of the room. But he didn't create that name. It actually came from PSR. They make the fig that makes the PSR rules. If you know what I'm talking about, it's cool if you don't. It's not that big of a deal. But there is a central organization in PHP that sometimes creates interfaces that the rest of the community follows, and they're the ones that created that name. End rant, it's just kind of an awful name. Anyways, that's how you get the cache object. This is all of our tools right here. You can type in these, and we're just going to pass them to you. You get really good errors if you type in something wrong. We kind of suggest something else. It's all really, really easy to use. All right, so let's say we want to organize some code. We're going to take our song generation up a notch and actually start creating random country songs. But to do this, we need maybe like 50 lines of code. 50 lines of code, perfect code that generates the next perfect country music song, okay? So instead of throwing this code in our controller, which we could totally do, 50 lines of code in our controller, we decide we want to isolate this to an external spot and so we can reuse it other places. This is the classic thing where you put it into a class and put a method in the class and kind of create your own service. So in Drupal, we do this exact thing. You just can go into your source directory of your module, create a class, put a function inside of there, register it as a service in a YAML file, and then go into your controller or a block or wherever and fetch that service out of the container. In Symphony, we thought that was too much work. So we have the same idea, but we shortcutted it. So this is our new song generator. This has nothing to do with Symphony. We just decided to create a new class called Song Generator. I put it in my source directory. It doesn't go anywhere. It has a public function. Yay. This is a nice-looking class. To use this... Again, there's nothing... I'm not skipping any steps here. Step one, create this file. Step two, to use this file, is to go into your controller, for example, and just type in it. Just type in Song Generator, and it's going to automatically pass that to you. If your Song Generator had a construct function that had a logger interface type int, then it would pass it the logger. And then, of course, it would still pass the Song Generator into your controller. So you just run around everywhere just using type ints and then Symphony wires that up for you so you don't have to go to a configuration file and do stuff. Yes, there are edge cases where you do need to go into a YAML file, but most of the time you can just... Most of the time, you just stay in PHP code. You just code and everything else happens. And if there's any doubt, because we don't know exactly what to pass you, then you get a clear error message, then you go to a YAML file and you just add a little hint for that one little situation. All right, so let's add a database, because we don't have a database yet, either. Composer-required doctrine. So Symphony doesn't have a database. You can use anything you want for the library that most people use is called doctrine. It's an independent library. So we're just going to composer-required doctrine. It installs a bunch of stuff. It configures a couple of recipes, which is great. It has another nice little helpful message on the bottom. Now one of the interesting things about the database that's unique so far is databases need configuration. Nothing yet has needed us input from us. When we install the logger, it just has defaults. We can change those defaults, but it logs to some file. It's fine. But the database actually needs some information from us. So it actually tells us on the bottom exactly what to do. You can modify your database URL config in .env. So the .env file, which is at the root of our project, is basically equivalent to the settings.php file. Settings.php file, of course, most famously has your database configuration. The .env file has any configuration that you don't want to commit to your repository. And these actually become environment variables that you reference later in your application. So it plays really good with Docker and stuff like that but it's not important for this. The cool thing is, as we install libraries, sometimes the recipes for those libraries know that they need some configuration. So they actually modify this .env file. So those lines you see there, those are actually added a second ago when we installed Doctrine. So all we need to do is just go in there and modify it. It's kind of handled adding that section for us. Once we've kind of configured our database there, to actually create the database with Doctrine, there's just a command to do that. So bin console, Doctrine database create, that creates your database behind the scenes. And, oh, and because by the way, if you can see up there, the database name is actually at the end of the connection string. So that's where it's getting the database name from. It creates a database but it's totally empty for now. So we need to actually start creating some tables in our database and do is actually start generating our country music songs and store them in some country music table so we can keep track of our brilliant ideas. So to help us do that, we're going to install another library called Composer Require Maker. And what this actually gives us is a bunch of new bin console commands. This is similar to what Drupal console does. They have all the generate commands. The word make is more hipster. So we used to call ours generate but we're trying to keep up with millennials. So we called ours make and so we have all these make commands. And we're going to go through a couple of them. So Doctrine, like Drupal, has an idea of entities and they're fairly different. Don't think they're the same thing but they're actually pretty good parallels to each other. So every time we want a database table, we're going to have a single entity class. So you'll create a class and this will map to a database table. So you can actually create these entity classes by hand. They just look like normal PHP classes but we also have a make colon entity command which makes it super easy to add stuff to your database. So in this case, it just starts asking us interactively what we want the class to be called. So we're going to call it country song and then it starts asking us to add fields. So we added a title field. It's a string type, which is kind of a doctrine type that I have in my R and my SQL. Title, field length. Can this field be nullable in the database? Cool. Then I kept going. I also added a created at field. It guessed that was a date time and then at the end I hit enter again and it's finished. The end result of this was that it created one file. It actually created two files but one of them is not important right now. It created one file, which is this file. It's called country song. It looks like a normal class with normal properties, the private ID, private title, and private created at. So it creates a property for every field that we want in the database. The way that doctor knows how that field maps the database is with annotations. So put annotations above the field and it just figures out, it helps it map that this field goes to this column in the database. So it's actually a pretty simple idea. The nice thing about that make entity command is it's not a one-time use command. So at this point you're free to modify this however you want. You can copy and paste the title field and make another field. That's totally cool. But if you'd like to generator, you can go back and run it again and give it the same class name and you can actually add more fields to it. It also does relationships. So you can create another entity and then say that you want like a many to one relationship. Start joining them together, many to many, many to one, one to one. So that's really the adder method so that everything is kind of hooked together in a really nice way. So it kind of automates it because one of the downsides of doctrine is if you wrote all of this by hand it actually gets to be a little bit laborious. So if you use the generator it just takes care of a lot of details for you. But the point is either way you just have a new PHP class. That's it. There's no database table yet. It has not touched the database at all yet. We just have this new class. To create the database table and this is super cool we have a command called make migration. So database migration, right? The way this works and it's just a doctrine superpower, I wish I could take credit for it because it's cool, is it looks at all of your entity classes. So right now we have one, but let's pretend we have ten. Looks at all of your entity classes, looks at your database, runs a diff between the two and then generates the MySQL code or if using Postgres, the Postgres code, whatever that you need to basically take your database to modify it to match what your entities look like. So in this case it's a simple create table but if we later went and added a new field with an annotation above it to country music, you would see it would be an alter table to add that one new field. So this is awesome. You just like change your entities, run this command and it generates a migration file for you. Then to execute that there's a command called doctor migrations migrates and it runs that. The way that works is because you guys are smart crowds, you're probably wondering this is it keeps, it has a database table and has a table in the database, that's redundant. It's a table in the database where it keeps track of all the migration files it's run. So when you run this command it looks at that table and it looks at your migration files and executes any new ones. So you'll run this locally every time you do it. And then when you push to production that command is just part of your deployment script so that it will run any migrations that haven't been run on production yet. So it's super easy to like modify the database and keep things in sync. Alright, so we have a database table, we have our entity so let's create a new API endpoint to save new country songs to the database. So we're actually going to kind of take over our existing API write song. One little change I made just to show it off is I added on the route on top I added methods equals post. Before it would match any HTTP method but if you want only have this be a post or a git or a patch or whatever you just add a methods equals and it works just fine. If you can see it on the end there again everything in symphony everything a Drupal shared concept is done by a service. So if you want to save something to the database the question is what's the service that does that? The service is called the entity manager in doctrine's case so just like before with our song generator or the logger we just figure out the type hint to use to get that it's the entity manager interface so if you ever need to save something to the database you type in entity manager interface it passes you that object and you're off to the races and here to actually create the entity I'm just saying song equals new country song so I'm just creating the normal PHP object there's nothing special about it I'm setting the title using the song generator to do that and then the way you save things in doctrine looks a little weird at first you call EM persist and pass it the object you want to save and then you call EM flush and the flush is actually when the operation happens the reason it's split is so that you could persist 10 things and then run one flush so we're kind of using your a lot of people are just seeing like save so it's two steps but it's the same thing behind the scenes and then I'm just going to return the JSON so same thing return this error JSON and I'm going to give it title field and an ID field and it's just going to work yep so I can send a curl request of that and it gets back our our new song so that was cool so we use that new tool the entity manager we save things the database creating the JSON was a little bit too much work it may not have seemed it but I actually did the title and ID field I basically made the JSON manual I was like here I have this really nice class it has an ID property a title property I created that property but then when I turn it to JSON I did it by hand like manually created the array so it definitely begs the question you're like could we just do that return this error JSON and just pass it the object and then that turns it into JSON who knows because they've made the mistake like I have many times who knows what happens when you JSON underscore encode like the PHP function JSON encode an object the answer like anything is it depends probably well in the case of in this case we would have an empty and empty JSON string an empty JSON you know curly open curly close curly it it actually does what you think it would do because you think maybe it just JSON encodes all the properties it does as long as they're public so since we made these private or you could use protected we get nothing back and in fact it doesn't work boo unless you install symphony serializer so it's like on that same thing of like if you need another tool just install it so behind the scenes this error JSON that function does is it checks to see if the serializer library is available and if it is it uses that and if it's not it falls back to just a normal JSON underscore encode like super simple type of a thing so compose require serializer and suddenly like that that actually does work so it's just a it's just a service it gives us a service gives us an object that's really good at turning things into into JSON or XML or whatever you want making a so this is another end point making a get endpoint is actually one line there this is a bit of a show off slide there's like a lot kind of going on here you guys see that the the route has slash api slash long slash curly brace ID you guys know from doing Drupal controllers that that normally means that we would have a dollar sign ID argument to our controller you know whatever you have in your curly brace you can have as an argument to your controller that's true here symphony also has an extra layer of magic and Drupal has this in a few places as well where if you want you can just type hint the entity name and it'll see the ID there and it'll just query for that by the ID because it'll see that ID is the name of a property on your country song and it just does the database query for you and if it's not there it throws a 404 and then we can just return this error JSON that object yes there are ways to do custom queries but a lot of times you don't need to because it's as simple as that so like that's nice we can also generate a crud this is just showing off some of the other features so one of the things that I love about the way that symphony 4 does things is like again we start really small that's really great and the project builds with you but as you've probably noticed there's a lot of installing things and most of the time the way you're going to figure this out is you're going to say I need a logger or I need a cache and you're going to Google for that and the docs are going to tell you right at the top great run composer require logger that's how you're going to know you're not going to have to be lost in the desert trying to figure out what to install but anywhere we can we try to give really clear error messages so if you try to use something that's not available we try to give you the exact composer command you need to do to do that so in this case I'm using the make crud because I want to just quickly get a crud for my country song but we're missing symphony's form system and a couple other pieces so it just spits out the composer require line for that so it's like cool it's all good just run these commands and you'll have what you need so then we actually can run make crud this only asks us one question which is basically what entity do you want to have a crud for so we enter country song and it generates us like those eight files or so and it looks like this it's ugly I know but that's symphony we don't give there's no theming layer out of the box we haven't added any styles to our page I'm using no styles right now but you have a fully functional crud area there that you can mess around with security actually I mentioned this in part because this is also relevant to Drupal it's just kind of a cool thing there's a library called security checker I have the alias up there but you can look it up it's like sensiolab slash security dash checker I think you can install this into your project and then when you do that well I think in Drupal you have to do one other thing but you actually have a bin console command you can run in symphony security colon check and it checks your compose.json against known cve vulnerabilities the versions of your dependencies and checks to see if you have any dependencies that have known security vulnerabilities security is not always the sexiest but this is a good thing to have flex also gives you a warning in general if you install something and it sees that there's a security problem also and no I'm not making any money off this which is why I get to talk about it symphony this is just launched a new service this is like security.symphony.com where you can actually upload your compose.json file and it will tell you if you have any security vulnerabilities again that actually applies to Drupal projects and the service here which costs like two euro a month is something where it will basically check that every single day and as soon as it suddenly sees that a cve has come out on one of your projects libraries that you use it will message you like hey last night security vulnerability came out for this library you need to upgrade other bonus oh man and if I if I skipped everything else if I was trying to sell you guys on symphony I could have skipped everything else and just come to this API platform this isn't a library API building library that's built on top of symphony and you already saw it's very easy to create API endpoints you create a route controller this error json you're good to go but obviously we know that in bigger APIs like things get more complicated really quickly so if you want a larger more robust API you just run composer require API that's going to install stuff it's going to do some recipes etc etc but you're just installing the library then step two is to go into your entity that's our country song entity and to add one new annotation on top at API resource then you have this huge API and documentation built automatically for you so this is actually what happens when you go to local host colon eight thousand slash API this is a swagger like API documentation if you've seen that before it's behind the scenes we actually now have a get post get get collection post get single get complete and put endpoints set up for that country song entity you can open any of those and actually like start playing with them so this is me expanding the documentation I can try out the endpoints and it'll actually tell me what you're getting back gives you the curl command if you want to run at the command line the post endpoint again you can play with that you can give it data you can actually submit and see what would happen or you can actually go directly to what did I want to say about that oh yeah and it's a super legit API it uses JSON, LD and Hydra if you're into like the super rest nerdy stuff it's like a super super robust API and yes I know everything that is enabled with just one line means that you're like you're thinking like how much of a pain in the ass is it to configure yes you can configure the heck out of things it's not a pain in the ass so that's really really really big sell for this thing and I didn't have not actually worked on it so I can't take any credit for it it's just a really really great thing that just works with symphony one command and you have it by the way if you wanted to try it out your symphony project you run composer require API mess around with it for an hour and if you didn't like it you run composer remove API it uninstalls the package and removes the recipe so any configuration files it created it just takes those out so you can try things out really quickly without having like a big cost you can do this one in because it's also freebie composer require admin then you go to one configuration file and you say that I want an admin section for my country song entity and then you can go to localhost colon 8000 slash admin and you have an admin section for that oh and bonus and this one is more of a shameless plug how many people have worked with webpack okay great how many people enjoyed working with webpack yeah probably the after effect but probably not the setup so if not in Drupal because Drupal mostly has its own system for handling assets and things like that but one of the libraries that we package with symphony but is actually 100% independent of symphony and 100% independent of PHP is a library called webpack on core and it basically makes using webpack really really easy so if you webpack is something that basically combines your css and js files and lets you like require javascript files from other things and process sass and do all kinds of crazy things with webpack on core you can do that in a configuration file that's really easy to read and it's like 12 lines long and you just set that up and you're off to the races behind the scenes it generates a webpack configuration file which is probably 300 lines long and that's what normally you have to do on your own if you use webpack I believe me because I did that and it was awful and so I was like we should create something to make that simpler so if you're interested in that just kind of write that name down so Drupal and symphony great awkward friends it's like not everything translates exactly Drupal has it's weird things symphony has it's weird things but there's so much of a core I'm not going to tell you that there's not going to be a learning curve in symphony but like there's so much overlap there's so much that you're not going to have to learn that you would have to learn if you use anything else so it's like a super super cool thing I mean it's the reason that I know how Drupal works I have no business knowing how Drupal works so if you use symphony and do it then I'm like yeah I get it this is cool so they both have routing controllers they both have a container difference of course is many services versus like few services in symphony the plugins are modules versus bundles console tool, Drupal console we have bin console so same exact concepts and of course we all have we all use OOP name spaces composer we use them in the exact same way you know and symphony starts really tiny and it's to be feels much like a micro framework when you download it in the beginning like here's your tiny project that's super easy to understand and we didn't give you 100 files we gave you like 10 files and it does just this one thing so it's easy to understand easy to maintain by the way side note symphony does a really good job with its backwards compatibility stuff so if you use a symphony project it's really easy to upgrade so you know I know that in the Drupal world you guys are the panes of upgrading so it's another thing if you use something with symphony you're not going to ever get stuck or screwed over or have some horrible upgrade path it's going to be the opposite so it starts small and you just install stuff and again symphony.sh is basically the key place you can go to see like all like the libraries that we recommend that you install so if you guys have a project that doesn't need a CMS it's kind of a home run so definitely try symphony and at the very least it's going to make your Drupal foo way more awesome too so you're going to see basically all those Drupal things that you've been using kind of in a different context and I get way better at it at the bottom here last thing I'll say is there's if you go to github.com slash weaver ryan and I know that I made the repository name as long as I could but you can actually see the finished code for what we built today so you can actually go in and dig in and try it out if you want to and that is it thank you guys and oh nice animation if you guys do want to learn more about symphony we have a free tutorial on campioniversity.com so go there and we have a symphony track and the first tutorial it's like an hour plus long it's totally free and it goes through a lot of the stuff should be fairly easy for you guys since you guys have been doing the exact same stuff inside of Drupal questions yep hello thanks for the reports and other some tools for local development in symphony world I heard about laver homestead is it good enough and any other tools maybe yeah so are there any tools specifically for development setups kind of things yeah so are there tools for development kind of setups in symphony and you mentioned laverval homestead which is something that helps you basically set up like a VM really easily we actually recommend using laverval homestead it's a nice tool it's made by laverval which is a different framework but they just made a nice tool that makes it really easy to boot up virtual machines and they have like a symphony flavor or something in it and it works really well is the idea of like a small symphony like Sylex is that idea still alive or is it part of symphony now so what's the deal with symphony symphony is small and there's Sylex which is the micro framework it's weak-hilled Sylex so Sylex has actually been deprecated and unless the community jumps in they won't have like further development so Sylex is a true micro framework everything's inside of like one file and yeah the goal was basically to make symphony as small as possible so that you didn't have to choose between the two because the problem was like before you're like I have this really small thing it's a little API let's build it in Sylex which is a micro framework built on the symphony components and then suddenly it becomes like the flagship product of your company and you're like crap I wish we because Sylex there's a lot more work to wire everything together every time you install something new there's a lot of configuration so that that sucked and there was really there's no easy upgrade path from Sylex to symphony so to have our cake and eat it too we just made symphony really really tiny so you can use it for that little internal API project and when it becomes the flagship of your company it's still symphony and it just grows and scales with you good question so Dries was talking about making installing Drupal easier is there any discussion about using Flex and recipes and that sort of paradigm yeah is there any question is there any discussion about using Flex with installing Drupal modules and things like that not now somebody could start that conversation Flex is definitely very focused on symphony framework right now and it's important like from the symphony team like it's important for us that's very important for us we're not trying to create a tool that does everybody however Drupal is a little bit of a special case and to be clear there's really nothing like in the Flex if you look at the Flex library itself there's not much in there that really ties it to the symphony framework there are a couple little things that we did that are you know cute things that are specific to the symphony framework what really makes Flex a symphony framework only tool is that there's a repository where all the recipes are stored so the recipes aren't stored like in your with the libraries themselves they're actually stored in a central repository and there's a couple reasons for that one of them is so we can kind of make sure they're high quality another one is sometimes you want a recipe for something that maybe is not a symphony thing it's just a random library or even an NPM package we actually have a way for you to install Webpack Encore with a recipe that through a PHP package so the point is they're in a central repository and since Flex is basically hard coded to look at that repository and that repository only well that repository is full of recipes that assume you're using the symphony framework so yeah it's not like anything would need to be completely reinvented or rebuilt to make something else that look like a different recipe server so maybe it would be it would be interesting alright I think a lot of time anyways so if you guys have any other questions you know are for like you want to tell me I was wrong about something that's cool do come up and say hi oh yeah my slides will be available I'll attach them to my node shortly good question voice control that seems like one or two steps away from that yeah that's actually a really interesting perspective to have so we normally think of I work on that to make your library that gives you those co-generations and we simply think of like what's the thing people build let's make a generator for that but yeah yours is like one step away from that where you're like let's ask that same question but in a different way and maybe what we ultimately do is generate them X we didn't ask them hey do you want to generate X right yeah and even something that's more abstracted so like what you're building today is going to be a music database and then it would kind of already know what the ontologies are for you know like I noticed that it was you put in your variable and it just guessed what the type was oh you saw that with the created yeah yeah yeah something like that at the end oh hi hi thank you for doing that I love that awesome oh yeah of course yeah super fun it's like so fun for me to like be able to teach something that is taking such a big step forward yeah yeah it's so nice to like actually see you in person and thanks for fixing my blog post so funny I was like correct I phrased that horribly yes no that was great it was a cool idea and actually it's one of the questions I got it was like what about symphony 4 it was like oh I wrote a plug what's about that untypalized