Migrate from Symfony to Silex

Migrate from Symfony to Silex

sfPot - 22 juin 2017 - Liberch'ti - Afsy

8665aad8f35b1710df79e9aef52d6daa?s=128

Alexandre Salomé

June 22, 2017
Tweet

Transcript

  1. Migrate from Symfony to Silex (or the opposite) Alexandre Salomé

    Auchan Retail France 22 juin 2017 @ Liberch’ti
  2. Why?

  3. Differences

  4. 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 ?
  5. Symfony standard Silex Skeleton

  6. 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
  7. Templating Symfony standard Template: Controller: Silex Template: Controller: + Same

    templates (excerpt identifiers) + Same Twig extension classes • DIY : render method in controllers
  8. Controller Symfony standard Access a service: Silex Access a service:

    + Declare inline controllers + Same way to access request • DIY: AbstractController
  9. 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
  10. Doctrine Symfony standard + Full support Silex - Only DBAL

    supported • DIY : implement ORM support
  11. Commands Symfony standard ContainerAwareCommand to the rescue : Silex +

    Possibility to define inline commands - No ContainerAware abstract class. • DIY: an AbstractCommand
  12. 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.
  13. 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
  14. No big deal!* * excerpt for business

  15. Application structure Business Controllers Commands Services Value objects + specific

    code Symfony Templates
  16. Application structure - Heat map Business Controllers Commands Services Value

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

    + specific code Symfony Templates
  18. 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)
  19. time = sizecoupling time = size x coupling

  20. Plain Old PHP (POP) Back to 80’s

  21. Agnostic business

  22. Agnostic controllers

  23. Straight to the point - KISS - Reimplement third services

    API A single goal : make application work again
  24. 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)
  25. 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
  26. Thank you<3