Journal Symfony, AngularJS, ....

Posté par phoenix (site web personnel) le 23 septembre 2013 à 14:42. Licence CC By‑SA.

Étiquettes :

sept.

2013

Sommaire

Symfony2
MongoDB
Mes contributions
AngularJS vs Symfony2
Conclusion

Bonjour,

Erratum: Au début je pensais lancer juste un débat du style : AngularJS + Rest vs Symfony2. Mais je me suis dit que je pouvais faire plus et ~~lancer plusieurs débats~~ parler des différentes briques d'un projet existant.

Donc, dans le cadre du développement d'un site Internet e-commerce, j'ai fait du développement en utilisant le framework Symfony2. J'ai testé ce même framework avec une base de données SQL ainsi que la base de données NoSQL MongoDB (base de données orientée document).

Dans la suite je vais vous donner mon avis sur le framework, la base de données NoSQL, et des plugins Symfony2 que je livre à la communauté.

Symfony2

Symfony 2 est un framework PHP permettant le développement de sites Internet. Il est livré par défaut avec un ORM : Doctrine qui permet de faire correspondre à une structure de base de données des classes PHP qui seront automatiquement hydratées.

Le développement PHP s'en retrouve presque agréable (je préfère les langages compilés en règle générale). Le framework est de la même trempe que le Framework Python Django.

Ce dernier m'a d'ailleurs tenté (bien qu'interprété aussi), mais une lecture rapide de la documentation m'a donné l'impression d'être un peu moins pratique à utiliser que Symfony2. Peut-être car je ne fais pas de Python.

Est-ce que des personnes dans l'assemblée ont déjà développé avec Symfony2 et aussi avec Django, et peuvent donner leur avis ?

MongoDB

Mon projet d'abord basé sur une base MySQL a été basculé sur une base de données NoSQL nommée MongoDB.

La raison n'est pas technique (je n'ai pas besoin de replication, de sharding, …., pas assez de visiteurs). J'avais juste envie de tester cette base de données sur mon projet. De plus l'aspect orienté document est agréable au développement.

Ainsi pour des entités avec forte relation, où on ne récupère pas l'un sans l'autre, une seule requête permet de récupérer toutes les informations. Par exemple, dans une base relationnelle, on aura l'habitude de stocker l'entête de facture dans une table, les lignes dans une autre table, les paiements associés dans une troisième table….. Avec Mongo, si je veux récupérer une facture, en une requête je récupère aussi les lignes et les paiements. Cela implique par contre de ne pouvoir requêter facilement sur les lignes de factures indépendamment de leur entête.

Dans le même genre, j'ai entendu parler de CoucheDB.

Que pensez-vous des bases de données orientées documents ? De MongoDB en particulier ? Avez-vous déjà utilisé CoucheDB ?

Mes contributions

Lors du développement de mon projet, j'ai eu besoin de certaines fonctionnalités que je n'ai pas trouvées dans les bundles existant ou qui ne me convenaient pas. Je vous présente ici les différents projets, sachant que pour l'instant ceux-ci ne sont pas parfaits et voir même, la documentation peut laisser à désirer (quand aux tests unitaires ils sont dans le néant).

CollectionBundle

Lien: CollectionBundle

Dans symfony, il est possible d'ajouter dans un formulaire un type collection pour permettre à un utilisateur de saisir une collection de sous-élément (jointure de type OneToMany):

$builder->add('emails', 'collection', array(
    // chaque item du tableau sera un champ « email »
    'type'   => 'email',
    // ces options sont passées à chaque type « email »
    'options'  => array(
        'required'  => false,
        'attr'      => array('class' => 'email-box')
    ),
));

Le problème c'est que dans les formulaires symfony2 il n'est pas possible de gérer des formulaires différents suivant le sous-type de l'objet (gestion de l'héritage dans l'ORM).

CollectionBundle propose deux nouveaux types :

Un type permettant de gérer pour chaque classe fille, un formulaire différent.
Un type permettant de gérer des collections de taille fixe : Exemple toujours 5 éléments, quelque soit le nombre d'éléments rééls en base.

DoctrineMigrationODMBundle

Lien : DoctrineMigrationODMBundle

Pour l'ORM Doctrine, il existe DoctrineMigrationBundle qui permet de faire des migrations de schéma, mais il n'existait pas d'équivalent pour l'ODM gérant MongoDB.

