mobile-best-practice/chapters/MBP_027_fr.md

## Éviter les traitements trop complexes sur des données provenant d'un serveur
### Identifiants

// TODO 

### Catégories

| Cycle de vie |  Tiers  |  Responsable  |
|:---------:|:----:|:----:|
| 3. Réalisation (fabrication / développement) | Utilisateur/Terminal | Architecte Logiciel/Développeur |

### Indications

| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
|:-------------------:|:-------------------------:|:---------------------:|
| 3 | 3 | 3 |

|Ressources Economisées                                      |
|:----------------------------------------------------------:|
| Processeur / Mémoire vive / Réseau   |

### Description

Dans le cas de traitements de données issues d'un serveur avec une logique plus ou moins complexe, il est déconseillé de récupérer les données "brutes" et de réaliser toutes les opérations de calcul, de transformation ou encore d'agrégation côté application.

Ces traitements doivent plutôt être réalisés au plus près de la donnée, côté serveur afin de :

- limiter la bande passante à cause du transfert de données non traitées
- profiter des optimisations de la base données distante sur la manipulation des données
- soulager le processeur du téléphone.

Dans ce genre de situation, il peut être intéressant de développer côté serveur un niveau d'API intermédiaire, spécifiquement pour l'application et réduisant la complexité des données. Ce pattern s'appelle Backend for Frontend (BFF).

### Exemple

// TODO

### Principe de validation
| Le nombre ...                                                                       | est inférieur ou égal à   |  
|-------------------------------------------------------------------------------------|:-------------------------:|
| de traitements de données complexe exécutés en dehors du serveur |  1 |
ajout de nouvelle practice 2024-02-07 15:07:29 +00:00			`## Éviter les traitements trop complexes sur des données provenant d'un serveur`
			`### Identifiants`

			`// TODO`

			`### Catégories`

			`\| Cycle de vie \| Tiers \| Responsable \|`
			`\|:---------:\|:----:\|:----:\|`
review current best practice and add new one. move wip best practices on another branch 2024-04-03 18:57:11 +00:00			`\| 3. Réalisation (fabrication / développement) \| Utilisateur/Terminal \| Architecte Logiciel/Développeur \|`
ajout de nouvelle practice 2024-02-07 15:07:29 +00:00
			`### Indications`

			`\| Degré de priorité \| Mise en oeuvre \| Impact écologique \|`
			`\|:-------------------:\|:-------------------------:\|:---------------------:\|`
			`\| 3 \| 3 \| 3 \|`

			`\|Ressources Economisées \|`
			`\|:----------------------------------------------------------:\|`
			`\| Processeur / Mémoire vive / Réseau \|`

			`### Description`

			`Dans le cas de traitements de données issues d'un serveur avec une logique plus ou moins complexe, il est déconseillé de récupérer les données "brutes" et de réaliser toutes les opérations de calcul, de transformation ou encore d'agrégation côté application.`

			`Ces traitements doivent plutôt être réalisés au plus près de la donnée, côté serveur afin de :`

			`- limiter la bande passante à cause du transfert de données non traitées`
			`- profiter des optimisations de la base données distante sur la manipulation des données`
			`- soulager le processeur du téléphone.`

			`Dans ce genre de situation, il peut être intéressant de développer côté serveur un niveau d'API intermédiaire, spécifiquement pour l'application et réduisant la complexité des données. Ce pattern s'appelle Backend for Frontend (BFF).`

			`### Exemple`

			`// TODO`

			`### Principe de validation`
			`\| Le nombre ... \| est inférieur ou égal à \|`
			`\|-------------------------------------------------------------------------------------\|:-------------------------:\|`
			`\| de traitements de données complexe exécutés en dehors du serveur \| 1 \|`
review current best practice and add new one. move wip best practices on another branch 2024-04-03 18:57:11 +00:00