New French post: Upgrading my org-mode websites
All checks were successful
continuous-integration/drone Build is passing

This commit is contained in:
Lucien Cartier-Tilet 2022-08-15 16:49:36 +02:00
parent 8b248296b7
commit 02a9f7f7e3
Signed by: phundrak
GPG Key ID: BD7789E705CB8DCA

View File

@ -4,6 +4,7 @@
#+hugo_base_dir: ../
#+hugo_section: ./
#+hugo_categories: emacs linux conlanging orgmode
#+startup: content
* [EN] Open-Sourcing ALYS :ALYS:
:PROPERTIES:
@ -77,6 +78,174 @@ above.
* Conlanging :@conlang:
** TODO Writing my conlanging docs with Emacs :emacs:conlanging:
* Development :@dev:
** [FR] Mettre à niveau mes sites org-mode :dev:emacs:
:PROPERTIES:
:EXPORT_FILE_NAME: mettre-a-nivea-mes-sites-org-mode
:export_hugo_menu: :menu "main"
:END:
*** Le Problème
Cela fait quelques temps que je réfléchis à une nouvelle manière de
gérer deux de mes sites web, [[https://conlang.phundrak.com][conlang.phundrak.com]] et
[[https://config.phundrak.com][config.phundrak.com]].
Les deux sites sont actuellement générés via un export depuis org-mode
(un des nombreux modes dEmacs) directement vers du HTML. Sauf que
lorganisation du fichier HTML de sortie de me plaît pas, et depuis
plus de deux ans jutilise un script rédigé en Dart et compilé vers
Javascript pour réorganiser les fichiers. En soit ce ne serait pas
trop grave si mes pages web nétaient pas forcément lourdes. Mais
elles le sont! La plus lourde page de mon site de linguistique fait
232Ko (la page francophone sur le Proto-Ñyqy) et celle de mon site de
configuration fait 5,5Mo (configuration Emacs)! Je parle bien de
fichiers HTML! Il faut vraiment que ça change!
*** Nouveau Framework pour le front-end
À la base je métais lancé pour écrire un exporteur personnalisé pour
exporter mes fichiers org-mode vers des fichiers JSX qui seraient
utilisés par un projet [[https://reactjs.org/][Reac]]t, ou même [[https://nextjs.org/][Next.js]]. Mais jai récemment
découvert quelque chose qui pourrait être bien plus pratique pour
moi: [[https://vuejs.org/][Vue]] et tout particulièrement [[https://v3.nuxtjs.org/][Nuxt]]!
En effet, Nuxt lit le [[https://content.nuxtjs.org/guide/writing/mdc/][MDC]], ou Markdown Components. De fait, il est
possible avec MDC et Nuxt dinsérer dans du Markdown des composants
Vue soit en blocs soit en inline. Et pour moi, ça change tout! Je
peux maintenant écrire un exporteur minimal qui se chargera simplement
dexporter quelques éléments personnalisés vers des composants Vue,
voire même de simples macros org-mode pour exporter les composants
inline.
Et bien sûr, pour pallier au problème de fichiers HTML trop lourds, il
me faudra séparer mes fichiers actuels en plusieurs fichiers, mais
cela devrait être plus simple à gérer une fois la transition vers le
nouveau framework effectuée.
*** Et pour le backend ?
Mais ce nest pas tout: un élément que jaimerais ajouter à mon site
de linguistique serait un dictionnaire entre mes langues construites
et dautres langues, quelles soient construites ou non. Ce
dictionnaire doit pouvoir être interactif, avec par exemple une
recherche, une page par mot, etc.
Je ne ferai certainement pas télécharger à mes utilisateurs
lentièreté du dictionnaire à chaque recherche dun mot dans le
dictionnaire, il ne peut donc pas être hébergé avec mon frontend, et
jaurai besoin dun backend avec une API REST pour gérer les requêtes
des visiteurs du site web. Maintenant la question est, quel type de
back-end ?
Tout dabord, je vais complexifier un peu le problème: je suis un
grand amateur de org-mode. Je pourrais gérer ça via une base de
données classique, ajoutant chaque entrée manuellement, mais je vais
plutôt essayer de gérer tout ça via org-mode. Les fichiers texte sont
plus simples à versionner que des bases de données en un seul fichier
binaire. Du coup, il va falloir que je mécrive un nouvel exporter,
mais lequel?
Je pourrais rédiger un exporteur pour mon fichier ~dictionnaire.org~ qui
lexporterait vers un fichier Json qui serait lu ensuite par mon
backend qui extraierait et enverrai à mes utilisateurs les
informations nécessaires. Lavantage serait de navoir quasiment pas
besoin de manipuler le Json et den envoyer tel quel. Mais louverture
et fermeture constante du fichier nest pas forcément la meilleure des
idées, quoi que cela pourrait permettre de remplacer le fichier
pendant que le backend tourne. Mais je suis sûr quon peut mieux
faire.
Ma solution suivante était dutiliser EmacSQL, un paquet Emacs lui
permettant dinteragir avec des bases de données SQLite, PostgreSQL et
MySQL. Au moins ce serait une véritable base de données, avec
seulement un blob binaire à mettre à jour, et ce serait
potentiellement plus performant étant donné quil ny aura quà ouvrir
une fois une connexion avec elle. Mais le problème est maintenant sa
mise à jour. Mince…
Vient enfin ma troisième solution qui, je pense, sera celle que je
vais adopter: utiliser une base de donnée type Firebase. Lidée dun
verrouillage fournisseur ne me plaît pas franchement, donc jai décidé
dutiliser une alternative open source et hébergeable: [[https://appwrite.io/][Appwrite]]! Je
peux écrire sur une de ses bases de données pendant que mes
utilisateurs peuvent la lire, donc la mise à jour nest pas un
problème, et je nai rien à mettre en ligne, seulement une série de
requêtes à faire. Cependant, un problème reste: comment communiquer
avec Appwrite?
*** La quête pour un SDK Appwrite pour Emacs
Hélas, jai beau chercher, il nexiste aucun paquet pour Emacs
permettant une communication avec Appwrite. Mais ce nest pas
franchement surprenant: Appwrite nest pas encore extrêmement
répandu, et même Firebase ne dispose pas de paquet pour Emacs.
Bien heureusement, Appwrite dispose dune API REST assez bien
documentée, et Emacs est capable de gérer des requêtes nativement via
sa bibliothèque ~url~, cest donc naturellement que jai commencé à
travailler sur ~appwrite.el~, un SDK Appwrite pour du Emacs Lisp.
Jaurais pu utiliser ~request.el~, un paquet assez populaire pour Emacs
afin de gérer les requêtes HTTP, mais je ne suis pas grand fan de son
workflow et je préfère limiter au maximum le nombre de dépendances
dans mes paquets. Ce que ce paquet fait actuellement est une
transformation des paramètres nommés que mes fonctions acceptent en un
payload Json. Par exemple, ma fonction ~appwrite-stogare-list-buckets~
accepte les mot-clefs ~search~, ~limit~, ~offset~, ~cursor~, ~cursor-direction~
et ~order-type~. Ces arguments sont transformés en du Json via la
bibliothèque native dEmacs afin de donner ceci:
#+begin_src js
{
"search": "my search request",
"limit": 30,
"offset": 0,
"cursor": "",
"cursorDirection": "before",
"orderType": "ASC",
}
#+end_src
Ce payload Json est enfin envoyé à lAPI REST correspondante, en
loccurrence ~/v1/storage/buckets~ comme on peut le voir [[https://appwrite.io/docs/server/storage?sdk=nodejs-default#storageListBuckets][sur la
documentation officielle]]. Bien sûr, les éléments optionels ne sont
pas nécessairement inclus afin déviter à avoir à envoyer trop
dinformations. Dans ce cas, tous les éléments du payload sont
optionels, ce qui ferait que le ~appwrite.el~ nenverra que src_js{{}}
comme payload à lAPI.
Pour linstant, le projet en est encore à ses débuts, mais jai
commencé à travailler sur le SDK pour Appwrite que vous pouvez trouver
sur [[https://github.com/Phundrak/appwrite.el][ce dépôt Github]].
La question maintenant est: comment exporter mon dictionnaire vers
Appwrite? La réponse me semble relativement simple; je pourrai
écrire un exporteur org-mode dépendant de ~appwrite.el~ qui exportera
pour chaque mot quil rencontrera un payload Json vers mon instance
personnelle Appwrite. Et à la différence des exporteurs org-mode
habituels, ~ox-appwrite~ nexportera aucun fichier sur mon système.
*** Conclusions
Au fur et à mesure de mon analyse du projet et de mes besoins, je me
suis rendu compte que jaurai besoin doutils plus intelligents que de
simples pages HTML exportées automatiquement via Emacs.
Ainsi, jaurai besoin de créer un site web avec Nuxt, profitant ainsi
de sa capacité à rendre du Markdown avec du contenu interactif,
agissant en tant que frontend pour mon site web. Ce Markdown sera
exporté via org-mode à partir de mes fichiers déjà existants, bien
quà fragmenter afin de réduire la taille des fichiers de sortie.
Le backend sera une instance Appwrite que jhébergerai moi-même sur
mes serveurs. Elle sera populée par un exporter org-mode custom via
Emacs, ce qui me permettra de continuer à gérer mes dictionnaires et
mes langues avec org-mode.
Ce projet est vraiment intéressant car cela ma incité à explorer de
nombreuses possibilités et technologies différentes afin de trouver ce
qui correspond le mieux à mon besoin, notamment en me rendant compte
par exemple que React nétait pas forcément loutil le plus adapté à
ce projet précisément. Cela me fera également travailler sur ma
capacité à interagir avec des backends et des API REST, tout autant du
côté front-end pour le site web que du côté SDK avec Emacs. Enfin, la
création de ce SDK ainsi que des exporteurs org-mode me sera bénéfique
afin dapprofondir ma connaissance dEmacs et du Emacs Lisp.
Maintenant, au travail!
** [EN] Writing a Dynamic Array in C :dev:C:
:PROPERTIES:
:EXPORT_FILE_NAME: writing-dynamic-vector-c