The Architecture ================ You are my hero! Who would have thought that you would still be here after the first two parts? Your efforts will be well-rewarded soon. The first two parts didn't look too deeply at the architecture of the framework. Because it makes Symfony stand apart from the framework crowd, let's dive into the architecture now. Add Logging ----------- A new Symfony app is micro: it's basically just a routing & controller system. But thanks to Flex, installing more features is simple. Want a logging system? No problem: .. code-block:: terminal $ composer require logger This installs and configures (via a recipe) the powerful `Monolog`_ library. To use the logger in a controller, add a new argument type-hinted with ``LoggerInterface``:: // src/Controller/DefaultController.php namespace App\Controller; use Psr\Log\LoggerInterface; use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; use Symfony\Component\Routing\Annotation\Route; class DefaultController extends AbstractController { /** * @Route("/hello/{name}") */ public function index($name, LoggerInterface $logger) { $logger->info("Saying hello to $name!"); // ... } } That's it! The new log message will be written to ``var/log/dev.log``. The log file path or even a different method of logging can be configured by updating one of the config files added by the recipe. Services & Autowiring --------------------- But wait! Something *very* cool just happened. Symfony read the ``LoggerInterface`` type-hint and automatically figured out that it should pass us the Logger object! This is called *autowiring*. Every bit of work that's done in a Symfony app is done by an *object*: the Logger object logs things and the Twig object renders templates. These objects are called *services* and they are *tools* that help you build rich features. To make life awesome, you can ask Symfony to pass you a service by using a type-hint. What other possible classes or interfaces could you use? Find out by running: .. code-block:: terminal $ php bin/console debug:autowiring # this is just a *small* sample of the output... Describes a logger instance. Psr\Log\LoggerInterface (monolog.logger) Request stack that controls the lifecycle of requests. Symfony\Component\HttpFoundation\RequestStack (request_stack) Interface for the session. Symfony\Component\HttpFoundation\Session\SessionInterface (session) RouterInterface is the interface that all Router classes must implement. Symfony\Component\Routing\RouterInterface (router.default) [...] This is just a short summary of the full list! And as you add more packages, this list of tools will grow! Creating Services ----------------- To keep your code organized, you can even create your own services! Suppose you want to generate a random greeting (e.g. "Hello", "Yo", etc). Instead of putting this code directly in your controller, create a new class:: // src/GreetingGenerator.php namespace App; class GreetingGenerator { public function getRandomGreeting() { $greetings = ['Hey', 'Yo', 'Aloha']; $greeting = $greetings[array_rand($greetings)]; return $greeting; } } Great! You can use this immediately in your controller:: // src/Controller/DefaultController.php namespace App\Controller; use App\GreetingGenerator; use Psr\Log\LoggerInterface; use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; use Symfony\Component\Routing\Annotation\Route; class DefaultController extends AbstractController { /** * @Route("/hello/{name}") */ public function index($name, LoggerInterface $logger, GreetingGenerator $generator) { $greeting = $generator->getRandomGreeting(); $logger->info("Saying $greeting to $name!"); // ... } } That's it! Symfony will instantiate the ``GreetingGenerator`` automatically and pass it as an argument. But, could we *also* move the logger logic to ``GreetingGenerator``? Yes! You can use autowiring inside a service to access *other* services. The only difference is that it's done in the constructor: .. code-block:: diff // src/GreetingGenerator.php + use Psr\Log\LoggerInterface; class GreetingGenerator { + private $logger; + + public function __construct(LoggerInterface $logger) + { + $this->logger = $logger; + } public function getRandomGreeting() { // ... + $this->logger->info('Using the greeting: '.$greeting); return $greeting; } } Yes! This works too: no configuration, no time wasted. Keep coding! Twig Extension & Autoconfiguration ---------------------------------- Thanks to Symfony's service handling, you can *extend* Symfony in many ways, like by creating an event subscriber or a security voter for complex authorization rules. Let's add a new filter to Twig called ``greet``. How? Create a class that extends ``AbstractExtension``:: // src/Twig/GreetExtension.php namespace App\Twig; use App\GreetingGenerator; use Twig\Extension\AbstractExtension; use Twig\TwigFilter; class GreetExtension extends AbstractExtension { private $greetingGenerator; public function __construct(GreetingGenerator $greetingGenerator) { $this->greetingGenerator = $greetingGenerator; } public function getFilters() { return [ new TwigFilter('greet', [$this, 'greetUser']), ]; } public function greetUser($name) { $greeting = $this->greetingGenerator->getRandomGreeting(); return "$greeting $name!"; } } After creating just *one* file, you can use this immediately: .. code-block:: html+twig {# templates/default/index.html.twig #} {# Will print something like "Hey Symfony!" #}

