Utiliser HTTPS, avec de bons algos derrière (de mémoire, The First 200ms of HTTPs est une bonne vidéo, anglaise, pour comprendre l'intérêt d'HTTPS et s'en servir proprement).
Le vol de session, on ne peut pas vraiment s'en prémunir, du fait de la structure du réseau. Le sessID est une interface entre le client final et le serveur; toute personne sachant en présenter un valide sera considérée comme un client final légitime.
Sinon, on devrait tant que possible limiter les requêtes à la BDD (avec des jointures, cache etc), c'est pas tout à fait exact.
Si on peut faire tenir deux requêtes en une seule, alors oui, il est intéressant de les fusionner (jointure) et donc de limiter le nombre de requêtes. Aussi, une requête même complexe (d'apparence) sera parfois plus rapide qu'un traitement par PHP. Elle sera souvent plus claire, et donc plus facile à relire pour la suite.
De plus, la plupart de nos petits jeux gèrent des BDD très légères et les requêtes sont très rapides: mieux vaut coder propre et claire (mais "lourd" à l'exécution) car notre temps de développement est bien plus couteux que le temps de calcul du serveur. Il est d'ailleurs inutile de se préoccuper d'optimisation si l'expérience utilisateur est déjà bonne (qu'une page réponde en 437ms au lieu de 480ms, on s'en fiche complètement, surtout si ces quelques ms ont nécessité du spaghetti code).
Essentiellement, tu gagneras plus à:
→ Faire des requêtes propres utilisant les bonnes jointures
→ Utiliser proprement les index (cf Use the index Luke qui donne de bons conseils)
→ Bien structurer le code et la BDD pour qu'ils soient clair non pas pour toi, maintenant, mais pour n'importe qui plus tard (considère que, quand tu relieras le projet dans 6 mois, tu seras au même point qu'un nouveau développeur)
→ Favoriser les jointures plutôt que les requêtes multiples
... qu'à faire des bricolages stockant des données critiques du jeu dans un conteneur client (aka, dans un système de stockage de données quelconque sur lequel le client a la main).
Après, il n'est pas exclus de pouvoir construire des structures de données 100% partagées, où rien ne serait en BDD et tout en cookies; mais je ne suis pas certain que ce soit intéressant ici en terme de productivité, ni véritablement réalisable sans être une équipe de 10 ingés à plein temps là-dessus.
Le vol de session, on ne peut pas vraiment s'en prémunir, du fait de la structure du réseau. Le sessID est une interface entre le client final et le serveur; toute personne sachant en présenter un valide sera considérée comme un client final légitime.
Sinon, on devrait tant que possible limiter les requêtes à la BDD (avec des jointures, cache etc), c'est pas tout à fait exact.
Si on peut faire tenir deux requêtes en une seule, alors oui, il est intéressant de les fusionner (jointure) et donc de limiter le nombre de requêtes. Aussi, une requête même complexe (d'apparence) sera parfois plus rapide qu'un traitement par PHP. Elle sera souvent plus claire, et donc plus facile à relire pour la suite.
De plus, la plupart de nos petits jeux gèrent des BDD très légères et les requêtes sont très rapides: mieux vaut coder propre et claire (mais "lourd" à l'exécution) car notre temps de développement est bien plus couteux que le temps de calcul du serveur. Il est d'ailleurs inutile de se préoccuper d'optimisation si l'expérience utilisateur est déjà bonne (qu'une page réponde en 437ms au lieu de 480ms, on s'en fiche complètement, surtout si ces quelques ms ont nécessité du spaghetti code).
Essentiellement, tu gagneras plus à:
→ Faire des requêtes propres utilisant les bonnes jointures
→ Utiliser proprement les index (cf Use the index Luke qui donne de bons conseils)
→ Bien structurer le code et la BDD pour qu'ils soient clair non pas pour toi, maintenant, mais pour n'importe qui plus tard (considère que, quand tu relieras le projet dans 6 mois, tu seras au même point qu'un nouveau développeur)
→ Favoriser les jointures plutôt que les requêtes multiples
... qu'à faire des bricolages stockant des données critiques du jeu dans un conteneur client (aka, dans un système de stockage de données quelconque sur lequel le client a la main).
Après, il n'est pas exclus de pouvoir construire des structures de données 100% partagées, où rien ne serait en BDD et tout en cookies; mais je ne suis pas certain que ce soit intéressant ici en terme de productivité, ni véritablement réalisable sans être une équipe de 10 ingés à plein temps là-dessus.