Symfony ou Django ou [Flask] ? Angular/React/ [Vuejs 3] /Stimulus?

J’ai trouvé Bokeh qui a l’air pas mal. À creuser.

Je suis en train de faire un POC Flask avec Bokeh et Vue

:slight_smile:

  • avec un render_template() minimaliste
    • pointant sur un fichier html contenant
      • des div cibles réceptionnant des composants Bokeh (bokeh.plotting.figure()) émis par Flask grâce à bokek.embed.json_item()
      • des div contenant une architecture vue 3 (avec changement de délimiteur de vue en Array('[[,']]') , pour l’instant au niveau de chaque composant, pour ne pas marcher sur les plate-bandes des balises jinja2 de Flask)
  • et des sources de données côté serveur grâce à flask.jsonify()

Il faut maintenant:

  • que je fasse discuter tout cela ensemble (notamment Vue avec le js Bokeh, mais aussi les figures Bokeh entre elles)
  • que j’organise l’architecture fichiers et répertoires côté client et serveur car pour l’instant j’ai tout mis dans un même fichier htmtl et un même fichier python.

Je teste Vue grâce à vue3-sfc-loader fait par Franck Freiburger (de Strasbourg visiblement !)

Je garderais vue3-sfc-loader en prod s’il est robuste et s’il accepte bien les composants Vue qui existent à droite et à gauche. C’est très récent (v0.8.3), la version v0.1.0 date du 21 novembre 2020. Bon après tôt ou tard je devrais passer par npm et Parcel pour le côté client de Flask (contrairement à R Shiny où je voulais éviter cela car R Shiny a sa propre solution cliente en natif intégrée qui masque le js sauf les quelques adaptations js que j’avais fait).

J’ai mis du temps à comprendre l’intérêt de vuex: voici un article tutoriel qui l’explique très bien.

Et pendant que j’y suis sur le même site un autre article sur Flask + vue.

En dépit qu’il faille se coltiner les bizarreries des chemins et dépendances du répertoires node_modules de nodejs, et que nodejs n’ait pas de gestionnaires d’environnement comme conda ou pip (oui il y a nvm mais c’est par version et non par projet)(*) … putain je trouve que Vue 3 est vraiment pas mal du tout !!

:star_struck:

Et la conjonction de vue cli, npm run serve et npm run build permet de ne pas se farcir d’autres couches comme webpack puisque ça met en œuvre les mêmes fonctionnalités que ce dernier. En d’autres termes j’ai abandonné l’idée d’utiliser vue3-sfc-loader qui finalement obligeait à faire des acrobaties exceptés pour des petits POC. J’ai réussi à changer les delimiteurs pour Flask en Vue 3 là (lien S. O.) .

Sinon j’ai trouvé des tutos mieux fait pour mettre en œuvre Vue 3 avec Vuex et vue router . Ce n’est pas évident de trouver des bons tutos pour Vue 3 car cette version 3 est très récente : septembre 2020.

Édit,
PS: *= En fait j’ai finalement choisi d’installer nodejs par conda, conda install -c conda-forge nodejs, ça me permet d’avoir un environnement étanche en npm -g local à mon utilisateur, c’est-à-dire que ça ne risque pas de péter le serveur nodejs de R shiny-server, même si ça m’agace d’avoir en plus un répertoire node_modules propre à chaque projet, mais bon c’est leur philosophie et on peut l’ajouter dans .gitignore. Et comme j’utilise déjà conda pour Flask et les autres projets python, et qu’il est moins pénible que pip, me permettant néanmoins d’utiliser ce dernier sous conda en cas de besoin.

Édit 2:

Est-ce que vous avez en stock des exemples de menu ? Ceux que j’ai trouvé sont en Vue 2 et pas forcément bien écrit. Ah tiens j’ai trouvé mais pas encore testé S.O.: Using bootstrap5 with vue 3

