Lexpage visité, nature préservée    —  gogoprog

Discussions

Base de données / Python / AngularJS / ...

Guybrush 8428 Bob
Bonjour,

Je suis en train de développer un système d'encodage de données. L'idée est de proposer une application web permettant de manipuler les différents concepts, de façon dynamique avec AngularJS, et de répercuter ces changements dans une base de données.

Jusqu'à présent, j'envisageais une BD relationnelle, avec une couche Python/Django pour proposer une API REST au client. Cependant, après avoir écrit la plupart de mes services RESET, je me rends compte que ça n'est pas super pratique, parce que je dois composer/décomposer les objets de nombreuses fois (par exemple, le passage relationnel -> objet, puis objet -> json, puis json -> html et ensuite dans l'autre sens).

Vu qu'il n'y a aucune donnée confidentielle dans la base de données, j'envisageai de modifier mon approche : une application web qui va chercher les données en JSON depuis une MongoDB (par exemple), et tout est traité localement via AngularJS, avant d'être synchronisé vers le serveur. Le must du must serait de profiter du coté "persistent" autorisé par HTML5 : le client lance l'application web, les données sont chargées depuis le serveur, tout le travail se fait localement, avec une modification "temps-réel" vers la base locale, et le client peut choisir de "sauver" la base locale sur le serveur.

Est-ce que vous avez des commentaires concernant l'une ou l'autre approche, et des pointeurs pour me renseigner ? Je ne connais pas bien AngularJS, mais est-ce qu'il n'est pas possible d'avoir une sorte d'équivalent "local" de MongoDB ? Ou un mécanisme permettant d'interagir en temps-réel entre l'application cliente et la base MongoDB (qui serait totalement exposée) sans avoir à écrire une API intermédiaire ?

Ah oui, j'oubliais : j'aimerai éviter NodeJS, parce que ça fait encore un truc en plus à apprendre :-D (mais j'imagine que via NodeJS, c'est assez direct si y a un support de MongoDB depuis NodeJS).
roidelapluie 339 Maitre jedi
Là ça me fait penser à du meteorJS
Tchou 3587 Bob
SQLite, webSQL (en voie d'abandon, regarder plutôt ce qui suit) ou IndexedDB ? Ou webstorage en cas de données basiques ? Ou j'ai mal compris la question ?

La dernière fois que j'ai regardé ça, c'était encore un champ de mine et difficilement exploitable, encore avec un support faible et fragmenté suivant les browsers. Ça a dû s'améliorer depuis.

Après, si c'est du html, si tu n'as pas la maîtrise des gens qui se connectent dessus, n'oublie pas que le client peut être un smartphone ou même un laptop qui est actuellement en mobilité et ne peut pas synchroniser pile au moment où il devrai, par manque de réseau. Si ton appli ne sera utilisée que dans un seul lieu avec réseau, cette remarque n'a pas lieu d'être (ou bien moins).


Ce message a été modifié 1 fois. Dernière modification : 8 décembre 2014 à 16:21 par Tchou.

Guybrush 8428 Bob
Je vais regarder MeteorJS et IndexedDB.

Je vais donner quelques détails sur le projet. L'objectif est de fournir un ensemble de services à destination des écoles. La plupart de ces services font intervenir des algorithmes d'optimisation combinatoire (d'où l'autre topic) que je ferai tourner en local. Pour servir de passerelle entre ces algorithmes et les écoles, je souhaite offrir un front-end permettant d'encoder les données nécessaires à l'algorithme, et d'afficher les données résultants de cet algorithme.

Par exemple, pour mon cas de base, il m'est nécessaire d'avoir une liste des classes, leur cursus ainsi que les enseignants qui interviennent dans ce cursus (via une charge horaire et une matière). J'aimerai fournir une application web permettant d'encoder ces données. Afin de rendre l'encodage "agréable", j'aimerai que l'application soit très dynamique, AngularJS est prévu en ce sens.

De manière générale, ce qui m'importe, c'est juste de fournir un moyen simple d'insérer, modifier, supprimer et lire les données qui sont dans une base de données (relationnelles ou non) propre au client. A la rigueur, je pourrai faire un client lourd et charger/sauver des fichiers contenant ces données, mais je souhaite utiliser une application web essentiellement pour faciliter la mise à jour et le contrôle sur les acteurs.

Mon idée est donc que le client peut avoir totalement accès à la base de données s'il le souhaite, puisque tout ce qu'il peut faire de mal dedans (s'il contourne l'application web pour gérer les données) sera, essentiellement, son problème. J'envisageai, avant de poster ici, et après avoir écrit l'API REST en Python, de simplement "exporter la DB" vers un fichier, fichier qui serait accessible par le client (car hébergé sur un serveur) et manipulable par l'application (du JSON directement accessible depuis AngularJS). Le souci, c'est qu'AngularJS ne semble pas avoir de quoi "manipuler" un tel fichier (à juste titre, c'est pas son objectif).

