Architecture d’une app qui fait 5 millions de visites par mois
•
1 gefällt mir•2,359 views
Basé sur un cas réel dans la presse quotidienne régionale, cette présentation vous montrera quels sont les principes d'architecture à respecter pour concevoir et maintenir un parc d'applications mobiles natives iOS / Android / Windows Phone 8. Nous verrons les différentes étapes de la construction d'un socle commun et générique, résistant à la charge et évolutif. Nous parlerons également des solutions hybrides, de la gestion server-side, de la prise en compte du réseau mobile et des difficultés rencontrées.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Architecture d’une app qui fait 5 millions de visites par mois
Ähnlich wie Architecture d’une app qui fait 5 millions de visites par mois (20)
Architecture d’une app qui fait 5 millions de visites par mois
- 1. Architecture d’une app qui fait 5 millions de visites par mois @juliencarnelos #bdxio
- 2. Groupe Sud Ouest : 34 sociétés • Groupe Sud Ouest • Journaux du midi
- 4. 90 millions de pages vues apps en septembre 2014 300 000 6 000 000 8 000 000 3 600 000 26 000 000 48 000 000 Sud Ouest Midi Libre La république des Pyrénées L'indépendant Charente Libre Centre Presse Aveyron Actu locale Actu thématique Journal en PDF
- 7. Un Mercredi à 13h • 560 visiteurs • 1 300 interactions / minute • 13 100 requêtes HTTP / minute • Peut varier x50 (élections municipales)
- 8. “Replace 5 with X”
- 10. Nos solutions
- 11. « Big Picture » Reverse Proxy Server Reverse Proxy Server External CDN Web Services Assets Images Image Resizer MONITORING CDN
- 13. Extrait de notre parc
- 14. Comparaison iPhone / Android
- 15. Comparaison iPhone / Android
- 16. Notion d’application générique • même backend • même structure d’app • $$ : mutualisation • Personnalisation : couleurs, images, navigation, services
- 17. Organisation du projet • /Project => code source de l’app générique • /Assets => 1 sous dossier par éditeur • splashscreen • couleurs, wording • token • 1 URL de référence
- 18. Fichier de configuration • « Hydrater » l’application au démarrage • http://api.sudouest.fr/conf?token=ABCDEF • 1 token par éditeur et par app
- 19. routes internes • Format : editeur://{page}/{params} • so://rubrique/actu_home • so://article/12345 • so://kiosque • so://web/http://www.bdx.io/ • Porté dans la configuration
- 20. Définition de la barre de navigation
- 21. Menu
- 22. Liste des services appelés : URL / Paramètres
- 23. Possibilité d’insérer du HTML dans l’app
- 24. Les scénarios possibles • Mettre l’actu du mondial pendant 1 mois • Lien vers un formulaire de feedback en home • Modifier la hiérarchie de l’information • Retirer une fonctionnalité buggée
- 25. O-Auth • standard • Jeton d’auth transmis dans les so://web/
- 27. Moteur article webview JSON article {} JSON profil {} JSON app {} { article images type article payant } { statut } { device } Template HandleBars Template HandleBars Template HandleBars JQuery Logique JS
- 28. Moteur article webview webview.zip 5 Ko 200 304
- 29. La couche service Reverse Proxy Server Reverse Proxy Server External CDN Web Services Assets Images Image Resizer MONITORING CDN
- 30. Approche REST • pur REST : ❤️ en théorie • Complexité et contraintes fortes • Parc interne maîtrisé : on peut optimiser
- 31. Nos pratiques REST • 99% de GET • n° de version dans l’URL • Clé d’API dans l’url • Paramètres en GET plutôt que POST • Parle HTTP : 200 / 304 / 403 / 404 / 500
- 32. Nos pratiques REST • Copie-collable • Facilite la compréhension
- 33. Cache local • Cache First / Offline • Requête en arrière plan • Refresh à la volée • Importance du HTTP : 304 / E-Tag
- 34. Start de l’app • On veut des utilisateurs à jour • A chaque mise à jour, on vide le cache local et on force le download des fichiers de base • Fichier de config • Assets • Lors des autres lancements, 3 secondes en temps limite (=> marche mieux sur iPhone)
- 36. Un reverse proxy ? • Proxy : transmet les requêtes d’un client • Proxy inverse : transmet les requêtes à un serveur interne - peut être intelligent - Apache api.sudouest.frvarnish GET /article/12345 cache miss GET /article/12345GET /article/12345 cache hit
- 37. Reverse Proxy • 99% traffic anonyme : Exemple GET /home Apache 500 500 max-age 60 : 1 par minute e-tag : 304 varnish 500 1 max-age 60 e-tag max-age 60 e-tag • Dumb Server / 500 mbits - 1 Gbits / 32 - 64 Go • Tout en RAM, Cluster
- 38. Image Resizer / Thumbor • Optimisation mémoire (Android ?) • URL : « api.sudouest.fr/image/200/450/ image.jpg » • Mode « Smart »
- 39. Schéma logique varnish frontal 1 500 mbits Apache ML Thumbor Cluster varnish frontal 2 500 mbits varnish back 1 1 Gbits varnish back 2 1 Gbits Apache SO Apache Dep varnish frontal 3 500 mbits DNS Resolver CDN externe infini
- 40. Nos outils
- 41. Outil web interne • Choix éditeur / version / environnement • Choix du web service et des paramètres
- 42. Charles Proxy
- 44. Charles Proxy
- 45. Charles dans la vie • « Le serveur retourne bien les nouvelles données » • « L’Ad server retourne 200 / NO FILL » • « je suis chez FREE » (Throttling Orange) • Infrastructure KO
- 52. Crashlytics • SDK à intégrer au projet • Suivi dans le temps :
- 53. New Relic - $$$
- 54. Fonctionnement • Instrumente chaque appel réseau • Instrumente le temps passé dans les activités principales • Ajoute son code au moment de la compilation du projet
- 57. Stacktrace
- 60. Build : 3 parties • 1 moteur core par plateforme • 1 pack ressources par éditeur / plateforme • 1 pack « wording »
- 61. Build : processus • JENKINS en post-commit sur GIT • iOS : build inhouse (entreprise) et adhoc • Tests à 90% sur la inhouse. • Fin de recette sur adhoc (peu de devices) • Mise en prod manuelle • Android : 1 version build avec le certificat de production. Si recette OK => publication
- 62. En conclusion • Avoir le pouvoir depuis le serveur : « tirer un fil » • Contenu responsive hybride et adaptatif • Penser les futures extensions de l’app : o-auth, webview, deeplink • Monitoring actionnable • Automatiser la génération