Même si MongoDB est schémaless, et que les données peuvent être migrées à l'execution, je ressens le besoin d'avoir la possiblité d'exécuter des scripts lors des changements de version, pour :

ajouter de nouvelles données (nécessaires) dans des tables.
renommage de collection, suite à gros refactoring.
voir autre

Si ça peut intéresser d'autres personnes. Dites-moi ce que vous en pensez ? Est-ce que je me trompe de chemin ?

FPDI et FPDF_TPL

Des dépôts fpdi et fpdf_tpl qui fonctionnent avec ceux de "tecnick.com/tcpdf" pour les utilisateurs de TCPDF.

Liens:

ImageResizerBundle

Lien : ImageResizerBundle

Dérivé de https://github.com/nresni/ImageResizerBundle, ce bundle ajoute

des caches supplémentaires
de fournir une URL sur la valeur du cache directement (et de générer le cache lors de l'appel de la commande twig)

PiwikBundle

Lien : PiwikBundle

Afin de pouvoir ajouter la gestion de Piwik à l'aide de twig et de service PHP. Ce plugin gère également les paniers e-commerce.

AngularJS vs Symfony2

Voilà la question que je voulais au départ poser.

J'ai découvert AngularJS il y a peu de temps, je trouve le framework vraiment génial, sur le principe (coté développeur).

Mon application est actuellement :

écrite en PHP (avec Symfony2),
a des URL propres,
un cache d'OPCode APC (pour accélérer le traitement des pages)
cache de template propre à Symfony.

Bref, je trouve l'application propre, rapide, … et là, je me demande de l'utilité de AngularJS. Est-ce que ce n'est pas ce compliquer la vie ?

Je m'explique. Utiliser AngularJS nécessite coté serveur une API REST (par exemple). Les templates, les contrôles de formulaires, … se retrouvent coté client (même si les API REST doivent continuer à vérifier la cohérence des données et la sécurité).

Pour une telle application qui nécessite un référencement sur Google, il faut en plus sur le serveur pouvoir afficher les pages générer normalement coté client :

soit par un système de caches si les pages bougent peu, mais dans ce cas, quelle est l'utilité de faire de l'AJAX.
soit en doublant le code et en générant les mêmes pages côté serveur à la demande, mais dans ce cas est-ce vraiment utile de faire de l'AJAX pour de l'AJAX ?
soit en ayant un programme simulant sur le serveur un navigateur et servant les pages simulées au moteur de recherche. Quid de la performance des pages alors ? (Google aime bien que les pages générées soient rapides).

De plus en tant qu'entreprise on ne peut pas ignorer les vieilles versions de navigateurs, ou les navigateurs non libres même si on aimerait bien.

Donc plusieurs questions:

Est-ce que ce type de framework est vraiment intéressant ?
Compatible et performant avec les vieux navigateurs ?
Comment gérez-vous le cotés SEO de ce type de site ? (Ou est-ce que vous décidez de ne pas le gérer ?)
Est-ce performant ?
Comment gérez vous les connexions des utilisateurs (login + mot de passe) avec les API Rest ? Utilisez-vous une URL de ce type: https://login:password@host… ou un identifiant de session ? (Une API REST devant être normalement Stateless).
Peut-être est-ce dédié uniquement à des applications WEB et non des sites WEB ?

Bref quel est votre avis ?

Conclusion

Merci de m'avoir lu jusqu'ici, j'espère ne pas avoir été trop long. Le site dont je parle est celui-ci : http://monlivretdemesse.fr. Je vous laisse juge de la qualité du site et de la rapidité de génération des pages.

# AngularJS est fait pour faire des applications web mono-page.

Posté par LeBouquetin (site web personnel, Mastodon) le 23 septembre 2013 à 15:10. Évalué à 3.

Sur Wikipedia, en Français :

AngularJS est un framework open-source1 JavaScript, au même titre que jQuery, MooTools, Prototype ou Dojo. Il a pour but de simplifier la syntaxe javascript, et de combler les faiblesses de javascript en lui ajoutant de nouvelles fonctionnalités. Et ainsi faciliter la réalisation d'applications web monopages.

Sur la page en Anglais :

AngularJS is an open-source JavaScript framework, maintained by Google, that assists with running single-page applications. Its goal is to augment browser-based applications with model–view–controller (MVC) capability, in an effort to make both development and testing easier.

La question à te poser est de savoir si ton application a vocation à être mono-page ou pas.
- [^] # Re: AngularJS est fait pour faire des applications web mono-page.
  
  Posté par phoenix (site web personnel) le 24 septembre 2013 à 09:26. Évalué à 2.
  
  Pour moi une application web monopages est plus une façon de faire qu'un type d'application.
  
  Même si des applications comme G+, GMail, GDrive se prête bien à se genre de nom et donc de framework, nombre de site sur Internet sont des applis monopages (et donc usant de JS) et pourtant ne sont que des sites WEB.
# J'ai ri

Posté par Nicolas Blanco (site web personnel) le 23 septembre 2013 à 15:11. Évalué à 6.
- [^] # Re: J'ai ri
  
  Posté par dadou92 le 23 septembre 2013 à 16:12. Évalué à 2.
  
  Notre ami est coutumier :
  - Les logiciels sources bientôt illégales
  - GCC Lent : C AINSI
  
  Est ce intentionnel ? Je dirais oui.
  - [^] # Re: J'ai ri
    
    Posté par ʭ ☯ le 23 septembre 2013 à 16:41. Évalué à 3.
    
    C'est parce qu'il vient de se marier, il est prêt pour la suite avec cette BDD.
    
    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: J'ai ri
  
  Posté par phoenix (site web personnel) le 24 septembre 2013 à 09:32. Évalué à 4.
  
  Justement je passe beaucoup de temps avec CoucheDB ;) mais c'est une base qui nous laisse facilement dans la merde.
