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 ?
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
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
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
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)
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
alexandresalome
hirosatogamo
kubukoz
ahana
carta_engineering
onk
uzulla
lmi
kenichirokimura
seike460
soachr
sumiren
abenben
jensimmons
malarkey
matthewcrist
garrettdimon
sachag
revolveconf
reverentgeek
colly
skipperchong
danielanewman
bryan
quramy