I will point out some of the things Symfony offers (or the book covers) that might be new or different for Drupal developers.

Dev Environment

• using local php (for speed and simplicity, switchable using the symfony CLI tool) combined with docker for services (redis, mailcatcher, etc) that are harder to install locally/per project
• CLI tooling: symfony command
  • sets PHP version and env variables. It can also connect to dockerized services. It should be the prefix before any CLI command (console, composer, php, phpunit)
  • has a powerful dev php server build-in, including ssl support.
• CLI tooling: console command
  • is the equivalent of drush (and Drupal console)
  • has utilities for creating helpful scaffolds for entities, users, authentication, forms, translations
  • can list debug info for routes, authentication, the container and autowiring, notifier, messenger, etc.
  • can clear caches
  • can run doctrine commands (equivalent of Drupal commands such as drush updb)
  • you can easily create custom console commands, e.g. to use for cronjobs
• Storing variables and constants:
  • passwords and tokens should be stored in Symfony secret storage or vaults
  • dynamic values that can change without redeploying should be stored as environment variables
  • if a value changes per environment (dev/test/prod) it should be stored as a container parameter
  • otherwise best store the value in code, in a class constant.
  • you can set service parameters and bind variables to services in the services.yaml config file.
• Webpack encore: symfony can integrate with webpack to provide a nice frontend toolchain including node, yarn, sass, etc.
• Symfony 5 development: you need a complete PHP installation including amqp.so which you might need to install. Symfony leverages many PHP 7 features directly.

Core

• Services
  • are autowired
  • all classes in /src except Entity, Migrations and Tests are loaded as services.
• Routing
  • paths and prefixes can be i18n
  • request format and method can be set or be required
  • simple conditions and default values can be set inline
• Messenger and Notifier
  • the messenger system is an async system akin to Drupal queues.
  • define a Message, MessageHandler and a Transport. Consume the message with a Worker.
  • the notifier system combines notifications in the browser (Symfony calls these flashes, akin to drupam_set_message) with email, sms, slack and other notification options. Notifications can have different priorities and use multiple notification channels at the same time.
• Security & Permissions
  • the security system is called a firewall.
  • defaults to none provided. No permissions, no (dynamic) roles, no users
  • for simple apps an in-memory user provider can be enough
  • for login with an external user source: no local user system is required.
  • for login using an API: no GUI login (form) is required.
  • password encoders: lots of choice, the standard UserPasswordEncoder does what you would mostly need and selects the best encryption available.
  • authorization:
    • Drupal has Roles and Permissions. Symfony has Roles (can be nested) and Permissions and Security voters.
    • path based access for roles can be set in security.yaml (optionally including IP, host, port, method requirements)
    • annotation based permissions can be given to roles on Controllers
    • security Voters are used for fine grained access handling.
    • Drupal masquerade functionality is included in the authentication system (quickly switching users)
• Translation
  • crude language switching can be done on URL prefix. Other methods you need to implement yourself or find a bundle.
  • interface translation is handled by the symfony/translation composer package.
  • uses ICU (International Components for Unicode) libraries for plurals
  • translations are stored using the .xlf file format (XLIFF; XML Localisation Interchange File Format) and can be generated with a console command and shown on the Symfony Profiler Toolbar
  • content translation is done using Doctrine extension bundles.
• Annotation
  • a lot can be configured via class annotations: database tables and fields, validation, security and access, routing, parameters, api exposure, and more
  • entity references can be set using annotions and the necessary database tables created using symfony console:make:entity
• Forms
  • Form types are available using HTML validation set by the database annotation.
  • inline form errors are available
  • file uploads are easily implemented
• Api
  • the api-platform/api-pack symfony component allows you to expose entities using their annotation.
  • includes a gui to browse the API including swagger files.
  • requires very little configuration and setup to start of with.
• Workflow
  • the workflow system introduces a state machine that can manage the state of an entity
  • states are configured in a yaml file and the state process can be visualized using the dot CLI tool and symfony console workflow:dump
  • works well together with the Messenger system
• Events
  • Symfony uses event listeners to expand its core functionality (there are no Drupal hooks like system)
  • You can list all events using symfony console debug:event-dispatcher
• Caching
  • Basic caching is done using the HTTP cache mechanism: using an external (reverse proxy) cache such as Varnish. This can cache until expired or use a validation strategy.
  • You can set the HTTP cache headers and proxy cache headers in the Response objects
  • Symfony supports ESI (Edge Side Includes) subrequests to achieve something similar to lazy loading page elements in Drupal Bigpipe.
  • The symfony/cache component enables a local cache similar to the Drupal cache. There is no render cache: for this the native caching mechanisms of HTTP are used.

Testing

• Automated tests
  • You can define fixtures and load them via a doctrine console command
  • When writing automated tests there is a nice doctrine bundle that can reset the test database
  • Symfony has a headless browser bundle that provides the 'panther' headless browser with drivers for Chrome and Firefox.
  • You have access to the Symfony kernel during tests and can use this in your assertions.
• Blackfire player:
  • The blackfire system is known for its profiler, but also contains a player that can be used for black-box testing.