# Django / Symfony

Posté par Frédéric Péters (site web personnel) le 23 septembre 2013 à 17:11. Évalué à 2.

Je n'ai pas d'expérience avec Symfony mais en 2010 à la djangocong il y avait eu une présentation Django/Symfony, même si les deux projets ont évolués elle peut encore t'intéresser : https://nicolas.perriault.net/talks/2010/django-pour-les-developpeurs-symfony-et-reciproquement/ J'en avais fait l'enregistrement audio (pas réécouté depuis), je viens de l'uploader ici : http://www.0d.be/tmp/d1c8-symfony.ogg

PS : Certains des modèles (sur la première page, Branches fleuries, Thème iĉones) affichent les noms de mois avec une majuscule, ce n'est pas l'usage en français.
- [^] # Re: Django / Symfony
  
  Posté par phoenix (site web personnel) le 24 septembre 2013 à 09:33. Évalué à 2.
  
  Merci, je vais écouter ca dés que possible.
# Couchbase

Posté par Croconux le 23 septembre 2013 à 19:15. Évalué à 5.

Que pensez-vous des bases de données orientées documents ?

Ni pour ni contre. Ca dépend de l'usage. C'est un peu comme dire "que pensez-vous des marteaux ?" Pour planter un clou c'est bien. Pour monter des blancs d'oeuf en neige, bof…
Comme tu le dis, c'est pratique quand on récupère toujours des agrégats d'un coup. Typiquement, sur un site à grande fréquentation, on peu stocker toutes les données d'un utilisateur associées à une clé. Par contre, c'est juste inutilisable pour faire de l'analytique. Ex: Sur un site d'e-commerce, faire du reporting sur les produits les plus commandés ensemble, les paniers moyens, etc… Pour faire ça avec du NoSql, en gros il faut balayer toutes les clés.

De MongoDB en particulier ? Avez-vous déjà utilisé CoucheDB ?

Pas sur MongoDB ou CouchDB mais sur Couchbase, son frère siamois. Les deux sont proches et ont été lancés par le même gars.
Mon dieu quelle merde! (pardon aux familles, toussa). Le bousin a déjà du mal à tenir debout tout seul, sans aucune connexion. Des noeuds tombent sans explication. Au bout d'un moment, ça rame. Il faut redémarrer les noeuds tombés et là on est parti pour long "pending rebalance". Pendant ce temps là, le système est juste à genoux. Il n'y a plus qu'à attendre que ce soit fini à la machine à café. Ma consommation de café a explosé.

