Merci pour ton commentaire !

En effet il y a de moins en moins de “fullstack” et des pans entiers de frameworks ne “servent plus à rien”. Nous avons bien évolué avec Symfony2, nous utilisions un petit peu tout. Mais désormais, nous avons deux applications SPA Backbone et Ember, et n’utilisons Symfony2 plus que comme moteur d’API. Et même pour ce job bien spécifique, l’apport du framework est inestimable !

C’est un challenge pour ces frameworks, et on voit de plus en plus de projets / extensions / bundles pour Symfony2, RoR, Node, etc.. qui visent à faire uniquement de l’API tout en utilisant les composants indispensables de ces frameworks pour le faire.

Je suis passé par les mêmes phases que toi pour finir directeur technique dans une agence de com, avant de revenir aux startups. Je rejoins entièrement ta vision sur les bonnes pratiques que ce soit technique, organisationnel, ou autre, après tout dépend des contextes évidemment, il faut adapter les méthodes à l’environnement.

Concernant le point 1 de cet article, je commence à emettre des réserves. Après avoir pas mal travaillé sur Zend 1 puis 2, puis Symfony 2, je constate que nous utilisons globalement qu’une très petite partie de ces 2 frameworks à moins de s’y investir corps et âme. Il y a quelques mois encore j’étais à 100% sur ces frameworks, et un jour j’ai donné un coup de main à un ami qui devait réaliser un site sans framework ou cms (pour son apprentissage du langage). Du coup on a refait un MVC maison (basé sur la logique Zend 1) ou 100% du code était utilisé.
Depuis j’ai entamé un lent désintéressement des frameworks pour les raisons suivante :
- nous les exploitons généralement assez mal, ou alors il faut s’investir tellement qu’il n’est pas possible de bien le faire sur plusieurs frameworks. Petite parenthèse, ça m’amuse toujours de voir passer des offres d’emploi du type “cherche expert drupal, ezpublish, wordpress, symfony2, …”
- les app utilisent de plus en plus de js/ajax, et côté serveur on se contente de faire se services ou à part vérifier l’intégrité des données + les différentes opérations de sécurité, il n’y a plus grand chose à faire

Du coup, bien que je trouve les frameworks indispensable, ils ne sont pas (plus) si indispensables au vu des nouvelles pratiques. Inutile de déployer les forces armées et les machines de guerre pour sécuriser une place de marché destinée à uniquement gérer les IO.

Manque juste “Ne vous jetez pas sur les technos à la mode”, genre “mySQL c’est out, on doit absolument faire notre app avec MongoDB” alors qu’on prévoit un site transactionnel…

Pas d’accord avec le fait d’ériger le cache comme une règle absolue : le cache est un outil qui répond à certaines problématiques, et toutes les problématiques ne se résolvent pas avec un cache. Tous les sites n’ont pas forcément non plus comme ambition de générer suffisamment de trafic pour qu’un cache soit nécessaire.

J’aurais ajouté à la liste “utilisez l’outil adapté à votre problématique”, pas parce que c’est à la mode, pas parce que X l’utilise. Node.js, mongodb, etc. ne sont pas adaptés à toutes les problématiques.

un gros +1 pour le reste

Globalement d’accord avec le post, sauf peut-être le point 6 qui mériterait quelques détails.

Personnellement je ne suis pas friand des applications qui dépendent du cache pour avoir des perfs correctes, surtout si ça cache des requêtes qui prennent un temps fou quand il est invalidé.

Avant d’aller coller un Varnish devant l’applicatif, ça peut être utile de regarder si certaines pages ne pourraient pas être servies statiquement et certaines requêtes optimisées.

Sinon c’est globalement de bons conseils, surtout le 7. Ce n’est pas parce que les grands comptes en France font n’importe quoi avec l’externalisation que les startups doivent faire pareil ;)