Talk about why and how one can create decoupled (PHP) web applications

1. Decoupled CMS
Lukas Smith | @lsmith
!
slides created in collaboration with @bergie

2. Application
Framework
Database
File System

3. We've seen this picture before

4. Your CMS is a monolith

5. A great hiding place for spaghetti

6. It is holding you hostage
as you are trying to scale and evolve

7. Technologies are a fashion

8. Technologies fail

9. The internet was built on
protocols

10. It is scalable

11. It embraces failure

12. It delegates responsibility
empowering clients

13. It is language agnostic

14. It all boils down to ..

15. Decoupling

16. Service-Oriented
Architecture
like we're back in 2000s

17. Services of a typical web application
!
Accounts: login, authorization
API: data storage and retrieval
WWW: actual web front-end
Most frameworks put these in the
same box - why?

24. You're already using SOA

25. Atom & RSS

26. Authentication & identity

27. Commenting

28. oEmbed

29. Analytics

30. Search

31. Semantic mark-up

32. Payment

33. Infrastructure: SaaS, PaaS

34. But not everything is
ponycorns

36. SOA can take longer
...but if you don't know Drupal, you can be
faster with Jekyll and Disqus

37. API incompatibilities
...especially when you're still sketching out
your service

38. Server for each service
can be expensive
providers like Heroku can help here

39. You're on your own
less framework support, fewer books, less
experience

40. Many other valid concerns
Backup
Cross DB queries
API changes
Down time
Terms of service
Legal
Quality concerns
End of service
Performance
Missing Features
Setup delays
Price
Latency
User Experience

41. Making SOA manageable

42. Edge Side Includes

43. Edge Side Includes
<esi:include
src=".." />
<esi:includ
e src=".." />
!
!
!
!
!
<esi:include
src=".." />
!
!
!
!
!
!
!
!
!
!
!
<esi:include src=".." />
<esi:include src=".." /
!
!
<esi:include
src=".." />

44. Events, Message Queues

45. Applying decoupling to
PHP applications

46. Interfaces
protocols on programming language level

47. Framework
Interoperability Group
bikeshedding instead of defining
interfaces?

48. We are not yet tackling the hard stuff
.. did give us PSR-3 for logging

49. PHP Content Repository Specification
•
•
•
•
Adaption of the JCR standard
Contains mostly just interfaces
API covers the needs of CMS
Semi-structured data
• Hierarchical data
• Fulltext Search
• Versioning
• etc.

50. Composer as the savior
dependency management done right

52. Interface providers in Composer
"name": "jackalope/jackalope",
"type": "library",
...
"provide": {
"phpcr/phpcr-implementation": "2.1.0"
},
… now you can depend on
“phpcr-implementation” instead
of a specific provider

54. Create.js

55. Decoupling your CMS
Example: Symfony CMF
•
•
•
•
!
PHPCR
o
Single API, different storage implementations
Symfony2
o
Off-the-shelf framework
Create.js
o
Client-side inline editing with RDFa and JSON-LD
Varnish
o
Construct pages from output of different services

56. Think protocols
...and interfaces

57. Reuse existing
infrastructure
...whether it is a library or a hosted service

58. Build services
...not monolithic code

59. Questions?
!
Lukas Smith | @lsmith
!
http://pooteeweet.org
https://github.com/lsmith77