Même quand ça tient debout, les performances ne sont pas extraordinaires. Si bien qu'on est en train de basculer sur… MySQL. On n'a pas spécialement besoin dans notre cas de la partie relationnelle mais utilisé façon NoSQL, MySQL décoiffe aussi bien en lecture qu'en écriture. Surtout en écriture. Nous avons des volumes relativement conséquents (5-10 Go) de données à charger/mettre à jour tous les mois et nous devons pouvoir y accéder ensuite rapidement en lecture. Sur Couchbase, le chargement prends 25-30 heures sauf que le bordel ne tient pas assez longtemps et s'écroule avant la fin. Du coup il faut recommencer. Si bien que le mois dernier on avait pas encore réussi à finir l'update que le suivant était déjà là. Sur MySql, bah, ça prend quelques minutes. Voilà, quoi.
- [^] # Re: Couchbase
  
  Posté par mackwic le 23 septembre 2013 à 19:27. Évalué à 4.
  
  Juste pour info, PostGreSQL a un type JSON pour y stocker des documents. Ça permet d'utiliser une NoSQL pour itérer rapidement et de faire un portage facile une fois les modèles stabilisés.
  
  Ref: http://www.postgresql.org/docs/9.3/static/functions-json.html
- [^] # Re: Couchbase
  
  Posté par ckyl le 23 septembre 2013 à 19:53. Évalué à 3.
  
  Nous avons des volumes relativement conséquents (5-10 Go) de données à charger/mettre à jour tous les mois et nous devons pouvoir y accéder ensuite rapidement en lecture.
  
  5 à 10 Go par mois conséquent en 2013 ?
  
  J'ai envie de dire que n'importe quoi de sérieux fait l'affaire. Tu ne verras pas de différence entre un truc ou l'autre par ce que tu es très très loin des limites quelque soit la technos. Après c'est en cache ou c'est pas en cache, mais ça dépend du hard.
  
  La différence fonctionnelle ou de perf devient notable quand un RDBMS sur une grosse machine ne peut pas suivre en volume, en lecture, en écriture ou pour des besoins spécifique. Là ca commence être intéressant de réfléchir à ses besoins et aux choix qu'on va faire pour que ca réponde à nos besoins en terme de perfs / facilité de dev / maintenance. On peut choisir autre chose qu'un RDBMS avant si c'est plus pratique, mais c'est généralement moins mur et moins de compétences dispo, donc sauf besoin précis pas forcément un bon choix.
# Angular JS vs Server Side framework

Posté par RB le 24 septembre 2013 à 01:39. Évalué à 1.

