Decoupled cms sunshinephp 2014

922 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
922
On SlideShare
0
From Embeds
0
Number of Embeds
82
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Decoupled cms sunshinephp 2014

  1. 1. Decoupled CMS Lukas Smith | @lsmith ! slides created in collaboration with @bergie
  2. 2. Application Framework Database File System
  3. 3. We've seen this picture before
  4. 4. Your CMS is a monolith
  5. 5. A great hiding place for spaghetti
  6. 6. It is holding you hostage as you are trying to scale and evolve
  7. 7. Technologies are a fashion
  8. 8. Technologies fail
  9. 9. The internet was built on protocols
  10. 10. It is scalable
  11. 11. It embraces failure
  12. 12. It delegates responsibility empowering clients
  13. 13. It is language agnostic
  14. 14. It all boils down to ..
  15. 15. Decoupling
  16. 16. Service-Oriented Architecture like we're back in 2000s
  17. 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?
  18. 18. You're already using SOA
  19. 19. Atom & RSS
  20. 20. Authentication & identity
  21. 21. Commenting
  22. 22. oEmbed
  23. 23. Analytics
  24. 24. Search
  25. 25. Semantic mark-up
  26. 26. Payment
  27. 27. Infrastructure: SaaS, PaaS
  28. 28. But not everything is ponycorns
  29. 29. SOA can take longer ...but if you don't know Drupal, you can be faster with Jekyll and Disqus
  30. 30. API incompatibilities ...especially when you're still sketching out your service
  31. 31. Server for each service can be expensive providers like Heroku can help here
  32. 32. You're on your own less framework support, fewer books, less experience
  33. 33. 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
  34. 34. Making SOA manageable
  35. 35. Edge Side Includes
  36. 36. Edge Side Includes <esi:include src=".." /> <esi:includ e src=".." /> ! ! ! ! ! <esi:include src=".." /> ! ! ! ! ! ! ! ! ! ! ! <esi:include src=".." /> <esi:include src=".." / ! ! <esi:include src=".." />
  37. 37. Events, Message Queues
  38. 38. Applying decoupling to PHP applications
  39. 39. Interfaces protocols on programming language level
  40. 40. Framework Interoperability Group bikeshedding instead of defining interfaces?
  41. 41. We are not yet tackling the hard stuff .. did give us PSR-3 for logging
  42. 42. 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.
  43. 43. Composer as the savior dependency management done right
  44. 44. 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
  45. 45. Create.js
  46. 46. 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
  47. 47. Think protocols ...and interfaces
  48. 48. Reuse existing infrastructure ...whether it is a library or a hosted service
  49. 49. Build services ...not monolithic code
  50. 50. Questions? ! Lukas Smith | @lsmith ! http://pooteeweet.org https://github.com/lsmith77

×