Je suis en train de finir un POC assez représentatif pour m’autoformer à ce dont j’ai besoin pour mon boulot, en créant 2 graphs Bokeh liés entre eux, par un lasso via js_on_change() côté python (lien) et Bokeh.embed.embed_item() côté js, via json_item() côté python (lien).

C’était vraiment sympa ce POC, je vais pouvoir mettre en œuvre ce que je cherchais à faire, ce qui est l’aboutissement de ce topic.
Merci pour vos conseils et réponses dans les précédents messages. :slight_smile:

Je posterais ici un lien github et/ou stackoverflow de mon POC.

1 « J'aime »

Dans Vue3 tu as la possibilité maintenant de passer l’attribut setup au bloc script pour éviter tous ces exports si tu utilises des composants:
https://v3.vuejs.org/api/sfc-script-setup.html

1 « J'aime »

hop:

J’ai suivi ta suggestion pour l’instant uniquement dans la page principale qui concerne mon POC frontend/src/pages/ProdSinusPage.vue.

Ça me fait penser : est-ce qu’on peut utiliser cette syntaxe, excepté évidemment la balise <script setup>, dans les fichiers js des store, api, router ? Je n’ai pas l’impression.

C’est à dire sans se farcir ces structures imbriquées. Bon après c’est beaucoup moins gênant que dans les fichiers vue.

édit : Mais à part cette syntaxe imbriquée, dont on peut se passer dans les composants vue grâce à composition api, je trouve que le mécanisme et l’organisation de vuejs sont vraiment bien conçus :slight_smile:

Et vuejs m’a permis de suivre le conseil, donné dans les pages précédentes, d’utiliser Flask uniquement pour produire des api et de laisser la gestion de l’UI bien séparée.

J’ai pas creusé assez (je suis tombé sur cette notation très récemment en trouvant Vite puis surtout Vitesse qui l’utilise) mais je n’ai pas l’impression non plus:
https://github.com/vuejs/rfcs/blob/master/active-rfcs/0040-script-setup.md

1 « J'aime »

Je suis plusieurs fois tombé sur Vite, en cherchant des informations sur Vue, en ayant l’impression que c’était encore une couche de plus à lire la page github. J’ai tendance à penser que ce n’est intéressant que pour les gros projets.

Ton message sur Vite m’a incité à me renseigner davantage: cet article ci-dessous est instructif notamment sur les exemples, les domaines d’applications possibles, et les outils pré installés. Je vais finalement garder cet outil en tête au cas où.

« Vite is a new build tool from creators of Vue JS framework. They have released the first version in April 2020. It immediately created a lot of buzz, while raising a question: do we need another build tool?

The answer is yes. Why? Because leading build tools became unbearably bloated. Vite is a swift and refreshing change. Although created by the Vue tribe, it is not limited to Vue. You can use it to build all kinds of JavaScript code, and it has many cool features.»

@Histrion , @Ewi , et tout contributeurs bienvenus :slight_smile:

Vu que j’ai opté pour Flask (*), avec l’optique de l’utiliser avec Vue ou R Shiny, c’est-à-dire uniquement en utilisation d’Api, comme semblent être les bonnes pratiques récentes en ce domaine, que penser de Fastapi ?

Je lis des articles sur cette question, ci-dessous par exemple, mais j’aimerais avoir vos avis.

De toute façon j’ai l’impression que Flask utilisé en mode API et Fastapi sont dans le même esprit, ils ne sont pas vraiment opposables: le 2e est dans l’esprit du 1er en étant plus moderne mais moins répandu ?

PS: Et flask_restful sert à quoi ? Puisque de base Flask sait présenter des api.

(*)Pour l’instant uniquement en POC en l’absence de décantations assez avancées en ce qui concerne les besoins métiers.

PS2: Léger HS par rapport à ma question : j’ai fait un autre POC, RshinyBokehReticulatePOC, en R Shiny python, via reticulate, pas longtemps après FlaskVueBokehPOC.

Ah putain, je suis bien content d’avoir opté pour Flask et VueJs (grâce à vos commentaires sur ce topic).

