Migrate from Symfony to Silex (or the opposite) Alexandre Salomé Auchan Retail France 22 juin 2017 @ Liberch’ti

Why?

Differences

General considerations Solution for large applications - Heavy foundations - Lot of professional support Tons of features activated by default (swiftmailer, doctrine, twig, ...) Solution for small applications - Lightweight - Easy to understand Nothing activated by default. DIY oriented. What about medium applications ?

Symfony standard Silex Skeleton

Framework Symfony standard Bundles Use DependencyInjection component for service container: Silex Extensions Use Pimple component for service container: + Based on Symfony components - Very few service providers for Silex ● DIY: implement a ServiceProvider

Templating Symfony standard Template: Controller: Silex Template: Controller: + Same templates (excerpt identifiers) + Same Twig extension classes ● DIY : render method in controllers

Controller Symfony standard Access a service: Silex Access a service: + Declare inline controllers + Same way to access request ● DIY: AbstractController

Routing Symfony Declare a route : Everything is in routing.yml Generated procedural code, optimized for resolution speed. Silex Declare a route: Routes declared in Application class. Every route reloaded in memory at each execution. Becomes critical when having many routes. - Silex routing performance ● Declare controllers as services in Silex

Doctrine Symfony standard + Full support Silex - Only DBAL supported ● DIY : implement ORM support

Commands Symfony standard ContainerAwareCommand to the rescue : Silex + Possibility to define inline commands - No ContainerAware abstract class. ● DIY: an AbstractCommand

Performance Symfony Has a compilation step (container, warm up) Can be very lightweight, with good optimizations: - Remove unused bundles - Remove unused features from configuration Silex Mostly executed at runtime (but still possible to make optimizations, DIY). Simple enough for small websites, performant for small applications.

To resume + Same concepts + Framework cases are simple to migrate + Most of the framework-related code is kept (Twig, Doctrine, …) + Performance is OK for small websites - DIY in Silex for extra features - Heavy applications with Silex doesn’t make sense

No big deal!* * excerpt for business

Application structure Business Controllers Commands Services Value objects + specific code Symfony Templates

Application structure - Heat map Business Controllers Commands Services Value objects + specific code Symfony Templates

Application structure - Coupling Business Controllers Commands Services Value objects + specific code Symfony Templates

Coupling Coupling is the dependency of your business to your framework. You should must be aware of that dependency, and decide or not to abstract your business code from it. To make this decision, you should consider: - The size of the coupling from your business your framework - The effort to abstract your business from X (5-days website) - The risk that X will be changed for Y or Z (benchmarks) - The durability of X (maintenance and support)

time = sizecoupling time = size x coupling

Plain Old PHP (POP) Back to 80’s

Agnostic business

Agnostic controllers

Straight to the point - KISS - Reimplement third services API A single goal : make application work again

Progressive migration - Encapsulate Symfony with Silex, or the opposite - Delegate everything to inner application - Override entry-points, one by one Difficulties - Conflict between libraries - Performance overhead It depends! (free beer consulting)

To sum up - A good exercise for your personal projects: - A good way to challenge yourself - A good way to discover new things - An opportunity to refactor your code - Makes you feel how much you depend on your framework - Makes you learn how to be agnostic in your code - Be aware of the costs and risks, and make assumptions

Thank you<3