Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Drupal 8 non standard cooking: REST API + Solr + Domains - Maksym Kuzmych & Vladyslav Bondarchuk

140 views

Published on

This speech will be focused on non standard practices for Drupal sites 'cooking'. The main aspects of the speech are:
Page building with Apache Solr data storage, REST API on the back-end side and Angular JS on the front-end side.
How to handle Solr data storage via REST API:
- Referenced entities
- Responsive images
- Menus and site settings
- Cache and it's invalidation
- Access and permissions
- 403 & 404 exceptions
Search results based on REST response: filters, facets and sorting.
Managing 10000+ domains on one site.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Drupal 8 non standard cooking: REST API + Solr + Domains - Maksym Kuzmych & Vladyslav Bondarchuk

  1. 1. Drupal nonstandard “cooking”: Apache SOLR+REST Api+Domains
  2. 2. Max Kuzmych Drupal developer at Adyax ▸ in Drupal for 3+ years ▸ maintainer and contributor on drupal.org ▸ co-author of Widget engine module Vlad Bondarchuk Drupal developer at Adyax ▸ in Drupal for 5+ years ▸ maintainer and contributor on drupal.org JUST FEW WORDS ABOUT US
  3. 3. Cooking WTF? Are you serious?!
  4. 4. CODING VS COOKING ▸ Recipes are other people’s code ▸ Genres are languages ▸ Multithreading
  5. 5. TASTE FEATURES Different data-sources Fast response Subsites & site-factory Actual data all the time
  6. 6. EXPECTED MASTERPIECE
  7. 7. FIRST STAGES
  8. 8. Cooking Genres What to use?
  9. 9. COOKING GENRES PHP Genre (Backend - Drupal) JavaScript Genre (Frontend - Angular JS) Masterpiece
  10. 10. Ingridients What should we include?
  11. 11. STORAGE Main concept PRIMARY (content administration) SECONDARY (REST API content retrieving)
  12. 12. STORAGE Primary DB PostgreSQL ?
  13. 13. STORAGE Secondary DB PostgreSQL
  14. 14. Solr? NoSQL? ▸ CP system (consistent and partially tolerant) ▸ Document oriented ▸ Indexed in sophisticated way (search across all fields or specific) ▸ No fixed schemas (fixed schemas as well) ▸ Avoid joins ▸ Marketing
  15. 15. “Genre is about marketing” Ursula K. LeGuin
  16. 16. ▸ Scalability ▸ Realtime-Get ▸ Search (facets) ▸ Very similar to MongoDB ▸ Update Durability ▸ Versioning and optimistic locking SOLR BENEFITS
  17. 17. DRUPAL INTEGRATION
  18. 18. REAL PROJECTS ▸ https://www.zoosk.com ▸ https://www.theguardian.com
  19. 19. COOKING PROCESS
  20. 20. REST resources External WS Backend pages FRONTEND PAGES BACKEND PAGES
  21. 21. SOLR PRE-COOK SOLR Backend Enhanced contrib backend solution: avoid building full field structure on results extracting. SOLR Processors For some specific data we need specific format of storing.
  22. 22. Call REST resource Check URL or params Process query by custom helper Call Search API SEARCH CONCEPT Retrieve data from Solr Convert to JSON
  23. 23. REAL SEARCH PAGES ▸ Partly using Search API (custom Solr backend plugin and query builder) ▸ Direct facets (avoid using Facets module)
  24. 24. CUSTOM QUERY BUILDER HELPER
  25. 25. RESPONSE EXAMPLE
  26. 26. Recursion Check Serialize Store REFERENCED ENTITIES
  27. 27. REFERENCED ENTITIES
  28. 28. Configure Generate Serialize Store RESPONSIVE IMAGES
  29. 29. RESPONSIVE IMAGES
  30. 30. Collect tags Serialize Store Invalidate CACHING
  31. 31. CACHING
  32. 32. ADMINISTRABLE CUSTOM ROUTES ▸ Own ParamConverter ▸ Project specific settings for routes (building route per entity type/bundle/etc.) ▸ Handling 403/404 errors (via Fast404 module & custom Fast403)
  33. 33. DOMAINS ▸ Huge amount of breeders (70k, 8k active, 300 clubs) ▸ Menu per domain ▸ Config entities problems ▹ domainNegotiator ▹ CacheContext ▹ path processors ▹ extending Domain Entity
  34. 34. DOMAIN SETTINGS CUSTOMIZATION ▸ Extending domain basic features ▸ Custom drush command for export/import (based on Drush CMI tools) ▸ Thoughts about config entity concept
  35. 35. IN CONSEQUENCE

×