Je m’amuse comme un petit fou dans l’application, non POC, que je suis en train de réaliser, je rajoute les briques qui me vont, je peux mélanger différentes solutions. À chaque brique je rajoute seulement ce qui est nécessaire, tout étant proche de mes besoins. C’est vraiment souple et en même temps puissant.

  • Flask
    • tout en Rest
    • jwt
    • Blueprint
    • SqlAlchemy (mais seulement pour les requêtes qui ne vont pas bouger ou les formulaires)
  • VueJs 3
    • menu bootstrap
    • vuex
    • router
    • axios
    • jwt
1 « J'aime »

Avant que mon application ne grossisse trop j’ai remplacé Vuex par Pinia …qui va en fait être le très très probable remplaçant de Vuex 4. Conçu par quelqu’un du coeur de l’équipe Vue .

Pinia est moins verbeux que Vuex que ce soit pour la définition du store comme son l’utilisation, tout en restant dans le même esprit. Et donc j’ai fait le changement sans souci.

Evan You @youyuxi, 9:49 AM · 24 nov. 2021:

Pinia is de facto Vuex 5! At this point it’s really a naming/branding issue.

https://twitter.com/youyuxi/status/1463429442076745730

« Comparing Pinia 2 with Vuex 4

Pinia draws these comparisons to Vuex 3 and 4:

Mutations no longer exist. They were very often perceived as extremely verbose. They initially brought devtools integration but that is no longer an issue.

No need to create custom complex wrappers to support TypeScript, everything is typed and the API is designed in a way to leverage TS type inference as much as possible.
»

Et en français:

https://fanzine.dejavue.school/pinia-le-nouveau-store-de-vue-js-deja-vue-2/

Je viens de tomber sur ca :

Ca ressemble a du bricolage mais j’aime bien l’idée de me passer de la syntaxe « aléatoire » du JS :sweat_smile:

Ton message me fait penser à cet échange :

:grin:

Je connaissais apply() en R et j’ai fait connaissance il n’y a pas longtemps avec reduce() en js (qui existe aussi en JS et python).

Ben j’ai mis du temps à m’y faire, mais je trouve ça sympa. Une fonction for simple est plus facile à concevoir et à lire qu’une fonction reduce() ou apply() mais dès qu’on a besoin de plusieurs niveaux ou de complexité, je commence à trouver cela bien plus puissant et claire.

Il faut dire que de faire du R m’a fait faire de la programmation fonctionnelle comme monsieur Jourdain.

Et j’ai vu qu’en JS, depuis que je fais du VueJs c’est-à-dire sans jquery, on est quelques fois presque « obligé » d’utiliser reduce() et autres fonctions de programmation fonctionnelle.

De même en pandas (python), je me suis mis aux df.apply( lambda x: pandas.Series(..)).

Bon après tout écrire en programmation fonctionnelle c’est une autre paire de manche.

PS: Merci de me corriger si je dis des inexactitudes, je ne suis pas forcément à l’aise en théorie.

Marrant de penser à notre échange d’il y a déjà 2 ans sur webpack qui m’inquiétait un peu.

Je m’étonne à presque m’amuser à essayer d’optmiser différents module hétéroclites dans l’implémentation webpack de VueJs (vue.config.js).

En fait ce travail me permet de mieux appréhender l’architecture technique.

Par exemple Webpack Bundle Analyzer m’a permis de faire des alias vers des min.js pour certains modules qui persistaient à utiliser leur version volumineuse non minifiée.

module.exports = {
  configureWebpack: {
    resolve: {
      alias: {
        jquery: path.join(__dirname, "/node_modules/jquery/dist/jquery.min.js"),
        "datatables.net": path.join(
          __dirname,
          "/node_modules/datatables.net/js/jquery.dataTables.min.js"
        ),
        "sockjs-client/dist/sockjs": path.join(
          __dirname,
          "/node_modules/sockjs-client/dist/sockjs.min.js"
        ),
      },
    },
  }
}