En fait, Angular js et tous les framework JS se concentrent sur la fluidité de l'interface utilisateur dans le cadre d'une utilisation de style applicative: l'utilisateur peut faire des manipulation dont les effets se voient directement à l'écran (exemple typique http://todomvc.com/).

Dans la pratique, ces interfaces sont plus des exceptions que la règle et on a, a mon avis, souvent plus de confort avec le server side et les nombreux composants que l'on peut trouver dans les framework modernes.

Même si Angular JS est purement destiné à la partie cliente, il s'inscrit aussi dans la tendance du "tout js" qui sévit actuellement (voir nodejs pour faire du js serveur side).

Pour ma part, le js (ou languages compilant vers du js) n'est pas (encore) ma tasse de thé et je préfère le choix que me laisse le fait de travailler plus server side dans les languages de mon choix. Mais vu qu'il commence a y avoir pléthore de librairies js fantastiques et qu'on doit faire des sites de plus en plus dynamiques et beau dans les manipulations et les affichages on devra forcément y avoir de plus en plus recours.

NB: Il peut aussi en découler un joli avantage architectural a faire de bonnes APIs REST. Ensuite tu connectes tes pages (angular ou autre) comme des clients, mais tu peux aussi réutiliser cette API pour des applis mobiles ou d'autres site, ça fait une belle interface réutilisable pour accéder a ton modèle/controlleur.
- [^] # Re: Angular JS vs Server Side framework
  
  Posté par Croconux le 24 septembre 2013 à 08:44. Évalué à 2.
  
  Dans la pratique, ces interfaces sont plus des exceptions que la règle et on a, a mon avis, souvent plus de confort avec le server side et les nombreux composants que l'on peut trouver dans les framework modernes.
  
  La partie cliente reste un peu plus artisanale que la partie serveur mais les deux sont complémentaires. Certains traitements ne peuvent se faire que côté serveur pour ne pas exposer tout et n'importe quoi publiquement dans le navigateur. Et même pour ce qui est fait côté client, on est parfois obligé de l'implémenter aussi côté serveur. La validation notamment oblige à faire le boulot en double. Toute donnée validée dans le navigateur doit être validée aussi côté serveur pour éviter le tampering. C'est assez frustrant.
  Je serais assez intéressé par un framework liant les deux: On défini une règle de validation côté serveur et le côte javascript correspondant est généré.
  - [^] # Re: Angular JS vs Server Side framework
    
    Posté par RB le 24 septembre 2013 à 10:42. Évalué à 1.
    
    Il me semble que pas mal de framework faisaient automatiquement cette double validation, surtout ceux orientés "composants", par exemple:
    http://www.pradosoft.com/
    
    Après des framework comme GWT en compilant le java en javascript permettent aussi d'avoir une seul fois le code et de "l'exporter" du côté client.
  - [^] # Re: Angular JS vs Server Side framework
    
    Posté par groumly le 25 septembre 2013 à 07:44. Évalué à 1.
    
    La validation notamment oblige à faire le boulot en double. Toute donnée validée dans le navigateur doit être validée aussi côté serveur pour éviter le tampering. C'est assez frustrant.
    
    Cela dit, on est 2013, on s'attends a ce que la validation soit faite cote client, de facon claire, avec des messages comprehensible, et avant que la requete soit partie au serveur (autant que faire se peut), donc de toutes facons, t'es un peu oblige de te la taper 2 fois quoi qu'il arrive.
    
    Cela dit, c'est une validation differente, cote client c'est plus preventif et pour faire comprendre ce qui ne va pas, cote serveur tu peux te permettre d'etre un peu plus "grumpy cat" et juste repondre "no" avec un 400.
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    - [^] # Re: Angular JS vs Server Side framework
      
      Posté par Laurent J (site web personnel, Mastodon) le 26 septembre 2013 à 12:24. Évalué à 3.
      
      cote serveur tu peux te permettre d'etre un peu plus "grumpy cat" et juste repondre "no" avec un 400.
      
      Non. surtout si tu fais une application qui se dégrade correctement quand le JS n'est pas présent (ou pas exécuté parce que y'a un p*t*n de script de pub qui plante, genre à cause de adblock/ghostery). Il faut donc que quand la validation se fait coté serveur, le formulaire puisse se ré-afficher avec les bons messages d'erreur, et pas un "no".
      - [^] # Re: Angular JS vs Server Side framework
        
        Posté par phoenix (site web personnel) le 26 septembre 2013 à 17:56. Évalué à 2.
        
        En même temps, avec AngularJS, tout est JS et basé sur des APIs REST, donc il n'y a pas de mode dégradé sur ce genre d'application (ce qui m'embête un peu, même si à notre époque le JS est quasi-obligatoire).
      - [^] # Re: Angular JS vs Server Side framework
        
        Posté par Sufflope (site web personnel) le 26 septembre 2013 à 20:44. Évalué à 3.
        
        (ou pas exécuté parce que y'a un p*t*n de script de pub qui plante, genre à cause de adblock/ghostery)
        
        Si tu conditionnes le fonctionnement de ton site au bon fonctionnement de pubs, c'est ton problème.
      - [^] # Re: Angular JS vs Server Side framework
        
        Posté par groumly le 26 septembre 2013 à 21:34. Évalué à 2.
        
        on parle d'une api rest cote serveur, c'est pas comme si ca te servait du HTML avec un form et du rouge la ou il faut, meme si tu te fais chier a donner de la semantique a ta validation, tu vas avoir du json en retour, si t'as pas de js, t'es foutu. C'est une appli riche en javascript quoi.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Django + python

Posté par François GUÉRIN (Mastodon) le 24 septembre 2013 à 14:14. Évalué à 2.

Salut,

Je suis développeur django / python depuis 3 ans déja, et je trouve la puissance de l'ensemble très très bien.

J'ai eu à choisir mon framework de développement (je suis seul développeur dans ma structure), et j'ai choisi django pour ses capaciées ORM (la plupart des applications que je développe sont du CRUD sur des bases de données, pré-éxistantes ou pas).

Je n'ai fait du php que de façon très sporadique, mais clairement je n'aime pas ce langage : typages tableaux / dictionnaires pas clair, fonctions pour tout daire, inconsistance du langage à droite à gauche, modèle objet ajouté à l'arrach… non, vraiment le php n'est pas pour moi (j'ai peut être tord)… L'élégance du python en face n'a rien à voir !

Bon courage !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.