Unglue All The Things! Forum PHP Paris 2015

Bundles. Packages. Modules. Plugins. So much code is locked up in framework-specific packages. Integration packages are not bad, but losing the ability to reuse code that has nothing to do with a specific framework's implementation is! Don't let reusable code get locked into framework-specific glue packages! Come see practical strategies for writing framework agnostic code and walk away having a better idea how you, too, can unglue all the things!

Transcript

1. Unglue All The Things! joind.in/15272 Beau Simensen • beau.io • @beausimensen
2. Framework Agnostic PHP Packages
3. Overengineering
4. Domain-Driven Design
5. Exploring Domain-Driven Design led me to pursuing Tactical Purity
6. Tactical Purity is Hard. (especially in PHP)
7. I've got this. — Me
8. hubris [(h)yo͞obris] noun Excessive pride or self-confidence.
9. Reality
10. Active Record is just the worst
11. Doctrine is actually just as bad
12. Lesson Learned ORM framework agnostic models are hard to get right
13. Lesson Learned ORM framework agnostic models may require compromises
15. History
16. Halo Mine
17. CodeIgniter Not mine
18. It's pretty awesome for "not mine." — Me
19. Symfony 2 Still not mine
20. One catch...
21. Bundles.
22. "Modern PHP Packages"
23. Yuck.
24. Too many conventions
25. Too complicated
26. Too "Symfony"
27. Why was I fighting this so hard?
28. Too much noise around my Business Logic
29. My goal had become working on my domain model In Isolation
30. Purity for the packages that contained my domain model
31. "Framework Agnostic"
33. Silex + Doctrine
34. Silex Service Providers Fancy classes that wire up Pimple
35. dflydev/doctrine-orm-service-provider
36. My models were already not ORM framework agnostic But annotations were just too much for me to accept
37. External mapping using XML/YAML was simple
38. But most Doctrine integration packages required knowing the exact path to the mappings
39. Symfony handled this by convention (this is one reason why so many projects ship everything as a bundle)
40. Won't work if the mappings live in a project other than a bundle* * Nasty __DIR__ hacks don't count.
41. For Silex packages there was no option
42. This was problem.
43. Do we already have the tools to solve this problem?
44. PSR-0 (with a little help from Composer)
45. "autoload": { "psr-0": { "Monii\\Deal\\": "src" } }
46. "autoload": { "psr-0": { "Monii\\Deal\\": "src" } } Monii\Deal\DealRepository => src/Monii/Deal/DealRepository.php
47. "autoload": { "psr-0": { "Monii\\Deal\\": "src" } } Monii\Deal\DealRepository => src/Monii/Deal/DealRepository.php Monii\Deal\DealRepository => vendor/monii/deal/src/Monii/Deal/DealRepository.php
48. What if we used PSR-0 mappings and rules to locate other types of files than just classes?
49. "autoload": { "psr-0": { "Monii\\Deal\\": "src" } } Monii\Deal\DealRepository => src/Monii/Deal/DealRepository.php
50. "autoload": { "psr-0": { "Monii\\Deal\\": "src" } } Monii\Deal\DealRepository => src/Monii/Deal/DealRepository.php classpath:Monii/Deal/resources/mapping.yml => src/Monii/Deal/resources/mapping.yml
51. "autoload": { "psr-0": { "Monii\\Deal\\": "src" } } Monii\Deal\DealRepository => src/Monii/Deal/DealRepository.php classpath:Monii/Deal/resources/mapping.yml => src/Monii/Deal/resources/mapping.yml classpath:Monii/Deal/resources/mapping.yml => vendor/monii/deal/src/Monii/Deal/resources/mapping.yml
52. dflydev/psr0-resource-locator
53. dflydev/doctrine-orm-service-provider
54. Worked great in Silex!
55. $container["orm.em.options"] = [ "mappings" => [ [ "type" => "xml", "namespace" => "Monii\Deal", "resources_namespace" => "Monii\Deal\mappings", ], ], ];
56. $container["orm.em.options"] = [ "mappings" => [ [ "type" => "xml", "namespace" => "Monii\Deal", "resources_namespace" => "Monii\Deal\mappings", ], ], ]; Monii\Deal\Deal => classpath:Monii/Deal/mappings/Deal.xml => vendor/monii/deal/src/Monii/Deal/mappings/Deal.xml
57. Symfony Bundle would have required a lot of work
58. No More Time :(
59. Amy Stephen
60. PSR-4
61. Shorter paths please! — Everyone, apparently
62. "autoload": { "psr-4": { "Monii\\Deal\\": "src" } }
63. "autoload": { "psr-4": { "Monii\\Deal\\": "src" } } Monii\Deal\DealRepository => src/DealRepository.php
64. "autoload": { "psr-4": { "Monii\\Deal\\": "src" } } Monii\Deal\DealRepository => src/DealRepository.php Monii\Deal\DealRepository => vendor/monii/deal/src/DealRepository.php
65. "autoload": { "psr-4": { "Monii\\Deal\\": "src" } }
66. "autoload": { "psr-4": { "Monii\\Deal\\": "src", "Monii\\Deal\\Resources": "resources" } }
67. "autoload": { "psr-4": { "Monii\\Deal\\": "src", "Monii\\Deal\\resources": "resources" } } classpath:Monii/Deal/resources/mapping.yml => resources/mapping.yml
68. "autoload": { "psr-4": { "Monii\\Deal\\": "src", "Monii\\Deal\\resources": "resources" } } classpath:Monii/Deal/resources/mapping.yml => resources/mapping.yml classpath:Monii/Deal/resources/mapping.yml => vendor/monii/deal/resources/mapping.yml
69. Proposed to PHP-FIG
70. [Crickets.] — PHP-FIG
72. Puli the future of PHP package development
73. Puli allows packages can expose resources without knowing how they will be consumed
75. Controllers
76. MVC (Model, View, Controller)
77. Fat controllers
78. Skinny controllers
79. Hexagonal Architecture Ports & Adapteres
80. ADR (Action, Domain, Responder)
81. Translates between HTTP messages and your business logic. — Me, on controllers, actions, whatever
82. People have been known to get very opinionated on this. Really.
83. Traditionally, controllers have been trapped in the glue layer
84. Controllers as services can make controllers more portable
85. Symfony controllers as services can be used as-is in Silex, Drupal, Laravel, and Symfony full stack
86. PSR-7 controllers as services can be used anywhere you can find support for PSR-7
87. Hopefully in the near future that will be everywhere
89. Why stop at controllers?
90. Glide On-demand image manipulation library with an HTTP based API.
91. Glide is a self-contained HTTP application
92. I've used it
93. It's beautiful
94. It's glued to Laravel
95. Why?
96. Hey! I'm trying to decide if Glide should use PSR-7 for it's next release. — Jonathan Reinink, June 2015
97. Because let's be honest. That's the future. — Jonathan Reinink, two days later
98. A Deep Dive into Image Manipulations with Glide Reinink Jonathan tomorrow at 09h00
100. What should go in glue packages?
101. configuration
102. container wiring
103. hooks
104. other framework-specific features
105. code that is only relevant in the context of that framework
107. Purist vs Pragmatist
108. See: #phpdrama on Twitter
109. Closed Source
110. Will you actually reuse it?
111. Will you ever actually change frameworks?
112. Open Source
113. A lot of potential users from many potential frameworks
115. tips
116. Consider your goals
117. Start simple Move business logic out of the glue's namespace
118. Try Puli Especially if you have non-code resources that need to be referenced
119. Think about the code you write directly into a glue package (It can lead to better design)
120. Your model may always be influenced by your ORM Accept it
121. Container configuration is hard Expect some duplication across glue packages
122. If you must use Service Locator Consider using Container Interop (PSR-11)
123. Create separate packages for business logic and glue layers
124. suggest + require-dev is WEAK
125. Consider subtree splits for easier management of one repository containing multiple packages
126. EXPERIMENT
127. Learn more about Glide tomorrow Jonathan Reinink tomorrow at 09h00
128. Framework Agnostic for the Win Jonathan Reinink tomorrow at 11h15
129. Thanks! beau.io • @beausimensen monii.io • @moniidev thatpodcast.io • @thatpodcast joind.in/15272
131. GET INVOLVED
132. Engaging PHP-FIG was AWESOME (and exhausting)
133. PSR-0 Resource Locator (my experiment)
134. PSR-4 (getting involved)
135. Puli (something awesome)
136. StackPHP (my experiment)
137. PSR-7 (getting involved AND something awesome!)
138. I'm nobody
139. I'm just like you
140. Get involved :)