Ou alors de faire des imports ciblés d’icones fortawesome car de base sinon
fortawesome importe tout ses icônes (~600Ko !!).

import { faSyncAlt } from "@fortawesome/free-solid-svg-icons/faSyncAlt.js";
import { faPlusCircle } from "@fortawesome/free-solid-svg-icons/faPlusCircle.js";
etc...

Grâce à mon expérience acquise sur webpack depuis un an je suis en train de migrer mon projet de webpack (vue.config.js), vers ViteJs (vite.config.js)
J’ai ramé avec le composant jquery datatable.net mais j’ai finalement réussi (comme j’avais ramé pour la même raison pour vue.config.js).
En fait ça « compile » quasi instantanément.
Mais vite.config.js reste dans une logique syntaxique proche de webpack et acceptant les modules fait pour webpack.

Je me suis aidé au départ de l’article et de l’outil ci-dessous ( webpack-to-vite insuffisant mais qui permet une bonne mise en place de départ) et j’ai résolu chaque obstacle en glanant des infos sur Stackoverflow et Github.

Il faut noter que si ViteJs a été créé par le créateur de VueJs, il peut aussi être utilisé pour d’autres environnements.

  • vanilla
  • vue
  • vue-ts
  • react
  • react-ts
  • preact
  • preact-ts
  • lit-element
  • lit-element-ts
  • svelte
  • svelte-ts

Édit: sur alias, import forteawesome, sur les utilisations de Vite pour les autres frameworks js.

Quand j’étais encore spécialiste BI il y a 6 ans chez un éditeur je m’étonnais de l’attrait des développeurs pour JavaScript.

Mais depuis bientôt 5 ans que je fais du développement web en R Shiny (basé sur un moteur nodejs en fait), et un peu plus d’un an que je fais du VueJs 3, et donc de l’ES6 et plus, je vois que les possibilités de l’ES6 associé à l’écosystème nodejs, aux transpilers, et aux polyfills change la donne et font de l’ES un langage vraiment intéressant, passionnant et puissant dans des framework tels que VueJs ou ses concurrents. :slight_smile:

Sans parler des possibilités côté serveurs en « pur » nodejs ou Nuxt (Architecture VueJs en back) ou ses concurrents.

Reste l’architecture très redondantes de nodejs, mais j’ai vu qu’il existait maintenant pnpm qui évite ces redondances (non testé encore, je ne sais pas si tout les packages restent compatibles, surtout que j’ai des modules assez hétérogènes).

Après je n’oublie pas que chaque langage et environnement de développement est pour certains besoins et cas d’usages, et qu’il ne faut pas hésiter à en sortir et en prendre un autre si ces besoins et cas d’usage ne sont pas les mêmes.

Est-ce que le Node c’est devenu plus facile à monitorer en prod qu’avant ? La dernière fois que j’avais regardé, ça faisait pas rêver par rapport à l’outillage dispo en Java ou en .Net.
L’autre truc que j’avais trouvé aussi un peu lacunaire, c’est l’absence de générateurs de code qui te facilitent la vie en te faisant un vrai projet prêt à balancer en prod’ sans qu’un petit nouveau oublie des trucs. Genre pas oublier de câbler la lib de metrics, bien configurer les loggers, le système d’auth, s’enregistrer auprès de ton annuaire d’application, etc… Certes, je pourrais maintenir moi même des templates pour générer mes applis, mais l’intérêt que quelqu’un d’autre le fasse à ta place, c’est de gagner un maximum de temps.
Si vous ne voyez pas de quoi je parle, je fais référence à ce genre de truc

Je suis intéressé par les réponses à ta question puisque ma mise en prod est artisanale.

git pull origin prod && yarn --cwd frontend run build && sudo systemctl stop monappli.service && sudo systemctl start monappli.service

D’autant que le côté serveur est géré par Flask et non nodejs, pas d’annuaires etc…