Drupal distributed architectures
0 likes2,694 views
This document discusses distributed architectures in Drupal and options for scaling a Drupal site that is becoming too large for a single server. It outlines trends toward modular code and separating functionality into API modules. It also classifies different architectural options like all-in-one sites, shared functionality through services, and aggregating content. The key technologies mentioned are services, SPARQL, and caching processed data or remote blocks to get the benefits of shared resources with low latency.
Drupal distributed architectures
- 1. Distributed architectures in Drupal What to do when your site is getting cramped? Drupalcamp Timisoara 2010
- 2. Introduction Kristof Van Tomme Co-founder PRONOVIX.com Drupal, Distributed architecture
- 3. Goals of this session Highlight 2 important code trends
- 5. Highlight the most important technologies
- 6. Share our battle plan for world domination
- 7. One-off modules -> API modules
- 8. Site > code on your server
- 9. Easy to reuse Easy to connect Custom code one-purpose sites Frameworks - One-purpose modules Installation profiles Frameworks - API modules Installation profiles with features Drupal service clouds - modular sites features
- 10. We are moving from websites to webservices
- 11. All in one sites pro reduced maintenance costs
- 12. greater flexibility (easy to put a block from one business application on a page of another)
- 13. no data transfer required (bandwith)
- 14. better performance (no network latency)
- 15. All in one sites contra module overbloat (slower performance and potential integration issues)
- 16. Permission conflicts between sections
- 17. Over-abstracted to accommodate different use cases
- 18. Content pollution from other sections
- 19. Navigation might become a mess
- 20. What to serve? Content
- 21. Users
- 22. Functionality
- 23. Functionality = data mapping data transformations
- 24. data mediation
- 28. Sharing options Common resource
- 29. Just in time
- 30. Just in time + caching
- 31. Aggregation
- 32. Common resource architectures Organic groups
- 33. Domain access
- 34. Shared tables
- 35. Spaces/features
- 36. Not flexible
- 37. Just in time Services
- 38. SPARQL
- 40. Aggregation RSS
- 41. Table wizard + migrate
- 42. Deploy
- 43. Not always up to date
- 44. Just in time + caching Content staging
- 45. Remote blocks
- 46. Remote nodes
- 47. Best of both worlds
- 48. Processed data Remote blocks
- 49. i-frames
- 50. JSON objects
- 51. The internet will be a collection of Service Providers and Mashups
- 52. Drupal is already really good at consuming services
- 53. Drupal is already really good at consuming services
- 54. Drupal is pretty good at serving content
- 55. What about the missing services? data transformations
- 56. data mediation
- 60. If we can get better at producing easy to consume services we can conquer the world
- 62. @kvantomme