Je dois donc soit envisager qu'AngularJS puisse manipuler cette DB (localement, via IndexedDB si j'ai bien compris), soit qu'il puisse interagir avec la DB distante (MeteorJS ? MongoDB a aussi un ensemble d'applications annexes proposant une interface REST pour manipuler la DB). Dans le premier cas, cela signifie que le client peut "télécharger" les données, les manipuler, puis les synchroniser (et je sers essentiellement de Dropbox spécifique). Dans le 2e cas, la synchronisation se fait en temps-réel (via l'interface REST).

Il faut savoir qu'en terme de volumes, dans une db relationnelle, ça doit faire 5000 tuples environ sur 10 relations. C'est donc très léger. Niveau fréquentation/usage, je n'envisage même pas qu'il puisse y avoir plus d'une ou deux personnes simultanément. Je peux donc me permettre d'avoir une solution très simple pour stocker les données, tant qu'elle est bi-directionnelle et interrogeable directement depuis AngularJS sans avoir à écrire 30 000 lignes de code servant à faire le pont entre les 2 technos.
Guybrush 8428 Bob
Je ne suis pas sûr d'avoir bien compris ce que MeteorJS propose... :-D

Pour IndexedDB, y a du pour et du contre. J'ai un peu l'impression que ça va dépasser ce dont j'ai besoin, tout en ne proposant pas un mécanisme simple d'import/export. A ce titre, je me demande si passer par LocalStorage + le support FileReader/FileSaver d'HTML 5 ne pourrait pas me suffire : j'importe les objets dans le localstorage, et je les exporte vers un fichier local. Un peu à la manière d'un client lourd "Load file/save file" où la working memory serait le localstorage...

J'ai quand même encore une appréhension de ne pas avoir la main sur les données... Un truc comme Freebase (mais sans que ça soit lié à ce service) pourrait faire l'affaire... ou alors, combiner les deux approches : j'offre un support simple de "charger/sauver situation en ligne" via Django, et l'utilisateur travaille à 100% en local, à lui de s'assurer de ne pas oublier de cliquer sur "sauver" :-D

[Edit : à vue de nez, je pense qu'un combo MongoDB + Crest (API Rest pour MongoDB en Node.js) + Angular pourrait convenir pour la synchronisation "temps-réel" (ou presque). Reste que je n'ai aucune idée de l'empreinte mémoire de MongoDB + NodeJS/Crest, et qu'il faudrait que je puisse "mocker" ces services afin de pouvoir tester mon application AngularJS sans nécessiter un accès au VPS du Lexpage (accès impossible au boulot).


Ce message a été modifié 2 fois. Dernière modification : 8 décembre 2014 à 18:05 par Guybrush.

Guybrush 8428 Bob
J'ai fait un peu le tour de ce que j'ai pu trouver sur Google... Alors, on a notamment Taffy et Loki.js qui proposent des databases locales assez performantes. Dans les deux cas, la principale difficulté est sans doute l'import/export, même si via JSON, l'export est simple (et l'import peut se faire de la même façon avec un peu de logique derrière).

Mais de ce que j'ai pu lire, la solution vers laquelle je vais sans doute me tourner, c'est le couple CouchDB/PouchDB. Le premier est un simili-MongoDB, interrogeable via JS (coté serveur). Le second est une implémentation JS de CouchDB, fonctionnant aussi bien en local (LocalStorage, IndexedDB, ... selon ce qui est disponible) qu'en distant, via une synchronisation avec CouchDB. Cela signifie qu'il m'est à la fois possible de générer les données localement (à des fins de tests) et de facilement pouvoir intégrer la synchronisation avec une db distante.

Je vais me renseigner demain, entre deux réunions, et je ferai un retour si j'obtiens quelque chose de concluant.
pom 145 Padawan
Difficile de faire le tri dans les technos JS, hein? ;)
J'en suis là aussi (mais moi pour comprendre la notion de module en js...)

Pour la partie persistance offline, tu peux regarder lawnchair ou localForage.
Cet article te donne une petite idée.
Fabe 610 Geek
Hello,

Je n'ai pas trop pris le temps de m'impregner de ton sujet mais je viens de tomber sur ce recueil de littérature sur la conception d'applis Web "offline first"

Il y a sûrement des choses à garder là dedans :-)
github.com/pazguille/off…
Guybrush 8428 Bob
C'est "pocketisé", il ne me reste plus qu'à trouver un peu de temps pour lire ça :-)

Merci !
Guybrush 8428 Bob
Après lecture de l'article, je me rends compte que l'éco-système javascript est bien plus riche que ce que j'imaginais.
Moi qui hésitais encore à mettre "Javascript" sur mon CV, je pense que ça vaut définitivement la peine :-D

Je vais m'orienter vers une solution PouchDB (avec, à terme, couchDB derrière) et AngularJS. Il reste à découvrir AngularsJS, mais vu le boulot insipide que je fais en journée, ça ne devrait pas prendre trop de temps :-D

Un conseil en particulier pour débuter avec AngularJS ? Les tutoriels ne parlent pas beaucoup des "modules" que l'on peut faire, mais j'ai l'impression que c'est un peu indispensable vu ce que j'envisage de faire (essentiellement, 3 pages avec BEAUCOUP de dynamisme).

N'hésitez pas à poster des liens comme celui de Pom ou Fabe, je cherche à occuper mon cerveau en journée, ça ne me fait pas de mal et c'est intéressant :-D

Répondre

Vous devez être inscrit et identifié.