Case study - Cupido mobil – Eirik Morland, Ny Media – Case - mobilversjon
Case study - Cupido mobil – Eirik Morland, Ny Media – Case - mobilversjon
0 0
cupidom-dcoslo2014
Slides for talk about cupidom case studyOn Github eiriksm / cupidom-dcoslo2014
Case study - Cupido mobil
Eirik Morland, Ny Media
Cupido.no - web-versjon
- Drupal 6 (pressflow)
- Varnish
- Memcache
- 4 frontservere
Cupido.no - andre tall
- 16 000 sessions per dag
- 415 000 sidevisninger
- 17 min per session
- På det meste 1 melding hvert andre sek.
Case - mobilversjon
Alternativ
- App
- Responsiv design
- Mobil versjon
App
Ikke aktuelt pga restriksjoner på innhold.
Responsiv design
- Mulig gjenbruk av nåværende theme
- Mange av sidene har "desktop"-markup
- Man må bootstrappe Drupal med alle modulene
- Mest fordelaktig om man går "all-in".
Mobilversion
- Ingen page loads, kun dynamisk lasting av innhold med AJAX
- Mulig å "erstatte" kun deler av nettsiden.
- Ingen responsive hacks og display: none
Mobilversjon - teknologi
- Varnish - device detection
- Backend server, skrevet i go (gorilla)
- Frontend i angular.js
Login
Login request:
+----------------+ +---------------+ +---------------+
| App / client | | App backend | | Drupal (API) |
+-------+--------+ +-------+-------+ +-------+-------+
| | |
| 1. Page request | |
|+------------------------->| 2. No valid app session[1] |
| | Send login request |
| |+-------------------------->|
| | |
| | 3. Return Drupal session |
| 4. Create app session |<--------------------------+|
| Store Drupal session | |
| Return resources | |
| (html, js, img..) | |
|<-------------------------+| |
v v v
"Vanlige" API requests
API request to Drupal:
+----------------+ +---------------+ +---------------+
| App / client | | App backend | | Drupal (API) |
+-------+--------+ +-------+-------+ +-------+-------+
| | |
| 1. Drupal API request | |
|+------------------------->| 2. Check app session |
| | Proxy /api prefix |
| |+-------------------------->|
| | |
| | 3. Return json result |
|<------------------------------------------------------+|
v v v
Søk
API request to App backend and SOLR:
+----------------+ +---------------+ +---------------+
| App / client | | App backend | | Solr |
+-------+--------+ +-------+-------+ +-------+-------+
| | |
| 1. Search request | |
|+------------------------->| 2. Check app session |
| | Solr query |
| |+-------------------------->|
| | |
| | 3. Return result |
| |<--------------------------+|
| 4. Return result | |
|<-------------------------+| |
v v v
Meldinger
API request on messages:
+----------------+ +---------------+ +---------------+
| App / client | | App / redis | | Drupal |
+-------+--------+ +-------+-------+ +-------+-------+
| | |
| 1. Updates? | |
|+------------------------->| 2. Check app session |
| | Subscribe on key |
| |+ - - - - - - - - - - - - ->|
| | |
| | 3. Return result |
| 4. Return result |<- - - - - - - - - - - - - +|
| or HTTP 204 No content | |
|<-------------------------+| |
v v v
Demos?
SOLR sortere på distanse
SOLR generelt
Meldinger
Hvorfor ikke bare Drupal som backend?
- Mye overhead med bootstrap av Drupal for søk.
- Mye overhead med bootstrap av Drupal for bilder.
- Eget caching lag for realtime meldinger (redis)
Utfordringer?
- Mye eksisterende logikk i moduler uten ordentlig API-funksjoner
- Løsning: wrapper api modul
- Egen bruker-sesssions / tilgangskontroll
Andre positive effekter?
Potensielt enklere å forholde seg til oppgraderinger (f.eks 6 - 7) ved å ha en “kontrakt” ift API for backend.