Dans R Shiny il y a un unique point d’entrée.
J’ai dû installer une solution externe à Shiny, un package R qui s’appelle plumber, pour faire quelques Api. C’est vrai que ça m’avait gêné. Après c’est sans doute RStudio qui arbitre entre ses licences commerciales et ouvertes pour Shiny.
edit : Je ne cherche pas à remplacer R Shiny là où il est bon. Je cherche un framework qui sache compléter R Shiny là où il pêche.
Pas sans connaître plus précisément tes besoins.
Mais je veux faire la distinction entre ce que j’avais compris au départ comme « j’aimerais apprendre X » et ce qui ressort un peu plus de tes dernières réponses, qui est plutôt « j’aimerais me servir de X de manière concrète pour renforcer ce que mon projet fait déjà ». Les deux besoins ne tirent pas les mêmes rapports engagement/bénéfices.
Flask est avantageux pour apprendre moins de choses, moins structurées, mais les mettre en application rapidement. Du coup c’est aussi avantageux pour embrayer vite sur les outillages annexes (puisque tu as plus de « bande passante cérébrale » pour emmagasiner ces savoirs là en même temps). C’est un meilleur choix pour se former en autodidacte, et/ou pour prototyper.
Dans cette optique, un exemple de plan de formation serait de créer une API REST qui correspond actuellement à une de tes ressources principales dans une des bases de données SQL que tu as. Du pur CRUD à trois niveaux : au niveau SQL (Alchemy), au niveau REST (Flask REST), et au niveau IHM (du simple JQuery ce sera déjà tip top). Si tu sais faire une vue comme ça, du modèle jusqu’à l’IHM, tu auras le feeling de ce que ça implique au niveau Python. Ajoute quelques tests unitaires, et tu as déjà un vrai projet minimaliste de micro-service.
Note : si tu vas dans cette direction, tu peux jeter un oeil aux dossiers « exemple » dans les projets Flask, il y a souvent des choses sympa pour foncer tête baissée.
En revanche, si tu veux plutôt bosser en mode framework, avec Django, je te conseillerais une autre approche. Prends la documentation du projet, et lis-la. Vraiment… Tu prends les concepts, un par un, et tu lis la théorie avant même d’y toucher. Quand tu as lu la doc, là tu prend un projet existant (type « pet shop »), et tu pars de ça pour y intégrer une vue à toi.
Ce sont deux approches radicalement différentes. Je crois que je n’ai pas besoin de dire laquelle je préfère 
Côté IHM du Jquery ? Il y a un système de template avec Jinja2 pourtant ?
En fait je veux apprendre mais pas seulement pour la beauté du geste. R Shiny est très bon en dashboard, courbe et même gestion de l’IHM. En revanche pour ce qui est mise à jour de données c’est pas trop ça que ce soit front (absence de forms) que back où j’ai recrée un système de forms basique mais non modulaire que je dois réécrire à chaque fois. D’ailleurs j’ai aussi du créer un système de mise à jour pour SQL server, qui me génère des requêtes SQL à partir d’un dataframe.
Et donc pour jouer sur les mots c’est plutôt une recherche de complément de ce qu’il ne sait pas faire, mais pas un renforcement ni un remplacement.
édit : mais aussi un apprentissage de quelque chose de complet pour enrichir mon CV.
Comme mon pitch c’est « pour apprendre, plus c’est simple, plus c’est rapide, mieux c’est ! », bah JQuery (ou même du pur JS) adossé à une API REST de type CRUD tu ne peux pas faire plus simple et efficace. Un appel Ajax sur un bouton « ajouter », un appel sur un bouton « supprimer », un appel pour remplir un tableau, et un appel pour éditer une ligne du tableau… Et tu as une app. Côté serveur, tu sers une API. Côté client ton JS génère la vue. Et tu es presque à l’état de l’art en terme d’architecture web ultra-light.
Tu peux très bien faire ta vue côté serveur. On fait ça depuis les années 80, une époque où les clients n’était pas assez rapides pour gérer quoi que ce soit. Mais en 2020 c’est plutôt un anti-pattern (même si ça revient à la mode régulièrement…). Que ça soit en Python ou PHP, ou même avec JSP dans le monde Java, ou NodeJS sur le backend dans le monde JS, c’est pas très fifou à mes yeux. Ton serveur est là pour faire le gros du travail (tenir la charge), pas pour gérer de l’IHM. D’ailleurs, quand tu commences à penser Cloud, qu’est-ce que tu préfères : une IHM générée côté serveur où c’est toi qui paies le CPU à la seconde, ou une IHM générée côté client ?* 
-* La réponse sérieuse est : ça dépend du coût de la seconde de CPU par rapport au coup des Ko de données sur le réseau quand tu transfères la page avec le JS hors cache…
L’idée du micro service est de tout rentre indépendants et de ne passer plus que par des webservice (REST ou autre comme soap) pour faire tout communiquer.
Vu que ton ihm et ton modèle seront chacun dans un coin, il n’y a plus de limitation technique imposée par la communication. Il faudra documenter tes endpoint et c’est tout. Tu peux aussi bien faire du python, du Java, du R, etc. N’importe quoi du moment que tu peux consommer un webservice. Tu as même des extensions pour navigateur (voir le navigateur lui même) qui te propose ça.
La, on parle même pas de micro service mais juste de service. Quand on va plus loin dans la servicisation(?), c’est chaque bloque fonctionnel qui propose un endpoint pour une plus grande interoperabilité.
(Et après, on parle plus de programmation orientée objet mais de programmation orientée agent quand on ajoute de la proaction)
C’est vraiment une philosophie de développement.
Il faut donc que tu te penches sur 2 choses : ce qui t’amuse ( parce que c’est important) et ce qui te rend service (parce que ça te nourrit).
Dans cette optique plutôt que tout réinventer il faudrait passer par de l’Angular ou du Vue.js (ou du React). J’ai d’ailleurs vu, lorsque j’étais PO, un projet en back Java, dont les échanges avec l’IHM était uniquement via Api. Avec de l’Angular.
Ce n’est pas de l’AS400 ni du gros système non plus. Il me semble que R Shiny fonctionne de façon transparente comme tu me dis. Quand on fait un Ctrl-U on ne voit que quelques div cibles. À partir d’un fichier ui.R il génére tout un IHM (qu’on voit avec F12) . Mais c’est lui gère les échanges entre front et back (sauf quand j’ai fait un truc en ajax dont @Mistermick m’a aidé à corriger un souci là (lien)) .
Une absence de CRUD et de template ne me gêne pas dans un IHM interactif sans beaucoup de saisie, en revanche avec pas mal de saisie je n’en dirai pas autant.
Ça m’amuse de réinventer la roue mais pas pour tout, c’est-à-dire ou bien pour apprendre ou bien pour tordre à ma manière une fonctionnalité dont je préfère mon implémentation à celle existante. Après, tout refaire pour le plaisir, ben non ça m’amuse moins surtout quand il existe des solutions solides et bien pensées. Ce que j’ai fait pour mon gros projet en R Shiny : ne m’interdire aucun développement hors des sentiers battus si nécessaire, mais utiliser les helpers et gestion de l’IHM quand ça fonctionne bien.
Et en plus si je vais vers du Flask, très léger, ça veut dire qu’il faut aussi que je me mette à un framework front. C’est-à-dire remplacer un apprentissage Django par un apprentissage Flask + un apprentissage Vue.js ( *** ) . D’un framework léger Flask je vais me retrouver dans un tunnel d’apprentissage et de mise en place. ( ** )
Plus je vous lis tout les 2, plus je me dis que Django serait préférable à tout point de vue. Une fois que je me serai fait les dents dessus peut-être que je me mettrai Flask + Vue.js après une expérience plus importante en Django. ( * )
À moins que Django soit une usine à gaz. Ce qui ne semble pas être le cas dans l’exemple du projet «jllorencetti/pets» dont le lien github a été posté dans un des messages précédents.
edit : *= Et pour des micros projets Flask sera sûrement pertinent, amusant et intéressant, mais pour un projet de taille moyenne je n’en suis pas persuadé.
édit 2: ** en plus avec du Flask+Vue j’aurais moins de fonctionnalités qu’avec Django tout seul ! J’y perds en investissement de mise en place comparé aux fonctionnalités.
édit 3: *** Je n’arrête pas de parler de Vue.js car il me paraît plus souple qu’Angular qui me paraît assez rigide et avec une courbe d’apprentissage assez forte . Et la syntaxe de React me gêne notamment, mais pas que, à cause du fait de mélanger du js avec de l’html sans quote .
Angular ou VueJS ou ReactJS vs JQuery en fait tu retombes exactement sur le même débat fondamental : est-ce que tu veux embarquer un framework structurant, lire sa doc, te prendre sa lourdeur.
Tu peux appliquer quasi-strictement tous les mêmes critères que j’ai mentionnés pour Flask vs Django, pour faire ton choix. Sauf qu’en plus, dans le monde JS, tu oublies le LTS (ce que mentionnait déjà @damaki plus haut)… Dans un an ton code sera de la dette technique si tu ne le tiens pas à jour. Alors que du code JQuery tu peux le laisser tourner des années en montant juste la version de la lib (les fonctions de bases sont maintenant trèèèèès rarement dépréciées).
Je suis tombé sur cette série de 7 articles plutôt bien écrit sur Flask et VueJS.
Ça donne une impression de clarté, simplicité et efficacité. Mais je ne voudrais pas que ça soit trompeur et que ça se révèle de guingois.
Tout ce qui manquerait à Flask de base serait dans cet exemple ? (Où ils parlent de composants tierces) Et s’il y a du template en front, j’ai l’impression qu’il faut se taper du CRUD côté back même si a l’air assez concis.
édit : un commentaire dans cet article parle de WTForms. Tout ça et les précédents composants tierces de l’article initial se branchent tout seul où il faut faire des pieds et des mains pour que ça fonctionne ensemble ?
Tes questions sont celles qui nécessitent un niveau assez expert dans les technos, ça dépasse la simple veille et les concepts d’architecture qui vont avec du prototypage. Tu es en train de demander un cadrage technique complet là… Même si tu l’obtenais, je pense que ça ne t’aiderait pas forcément des masses, parce que tu poses la question à une audience qui ne connaît pas ta boîte, ton projet, etc. (Note : c’est pour ça que les connards de consultants comme moi sont bien payés quand on fait des missions d’audit et de cadrage chez des clients, c’est parce que les clients ont déjà essayé les réponses toutes faites, en voulant économiser les jours à se retrousser les manches pour apprendre, et se sont planté les pieds dans le tapis quand même ^_^)
Sinon il y a emberjs qui a un cycle de dev raisonnable, est bien maintenu et se tient loin de la hype.
(peut-être hors sujet ?)
Ça veut dire quoi debug visuel ?
Je suppose que c’est un moyen d’afficher l’état des variables comme ce que propose cake php : https://book.cakephp.org/3/fr/development/debugging.html
À moins que ma mémoire me fasse défaut sur le nom du framework, l’éditeur informatique dont je parlais plus tôt avait abandonné EmberJS pour AngularJS car ils n’étaient pas content d’EmberJS mais je ne me souviens plus pourquoi.
Je ne sais pas. J’ai fait un copier-coller de l’expression dans l’article comparatif. Je suppose que ça veut dire un système de debuggage plus textuel que d’autres et moins sexy. Après ça ne me dépaysera pas du mode debug de RStudio assez minimaliste.
heu oui mais non.
Même si le côté Api de Flask + VueJS, ou d’autres associations à la carte, ont l’air très séduisants il y a effectivement trop de questions à se poser et à mettre en place pour chacun des composants à configurer aux petits oignons pour la situation ci-dessous:
On n’est pas avec le DSI, l’admin sys et le lead dev à discuter de ce qu’on va faire avec 4 dévs et 50 utilisateurs, on est avec Philippe et 5 utilisateurs + un utilisateur clé (qui est aussi responsable de production métier) et pis c’est tout . Ce qui me fait encore plus aller vers Django compte tenu certes de mes presque 3 ans d’expérience en R Shiny (+ auparavant divers autoapprentissages php, CakePHP, un peu de Python en) mais qui risque de ramer si je dois tester des composants externes.
Un article ci dessous bien fait sur le choix des framework Web pour Python qui ne se contente pas de faire des comparaisons mais qui pose les mêmes questions judicieuses que toi.
« The de-facto standard for good reason, Django is the dominant full-stack framework for Python. Excellent for getting started quickly and with a proven track record for scaling, Django is a great fit for many projects.»
Ce paragraphe ci-dessus me fait dire que moi tout seul et mes utilisateurs qui peuvent tenir dans une pièce auraient du mal à rentrer dans les cases d’une réunion de cadrage d’un service informatique : une solution clé en main étant plus approprié AMHA ( *) . Après je peux me tromper . Mais je ne me suis pas mal débrouillé avec R Shiny… sauf peut-être la dette technique…mais de toute façon avec un SI composé d’une seule personne et d’un débit internet anémique…
édit : * = une solution clé en main, comme Django visiblement, étant plus appropriée AMHA, en lisant les divers contributions et suggestions de ce fil 
Je pose la question parce que j’utilise Django pour un projet perso (et apprendre Django et du webdev fullstack par la même occasion) et je debug dans tous les sens, aussi bien avec des plugin à ajouter à Django que à partir de mon IDE (ici: Visual Studio Code):
… Et en creusant un peu plus je pense que l’article que tu as donné tout pourri mal informé:
Django doesn’t offer multiple types of databases.
Ils n’ont pas lu la doc ? (PostgreSQL, MariaDB, MySQL, Oracle ,SQLite). Et si c’est « plusieurs DB en même temps », oui c’est possible.
Django doesn’t have any support for API.
« Any » support ? Le plugin/extension/whatever le plus populaire pour Django c’est Django Rest Framework, qui permet très simplement de créer une API REST à partir de tes modèles.
Flask does not offer dynamic HTML pages.
?
Flask n’empêche pas de mettre du Javascript dans ses pages générées.
Flask web framework uses a Ninja2 template design.
C’est Jinja2. Et c’est un moteur de template, pas un « design » (moteur que Django peut aussi l’utiliser).
Features of Flask: […] Extensive documentation.
[…]
The best feature of Django is Robust documentation.
Wut ?
Haaaa Python, la troisième meilleure option quel que soit le projet. Le visual basic de 2020 :).
Aaargl un troll ?! 
En tout cas du point de vue de la syntaxe et de la grammaire Python n’a rien à voir avec le langage VB, j’apprécie le premier et j’ai tout fait pour ne plus faire du second au début de ma carrière il y a plus de 20 ans.
Mais tu tombes bien de passer par là, à moins que je confonde ce n’est pas toi qui critiquait Django ? C’était dans un fil sur le remplacement d’un CRM par Django, mais peut-être que tu critiquais en fait toutes les tentatives de refaire à la main les CRM et ERP.
Ou alors tu ne critiques pas Python en tant que tel mais tu critiques le fait qu’il soit présenté comme la réponse à tout ? : rappel je suis assez premier degré, j’ai souvent du mal à discerner les différents niveaux d’ironie 
C’est quoi ton véritable avis en fait ? Sur Django et Python.
C’est souvent le risque de ce genre de comparatif, difficile de se faire une opinion car on n’est pas sûr que les gens l’ont rempli consciencieusement.
.
C’est pas un troll, c’est un fond de verite sur le ton de l’humour mais faut pas y chercher trop. C’est vrai, Python est un langage facile d’accès avec une liste de defaut longue mais aussi plus d’avantages. C’est vraiment le troisième meilleurs choix pour quasi tout. C’est mediocre pour tout, et c’est une énorme force. C’est jamais une grosse erreur comme PHP. Et de meme, ca remplit la case de « langage de programmation facile a appréhender sans se tirer une cartouche de shotgun dans le pied », souvent par des gens qui sont pas ultra experts dans un domaine particulier, mais qui se concentrent sur un objectif business pressant, en type « Rapid Application Development » avec les libs kivonbien. Bref exactement le meme role que Visual Basic remplissait il y a des années, avec des leçons apprises depuis et un environment technologique different orienté web et micro-service, mais meme role dans le grand foutoir des choses. Bref, demi troll, je maintiens tout ce que j’ai dit sur le ton de l’humour, mais y a des raisons pas trollesques.
.
Je dois dire que @GloP derrière l’arrivée fracassante, il dit ce que je disais aussi dans un de mes premiers messages. Dans les grosses boîtes Python est relativement cantonné à l’automatisation, et PHP aux sites de com’ ou de marketing à monter vite par une boîte de web design. Personne ou presque ne fait le choix de Python ou PHP pour un projet massif.
Mais dans les petites structures où chacun doit faire un peu de tout, du coup ce sont de très bons outils.
L’argument numéro 1 est que le ticket d’entrée est cher et que personne ne veut le payer. Sur le court terme, React et Vue sont largement supérieurs. C’est probablement cette raison qui rend React et Vue aussi populaires ; ils sont facilement approchables, on peut les apprendre graduellement, tout en sortant rapidement une appli. Ember te force à d’abord quasiment tout apprendre pour pouvoir faire une appli utilisable. J’en suis à la moitié du bouquin et j’ai du balancer dedans 30 ou 40 heures, mais je suis loin de pouvoir développer mon appli perso complète avec. Par contre je vois la valeur du framework, clairement, par rapport à du React ou du Angular. C’est solide, maintenable, bien pensé et géré par des gens qui savent faire tourner une prod sur le long terme ; ça se sent.
Mais je pense que sur le long terme, sur une appli pas mise à jour souvent, Ember a plus de valeur.