{{ name|greet }}

How does this work? Symfony notices that your class extends ``AbstractExtension`` and so *automatically* registers it as a Twig extension. This is called autoconfiguration, and it works for *many* many things. Create a class and then extend a base class (or implement an interface). Symfony takes care of the rest. Blazing Speed: The Cached Container ----------------------------------- After seeing how much Symfony handles automatically, you might be wondering: "Doesn't this hurt performance?" Actually, no! Symfony is blazing fast. How is that possible? The service system is managed by a very important object called the "container". Most frameworks have a container, but Symfony's is unique because it's *cached*. When you loaded your first page, all of the service information was compiled and saved. This means that the autowiring and autoconfiguration features add *no* overhead! It also means that you get *great* errors: Symfony inspects and validates *everything* when the container is built. Now you might be wondering what happens when you update a file and the cache needs to rebuild? I like your thinking! It's smart enough to rebuild on the next page load. But that's really the topic of the next section. Development Versus Production: Environments ------------------------------------------- One of a framework's main jobs is to make debugging easy! And our app is *full* of great tools for this: the web debug toolbar displays at the bottom of the page, errors are big, beautiful & explicit, and any configuration cache is automatically rebuilt whenever needed. But what about when you deploy to production? We will need to hide those tools and optimize for speed! This is solved by Symfony's *environment* system and there are three: ``dev``, ``prod`` and ``test``. Based on the environment, Symfony loads different files in the ``config/`` directory: .. code-block:: text config/ ├─ services.yaml ├─ ... └─ packages/ ├─ framework.yaml ├─ ... ├─ **dev/** ├─ monolog.yaml └─ ... ├─ **prod/** └─ monolog.yaml └─ **test/** ├─ framework.yaml └─ ... └─ routes/ ├─ annotations.yaml └─ **dev/** ├─ twig.yaml └─ web_profiler.yaml This is a *powerful* idea: by changing one piece of configuration (the environment), your app is transformed from a debugging-friendly experience to one that's optimized for speed. Oh, how do you change the environment? Change the ``APP_ENV`` environment variable from ``dev`` to ``prod``: .. code-block:: diff # .env - APP_ENV=dev + APP_ENV=prod But I want to talk more about environment variables next. Change the value back to ``dev``: debugging tools are great when you're working locally. Environment Variables --------------------- Every app contains configuration that's different on each server - like database connection information or passwords. How should these be stored? In files? Or some other way? Symfony follows the industry best practice by storing server-based configuration as *environment* variables. This means that Symfony works *perfectly* with Platform as a Service (PaaS) deployment systems as well as Docker. But setting environment variables while developing can be a pain. That's why your app automatically loads a ``.env`` file. The keys in this file then become environment variables and are read by your app: .. code-block:: bash # .env ###> symfony/framework-bundle ### APP_ENV=dev APP_SECRET=cc86c7ca937636d5ddf1b754beb22a10 ###< symfony/framework-bundle ### At first, the file doesn't contain much. But as your app grows, you'll add more configuration as you need it. But, actually, it gets much more interesting! Suppose your app needs a database ORM. Let's install the Doctrine ORM: .. code-block:: terminal $ composer require doctrine Thanks to a new recipe installed by Flex, look at the ``.env`` file again: .. code-block:: diff ###> symfony/framework-bundle ### APP_ENV=dev APP_SECRET=cc86c7ca937636d5ddf1b754beb22a10 ###< symfony/framework-bundle ### + ###> doctrine/doctrine-bundle ### + # ... + DATABASE_URL=mysql://db_user:db_password@127.0.0.1:3306/db_name + ###< doctrine/doctrine-bundle ### The new ``DATABASE_URL`` environment variable was added *automatically* and is already referenced by the new ``doctrine.yaml`` configuration file. By combining environment variables and Flex, you're using industry best practices without any extra effort. Keep Going! ----------- Call me crazy, but after reading this part, you should be comfortable with the most *important* parts of Symfony. Everything in Symfony is designed to get out of your way so you can keep coding and adding features, all with the speed and quality you demand. That's all for the quick tour. From authentication, to forms, to caching, there is so much more to discover. Ready to dig into these topics now? Look no further - go to the official :doc:`/index` and pick any guide you want. .. _`Monolog`: https://github.com/Seldaek/monolog