Bienvenue sur Double Slash, le podcast dédié aux Jutis et aux techniques pour le développement web.
Bonjour à tous et bienvenue sur ce nouvel épisode de Double Slash.
Donc je suis Patrick et nous sommes avec Alex comme d'habitude.
Salut Alex !
Salut Patrick, salut à tous !
Je vous souhaite à tous auditeurs une bonne année et merveilleux pour 2022,
puisque c'est le premier épisode de 2022.
Bonne année Alex !
Yes, merveilleux à toi et à tous aussi.
C'est quoi l'épisode ? C'est l'épisode 32, c'est ça ?
Ouais, 32, c'est cool.
Je reviens trop bien.
Et donc, si vous cherchez une bonne résolution pour 2022, j'en ai une pour vous.
Vous allez sur Apple Podcasts ou Spotify puisque Spotify maintenant prend les commentaires et les notes
et puis va vous poser une petite note sur le podcast.
Ça va permettre à d'autres personnes qui sont intéressées par le dev de trouver le podcast et de l'écouter.
Donc ça serait cool pour eux.
Donc faites un petit geste pour les autres auditeurs.
Et on remercie également notre sponsor de l'épisode Indie.
Donc Indie Service en ligne qui vous aide à faire votre comptabilité pour votre société,
qui remplace le comptable avec un tarif très avantageux.
Et pour 2022, ils ont sorti un nouveau service qui vous permet en fait,
c'est un accompagnement pour la création d'entreprises.
Donc voilà, souvent, les gens qui créent des entreprises,
c'est jamais évident, on ne sait pas trop quoi faire, comment ça marche, quel statut choisir.
Donc ils ont écouté bien un nouveau service qui est totalement gratuit.
Donc pour la création d'entreprises, pour vous aider en tant que futur indépendant
ou futur société à créer votre société.
Donc vous avez un rendez-vous téléphonique, simulation pour choisir le statut jurulique
puisque le statut jurulique c'est la question qui revient tout le temps
quand on doit créer une société.
Pour rappel, il n'y a pas le statut idéal, il y a juste un statut qui correspond à votre société.
Voilà, SRL, Sazu et compagnie.
Il y a un accompagnement pour l'immatriculation de la société,
la prise en charge des rédactions des statuts, des pots de capital.
Et je le répète, le service est totalement gratuit.
Bon, il y a un euro symbolique.
Ah, c'est ce que j'ai dit.
Je crois qu'il y a un euro symbolique.
Donc voilà, un euro pour le prix d'une baguette.
Donc c'est vraiment intéressant.
Je... quand même vous aurez les trucs à payer comme le dépôt, greffe, tout ça,
qui sont plutôt pour l'état, c'est pas Indy qui fait payer ça.
Donc il y aura quand même des choses à payer.
Mais le service, l'accompagnement de Indy est totalement gratuit.
Et je rappelle, donc on a un code aussi promo qui vous permet d'avoir 2 mois gratuits sur le...
Double dev.
Voilà, double dev.
Il est sur les notes de l'épisode.
Il y a un petit lien qui vous permet d'accéder directement.
Et voilà, ça vous permet d'avoir 2 mois gratuits sur le service classique d'Indy.
Donc profitez-en.
Pour la comptabilité.
Ouais.
Pour la compta, ça vous aide vraiment.
Alex l'utilise et ça lui fait gagner du temps au quotidien.
Ouais, il est clairement...
Moi, je suis pas fan de la compta.
Du coup, si ça peut se faire...
Qui est fan de la compta?
Par comptable.
Peut-être.
Bon, voilà.
Un grand merci, Indy, pour sponsoriser...
Ces épisodes-là.
Ouais.
Et donc, Alex, aujourd'hui, on parle de quoi?
Je crois qu'on parle d'Asura, c'est ça?
C'est exactement ça.
C'est Asura avec...

Asura.
Alors c'est pas...
C'est japonais, là-bas, ou...
Non, c'est pas espagnol.
Je crois que, initialement, les fondateurs et les premiers mecs qui ont mis des comites sont Indiens.
Il y a une grosse communauté indienne derrière Asura.
Ouais.
Et je sais pas exactement si ça se prononce Asura, Asura, Asura, Asura.
Je sais pas.
On dira Asura et ça s'agira bien.
Ça s'agira bien.
C'est clair.
Donc, clairement, moi, je vais être honnête.
Je connais pas le service.
Enfin, j'ai été deux fois sur le site, mais bon, j'en sais rien.
Je sais pas du tout comment ça marche et je sais pas quoi ça sert.
Donc, toi, tu le connais bien.
Donc, tu vas nous expliquer à tous et à moi comment...
À quoi ça sert, en fait.
Et on t'écoute.
Oui, carrément.
En fait, Asura, on va dire que c'est...
Alors, le terme exact, c'est un GraphQL Engine.
Ok, d'accord.
Qu'est-ce que c'est?
En fait, c'est un service qui va permettre de générer une API crude automatiquement basée
sur la DB et la structure de DB qu'on lui a donnée.
En clair, je prends la connexion à ma DB, je viens mettre ma connexion dans Asura et
lui, il va automatiquement générer une API GraphQL pour moi.
Donc, il vient créer toutes les queries, toutes les mutations et même les souscriptions.
Alors, pour ceux qui ne sont pas trop familiarisés avec GraphQL, on vous renvoie vers l'épisode
où on parle justement de GraphQL.
Mais en clair, si on résume très, très rapidement, c'est le client qui va demander les ressources
qu'il a besoin.
Ok, tu me donnes les postes avec les ID, le titre de le title et le contente avec l'auteur
et le nom de l'auteur.
Donc, le client, il va demander.
Ces informations, elles rentrent dans un résolveur et c'est ce résolveur qui va aller chercher
les informations dans la DB.
Donc, en fait, la première grosse partie de Asura, c'est d'être un ORM, vraiment Object
Relations Manager, où là, en fait, il va requêter la base de données pour nous.
Et le deuxième gros morceau, c'est justement qui va générer automatiquement tous ces résolveurs
pour nous.
Donc, ça, c'est assez puissant parce qu'en fait, on a juste à...
J'ai horreur de dire juste.
C'est le client qui dit juste.
Oh, tu as juste à faire ça.
Oui, oui, non, mais tu as deux clics.
Mais pour toi, c'est simple.
Non, non.
Donc, en fait, il faut vraiment comprendre que cette DB, elle va être exposée directement
à notre API.
Et en fait, quand on se pose souvent la...
Enfin, quand on regarde notre métier, on fait souvent tout le temps la même chose en
terme de crud.
Voilà, on va créer Read, Update, Delete sur des ressources.
Et on va dire que c'est un petit peu chiant de faire tout le temps les mêmes choses.
Et surtout, ça amène très peu de valeur parce que, en fait, notre application, elle
a une business logic qui lui est spécifique, qui là, en fait, est vraiment le coeur de
métier de l'application.
Mais on va dire faire des crud 1, 2, 3, 4, une fois qu'on en a fait 4.
Bon, clairement, c'est un cinquième, un sixième.
Ça amène peu de valeur ajoutée.
Et puis, ce n'est pas très, très intéressant et c'est vite chiant.
Donc là, en fait, l'idée, c'est de sous-traiter cette tâche-là à Soura qui, lui en plus,
va le faire sans doute beaucoup mieux que nous parce qu'il y a plein de gens qui ont
travaillé sur le projet qui vont faire de la métaprogrammation.
Donc ça, c'est complètement accessible avec GraphQL.
On va analyser, on va créer les résolvers, on va créer toutes les interfaces, tous les
types, ce qui nous permet, en fait, d'avoir notre documentation qui se fait automatiquement.
Mais ça, c'est propre à GraphQL.
Et en fait, on va vraiment optimiser toutes les recherches.
Et un problème courant qu'on va avoir aussi sur GraphQL, c'est le problème de N plus 1.
Vu que le client peut appeler autant de ressources qu'il veut et aussi toutes les ressources peuvent être
nestées à l'intérieur des unes des autres, en termes de performance SQL, ça va être compliqué
parce qu'on va avoir des joins dans tous les sens.
Et donc si ces query-là ne sont pas optimisés, clairement, ça va être lent.
Et Asura, lui, en fait, il vient analyser la query, il vient analyser l'ADB et il vient vraiment optimiser
de manière inodore un color pour des devs comme moi, en tout cas, qui en SQL ne sont pas des grosses machines
du tout. Et donc, Asura me permet d'avoir des queries qui sont optimisées, malgré le fait que je fasse du nest
Mais il y a une limite de profondeur ?
En fait, on peut déterminer la limite de profondeur qu'on donne accès, parce que sinon, on est dans une boucle infinie
et là, c'est vachement plus compliqué.
Je peux donner un exemple, j'ai un exemple rapide pour ces boucles infinies.
En général, il ne faut pas le faire, parce que tu fais tomber ton serveur.
Imaginons, tu as un poste, avec des postes liés à ce poste, donc tu vas chercher ces postes liés à ce poste,
mais dans ces postes qui sont liés, tu peux aussi chercher les autres postes liés à ces postes individuels, et ainsi de suite, et ainsi de suite, et ainsi de suite, et ainsi de suite,
et là, tu arrives à une boucle infinie, comme tu lis, et là, le truc, il explose en fait. Déjà, il ne répond jamais.
Et puis, tu as une boucle qui va être super longue, et ta requête va être très, très, très, très longue.
Donc oui, tu peux déterminer dans Asura le niveau de profondeur que tu donnes accès, clairement.
Donc en fait, vraiment, ce qu'il faut comprendre, les deux grosses parties de Asura, c'est un ORM, qui va appeler la base de données,
et qui va créer un serveur avec une génération de crues automatiques.
Ok, donc je connecte une base de données. C'est ta base à toi, c'est pas Asura qui gère la base de données ?
C'est ma base. Il y a différentes database qui sont accessibles. Il y a du PostgreSQL, il y a du SQL Server Microsoft,
il y a du Amazon Aurora, qui est l'équivalent de Postgre chez Amazon, et il y a du Google BigQuery.
Ça, c'est des DB qui sont implémentés, qui marchent là aujourd'hui, à l'heure où on enregistre.
Et ils ont pour projet de rajouter des bases Oracle, des MongoDB, MySQL et Elastic.
Ok. Ça, c'est la roadmap. Après, je ne sais pas du tout quand est-ce que ça va sortir.
Mais en tout cas, c'est...
Il y a déjà pas mal, tu as déjà de quoi faire.
Oui, oui, carrément.
Et puis, comment ça se passe ? Donc je rentre les informations de ma DB, qui est distante, je suis Amazon, n'importe.
Et là, je clique un bouton générait, un truc comme ça, et il va m'oliner, il va me générer tout les trucs.
Alors, le terme...
C'est instantané ou...
Absolument. Le terme, en fait, c'est sur Asura, ça s'appelle Track, en clair.
Il vient analyser ta base de données. Il dit, ok, tu as une table avec tel champ.
Et ce que tu veux que je track cette table là, et que je génère l'API total pour cette table, Track terminée.
Et là, ça vient automatiquement créer les queries, les mutations et même les souscriptions, donc les mises à jour automatique via WebSocket.
Donc ça, c'est assez pratique et assez puissant.
Par contre, je vais pouvoir aussi rajouter un champ, modifier un champ, et lui, il va automatiquement régénérer mon API basé sur les dernières infos que...
Il est capable de détecter, c'est par exemple dans ta base MySQL, tu vas rajouter une table avec... voilà, n'importe.
Lui, automatiquement, il va te dire, ah tiens, il y a une nouvelle table, est-ce que tu veux que je track cette nouvelle table ? Automatiquement ?
Oui, il le fait. Donc soit, en fait, on va le faire depuis Asura, et c'est mieux, en fait.
Soit on va le faire depuis notre client de DB. Mais en fait, si on le fait depuis Asura, lui, il va automatiquement le tracker.
On peut lui dire de ne pas tracker si on veut, mais il va automatiquement faire toute la surcouche qu'amène Asura, il va le faire automatiquement.
Donc il est préférable, en fait, de faire toutes les migrations et toutes les modifications de DB, de les faire directement depuis Asura.
Et ça, en fait, on a deux possibilités de le faire. Soit on le fait depuis l'interface graphique, qui est clique, clique, clique, clique.
Soit on peut le faire via des fichiers yaml, qui sont... Alors au début, ça pique un peu les yeux, les fichiers yaml.
Mais après, en fait, on comprend que c'est assez puissant. Et ce qui va nous permettre de versionner notre GraphQL Engine.
En fait, on va pouvoir le versionner, on va pouvoir le partager. Si on a plusieurs devs à travailler sur le projet,
on va travailler en équipe dessus. Donc on va pouvoir le versionner avec les branches et tout ça.
Et donc là, c'est assez intéressant parce qu'on va pouvoir, à via une CLI, lancer les migrations, appliquer les migrations, créer une migration et tout ça.
Donc en fait, ce qu'il faut comprendre, c'est que quand on a fait le choix de faire avec notre interface graphique,
malgré le fait qu'on soit dans une interface graphique, ça va enregistrer toutes nos modifications et ça va créer des fichiers SQL Up, des Down,
des fichiers de migration, on va dire, classiques, ce qui va nous permettre d'avoir tout un historique de des migrations, de DB quoi.
En fait, t'as tout qui est en fichiers statiques. Donc il fait des tracks de la base. Est-ce que ça marche dans l'autre sens ?
Est-ce que par exemple, parce qu'en fait, toute la base de données, elle est contenue dans des fichiers YAML en gros ?

Donc tu peux éventuellement générer une base de données en connectant une SQL VID. Est-ce que tu peux générer ou pas ?
Alors ?
Alors en fait, c'est une surcouche. En fait, Asura, le GraphQL Engine, c'est une surcouche.
C'est-à-dire que vu que tu as lancé et tu as écrit toutes tes migrations, tu vas lancer tes migrations SQL classiques et donc ça va te monter la table,
créer les relations et tout ça. Et après, en fait, tu vas avoir ce qu'on appelle les métadata de spécifiques à Asura
qui lui, en fait, va venir générer et créer toutes les connexions GraphQL pour la pays. Et donc du coup, ça, c'est un autre fichier.
Mais en fait, tu as vraiment deux mondes, quoi. Tu as le monde de l'ADB et tu as le monde de Asura avec toutes les métadata,
en clair, toute la connexion GraphQL, les autorisations, les actions, les events, qui sont des choses qu'on va parler maintenant.
Mais en clair, toute la configuration de Asura, elle peut être exportée, importée, exportée via l'interface.
Ok. C'est pas mal. Et donc c'est Open Source, tu l'éberges. Donc soit c'est ébergé en ligne, via un core, j'imagine.
Exactement. Deux possibilités. C'est un projet qui est totalement Open Source. Donc il y a le repo GitHub.
Sur le repo GitHub, il faudrait qu'ils sont à 25 000 stars. Donc c'est un projet qui est déjà un peu sérieux, on va dire.
Il y a une grosse, grosse communauté derrière. Il y a beaucoup, beaucoup de documentation, beaucoup de vidéos, beaucoup de ressources.
Pour justement comprendre le fonctionnement de Asura, la doc est super bien faite.
De toute façon, comme tout projet, la doc est clé.
Ils ont vraiment tout un step downboarding qui marche vraiment bien.
Et soit on vient auto-éberger ce GraphQL Engine, à savoir qu'au départ, ils préconisaient de le mettre sur une petite instance des recours à 5 balles par mois.
Ça suffisait largement. Avec Qedal de mémoire vive, on avait 50 000 requêtes qui passaient sans problème.
50 000 requêtes à la seconde. Donc ils étaient plutôt... c'était un peu...
Ouais, ouais, c'était super lite. Et en fait, ce qu'il faut comprendre, c'est écrit en Askel.
Nous en fait, en tant que dev, on n'a rien à voir. On ne va pas du tout jouer avec ça.
Donc c'est inaudible.
Faire le perso à ce qu'elle...
C'est trop, trop spécifique.
Donc en fait, on va prendre... il y a différentes images.
Donc des dockers ou des cubes sur des pods et tout ça.
On va pouvoir soit le déployer sur notre serveur à nous, soit on peut utiliser une version Cloud.
Maintenant, en fait, comme beaucoup de projets, en fait, Open Source, ils ont sorti une version Cloud avec du support et de...
tout est auto-éberger.
Et là, pour le coup, pour tester, ils ont une version gratuite qui nous permet en trois clics d'avoir un Asura en place.
Et c'est parti quoi. Donc pour faire des tests, je pense qu'il n'y a pas mieux que la version gratuite et Cloud.
Après, en fait, si vous voulez optimiser, avoir plus de...
voilà, si vous voulez contrôler votre machine, et bien là, vous pouvez le mettre sur un docker ou qui importe.
Et sur votre serveur...
Ce n'est pas envie de mettre la main dans les serveurs, c'est pas mal aussi de payer.
Exactement.
Il faut pas mal de société, ce n'est pas un problème de payer 30 ou 40 ou 50 euros par mois.
Et puis voilà.
Exactement. Après, en fait, c'est à quel stade de maturité de la boîte est, et c'est quand même à la ressource en interne
pour gérer un serveur, pour le maintenir, tout ça, où là, je mets la carte bleue et je ne me fais pas chier.
Je sais que, en cas de support, j'appelle le support et c'est eux qui vont gérer ça beaucoup mieux et plus rapidement que moi.
Donc après, c'est à quel stade de maturité d'entreprise et de projet est, soit je mets la carte bleue, soit je fais tout à la mano,
avec les tenants et les aboutissants.
Mais en tout cas, ça reste open source et il y a une possibilité de l'auto héberger ou de support cloud.
Ok.
Donc, ça, c'est plutôt bien.
Par contre, il y a encore une dimension qui manque, c'est que, ok, un crude, c'est bien, mais mon application métier, elle a des requêtes un peu spécifiques.
On va dire le truc classique, c'est quand j'ai un utilisateur qui s'inscrit, je veux lui envoyer un mail.
Ça, en fait, c'est une business logic spécifique à mon appli.
Bon, elle est plus que basique, mais clairement, à Soura, ça ne va pas envoyer un email, il ne sait pas faire.
Et donc, en fait, il y a tout un système qui s'appelle des events ou des actions, qui va nous permettre de faire de la business logic derrière à Soura.
En clair, ça va, c'est comme si on mettait un trigger, quand il y a une insertion ou une update ou un delete de la table, de tel champ,
eh ben, tu vas envoyer ces informations sur tel endpoint.
Et là, en fait, on va pouvoir faire notre business logic.
En clair, toute la partie, toute crude automatique, ça va être le GraphQL Engine qui va le faire, et toute la partie business logic,
ça va être soit un petit serveur, soit des fonctions serverlesses qui vont être automatiques.
Donc, et en fait, on va avoir notre business logic qui va vraiment être détaché du GraphQL Engine.
Et donc, il y a des webbooks, et on envoie les informations webbooks.
Le webbook, la fonction à ce service, elle va exécuter ce qu'elle a besoin de faire et est terminée.
Donc, deux possibilités, c'est les events.
Donc, les events, c'est, on va dire que c'est un trigger qui est interne à la database.
En clair, la création d'une nouvelle ligne, la modification, j'ai besoin de refaire un calcul,
j'ai besoin d'exécuter quelque chose.
C'est un event.
A tel événement, je vais envoyer à tel endpoint.
Et j'ai ma fonction à ce service qui va faire le job.
Ça, c'est la première possibilité.
Une deuxième possibilité, c'est de faire des actions.
Par exemple, je veux que mon client, il puisse calculer ou, on va dire calculer quelque chose.
Sauf que ce calcul, c'est pas dans la database.
Donc, c'est pas Asura qui peut le faire.
Donc, c'est qu'un serveur externe qui peut le faire, ma fonction à ce service pour le coup.
Et bien, en fait, là, on va utiliser des actions.
Et donc, les actions, ça va passer directement depuis le client.
Donc, la requête, la mutation en fait, exécutée en GraphQL chez le client qui va à Asura.
Asura va à la fonction à ce service, renvoie l'info à Asura.
Asura renvoie l'info au client.
Alors, au départ, on dit, c'est un peu over engineering, tout.
Et tu dis, ouais, mais en fait, c'est vachement simple et vachement plus facile en termes de sécurité et en termes d'installation.
Parce que le seul point d'entrée, c'est Asura.
Et là, en fait, on vient rajouter une autre dimension à Asura qui devient en fait l'API Gateway.
En clair, c'est la seule source tout pointe vers Asura.
Et c'est Asura qui va faire le chef d'orchestre.
Qui est dit, OK, ça, c'est de la DB.
Hop, je vais demander la DB.
Ça, c'est de la custom logic.
Je vais sur Tell Endpoint et je récupère.
Et donc, en termes de paramétrage, ça va être vachement plus simple parce que mon client,
mon client, il va avoir que un seul endpoint qui va être Asura.
Et Asura va gérer tout le reste.
Et comme c'est un API Gateway, en fait, je vais pouvoir brancher bienvenue dans le monde du GraphQL
où je vais pouvoir brancher en fait un autre serveur GraphQL que je vais brancher sur Asura.
Quoi ? Quoi ?
Inception.
Inception.
Inception.
Un exemple typique, j'ai un serveur GraphQL de mon... à droite, par exemple.
Et je vais le mettre sur mon client.
Et bien, je vais prendre mon serveur GraphQL que j'ai fait à mon custom.
Je vais le brancher à Asura.
Et en fait, depuis Asura, je pourrais appeler mon autre serveur.
Ce qui fait que mon client, lui, il n'a qu'un seul point d'entrée.
Et c'est vraiment ce concept de API Gateway qui est super intéressant.
Oui, il joue un rôle de proxy avec d'autres serveurs.
Et je vais pouvoir faire la même chose avec du reste.
Si j'ai un API resté, et bien en fait, ok, je vais me taper tout le mapping.
Mais en fait, je vais pouvoir avoir qu'un seul endpoint, mon GraphQL qui va...
Ok, ça, c'est Stripe, ça, c'est GitHub, ça, c'est mon custom server, ça, c'est ma DB.
J'ai qu'un seul point d'entrée à Asura.
Ah voilà, tu peux appeler Stripe et tout, c'est vrai, exactement.
Et donc, du coup, ça, c'est super, super puissant.
Oui, c'est vrai.
C'est pas vrai.
Et oui, ça, c'est super, super puissant.
Donc, soit il fait rôle de...
Avec les actions, c'est proxy, donc il va appeler différents services en dehors de la base de données.
Il peut aussi faire des transformations avant d'insérer en base de données, c'est ça ?
C'est ça. En fait, je dois retraiter de la donnée avant de l'enregistrer dans la DB.
Et bien, elle passe par ma fonction As-de-Service, elle revient à Asura avec les nouvelles données
et ces données-là sont injectées dans la DB, ou sont calculées à la volée et sont renvoyées au client.
Donc ça, ça va dépendre, mais les deux sont possibles, clairement.
C'est top.
Oui, c'est top. Et puis l'exemple que tu donnes d'appeler Stripe, par exemple, c'est génial,
parce que tu peux appeler directement Stripe via ton API, sans appeler directement Stripe, c'est excellent.
Et puis, ce qui est intéressant, déjà, c'est que tu viens diminuer le nombre de clients,
enfin, de services ou de serveurs que tu viens connecter à ton client front,
donc ton client front, il a que Asura et il conne que avec Asura.
Et après, c'est Asura qui va faire le chef d'orchestre, sauf que tous ces services-là,
en fait, c'est micro-service à micro-service.
Donc tu vas pouvoir sécuriser les données avec des variables, des tokens, tout ce que tu veux, des corps,
mais tu ne vas pas exposer cinq serveurs sur ton client front.
Et donc ça, c'est vachement mer en termes de sécurité aussi,
parce que c'est toi qui fais ta sauce dans ta bulle, et donc c'est toi qui gère ta sécurité.
Et tu exposes moins, donc si tu exposes moins, toujours c'est toujours mieux.
Excellent, excellent.
Alors, tout se fait par fichier Yamel, toujours, même quand tu fais ces choses-là,
enfin, par l'interface aussi.
Absolument, en fait, je suis dit que c'est ta deux possibilités.
Soit tu veux tout faire en fichier Yamel, parce que tu es un pur et dur.
Ce quoi, en fait, avec Viana,
avec soit via l'interface graphique, et de toute façon, en fait,
l'interface graphique va générer automatiquement tous ces fichiers Yamel à côté.
Donc, en fait, c'est comme tu veux, si tu veux le faire en Yamel direct,
fais le Yamel, après il faudra juste appliquer ces nouvelles fonctionnalités.
Mais l'interface graphique se fait plutôt bien, et c'est vrai qu'au départ,
c'est plutôt aidant de comprendre l'interface graphique.
Après, une fois qu'on a trouvé les paternes,
clairement, je pense qu'on peut aller plus vite sur du Yamel,
mais c'est comme tout, en fait, au départ, on fait l'interface graphique,
et puis à la fin, on y va directement au fichier Yamel, parce qu'on est plus rapide,
parce qu'on connaît tous les paternes, le fonctionnement.
Donc, oui, oui, c'est vraiment...
Et tous ces fichiers-là, en fait, ils sont versionnés,
et ils sont externes à l'instance, en fait, de Asura.
C'est vraiment des fichiers de configuration.
Donc, ces fichiers de configuration, tu peux les exporter, les sauvegarder, les partager,
les versionner, les sur GitHub, et tout ça.
Oui, c'est top, top, top. En plus, j'imagine, c'est quand même assez flexible,
donc tu peux rajouter facilement, créer un micro-service pour envoyer un email ou que ce soit,
et puis tu rajoutes la ligne dans le fichier Yamel, via l'interface, et puis hop, c'est parti.
En fait, tu peux rajouter des trucs facilement.
C'est assez facile, c'est assez fluide.
Alors, oui, la première fois qu'on le fait, c'est un peu compliqué,
parce qu'il faut créer, en fait, des interfaces.
Non, oui, des types avec des mutations qui sont spécifiques.
Au départ, c'est un peu complexe, mais une fois qu'on a trouvé le pattern,
ça marche vraiment bien, c'est vraiment efficace.
Et pour le coup, une fois de plus, la doc est vraiment super bien faite.
Il est important.
Par contre, il y a un autre point qu'on n'a pas encore abordé, c'est tout ce qui est autorisation.
Autantification.
Donc, Asura en lui-même ne gère pas l'authentification.
C'est-à-dire, lui, c'est pas lui qui va générer le token JWT.
Par contre, on va pouvoir connecter n'importe quel service qui gère ça très bien,
Firebase, Octa ou AudeZero.
Ils ont des connexions directes, où en fait, on va passer par un provider d'authentification.
Il va nous générer le token, le JWT, et ce JWT va être interprété par Asura.
Ce qui va nous permettre à l'intérieur d'Asura de mettre des systèmes d'autorisation
avec des rôles qu'on vient déterminer.
Et on a un niveau de granéalité hyper poussé pour chaque modèle, pour chaque ligne,
pour chaque champ et pour chaque type de rôle qu'on a affecté.
On va pouvoir donner les autorisations.
J'autorise, j'autorise pas.
J'autorise si l'utilisateur qui fait la requête est le propriétaire de ce poste,
alors il a le droit de modifier et ainsi de suite.
Donc en fait, on va pouvoir gérer toute l'autorisation à l'intérieur de Asura
et à l'intérieur de la table directement.
Donc en clair, on va avoir toutes nos tables de DB.
On va pouvoir explorer la DB.
Ça, c'est un client classique.
On va avoir un autre onglet qui va être la création, la modification de champ.
Et on va avoir un onglet spécifique sur l'autorisation,
où en fait, on va venir déclarer qui a le droit, qui n'a pas le droit, qu'est-ce qu'il peut faire.
Et on a un autre onglet aussi qui sont toutes les connexions
et les relations entre les tables
pour pouvoir justement appeler toutes les relations via GraphQL.
Donc en fait, c'est tout un écosystème qui est à la fois hyper ouvert
parce qu'on va pouvoir brancher n'importe quel système de JWT.
On a notre système de JWT homemade.
On peut le mettre et Asura va pouvoir le décoder.
Ce qui est super intéressant, c'est que à chaque requête qui va rentrer,
lui, il va décoder le JWT et baser sur ses infos,
il donne accès ou pas selon les règles qu'on a écrites.
Mais par contre, comme je le dis, lui, il ne le gère pas à la base.
Ça veut dire que quand tu l'installes au début, c'est tout open.
Absolument.
C'est un truc à savoir quand tu commences à prendre.
Exactement.
C'est au départ, c'est open bar.
C'est-à-dire le schéma de DB devient l'API ouverte.
Il faut faire des mutations.
Exactement.
C'est un truc à savoir.
Il faut bien déterminer en mode,
est-ce que je demande à cette personne d'être authentifiée
et peut-être aussi, nous, dans notre base de données,
on va pouvoir mettre des champs qu'on ne veut pas exposer
sur notre API GraphQL.
Parce qu'il faut bien différencier l'ADB et le schéma GraphQL.
Et par défaut, vu qu'à Soura, il ne sait pas,
lui, il fait égal.
C'est-à-dire, schéma DB est égal, schéma GraphQL.
Il prend trop.
Nous, si on veut stocker des données qu'on ne veut pas exposer,
c'est à nous de dire, ok, ça, tu ne l'exposes pas,
ça, tu l'exposes, ça, tu l'exposes que si lui,
il est admis ou support et ainsi de suite.
Mais en fait, on a un niveau de granularité,
mais c'est vrai que tu fais bien de préciser
qu'au départ, c'est open bar.
C'est le mec qui met ça, son petit serveur et tout.
C'est bon, ça marche.
Oui, oui.
Donc en fait, c'est vraiment approche.
Oui, ils auraient pu faire l'inverse, en fait.
Oui, après.
Ils auraient pu fermer tout d'origine.
Et après, c'est toi qui ouvre.
Blacklist ouvrir.
Blacklist.
Oui, après, c'est deux approches.
Est-ce que tu autorises tout et tu bloques
ce que tu n'as pas le droit, soit tu bloques.
Voilà, c'est toujours les approches.
Ils ont fait un choix.
Et ça veut dire que...
Oui, pardon.
Ça veut dire que tes autorisations, tes droits,
c'est toi qui décide en fait de l'intituler,
du label de...
Absolument.
User create.
Enfin, tu fais ce que tu veux.
Oui.
C'est dans le token et lui, il va voir si ça correspond
et puis il donne le droit ou pas.
Et en fait, tu vas avoir des claims,
sur CJWT, qui vont correspondre au rôle
que toi, tu as déterminé dans Asura.
Donc si toi, ton rôle, tu choisis qui s'appelle
manager et le manager, il a le droit de faire ça, ça, ça, ça.
Je ne sais pas, un customer,
il a le droit de faire ça, ça, ça, ça.
Et bien, si dans le JWT, il y a customer,
alors il va appliquer cette règle.
Si il est manager, il va appliquer cette règle.
Donc en fait, tu as un niveau de granularité
sur les autorisations qui est hyper poussé
et qui est assez intuitif, qui passe...
Voilà, c'est comme tout.
Il faut se ponger dedans.
Mais clairement, c'est vraiment,
c'est vraiment très, très, très puissant.
Ça me semble plutôt pas mal comme système.
Enfin, en tout cas, tu te l'envie.
Oui, mais clairement, après, tu vois,
moi, j'ai passé, ça fait déjà plusieurs...
Maintenant, ça fait plusieurs années que j'utilise.
Au départ, je jouais avec en mode facile.
Après, je suis passé sur un petit projet pour un client,
mais vraiment, je crois qu'il y a 2 ou 3 modèles.
Enfin, c'est vraiment hyper light.
Et pour le coup, là, sur le dernier projet que j'ai passé,
que j'ai bossé dessus,
là, on est passé en prod dessus
et on utilise tout à sourire.
Et clairement, on a gagné vraiment, vraiment du temps
sur la rapidité de mise en place de cet API.
Et en plus, moi, je reste intimement convaincu
que des gens qui ont passé plus de temps
à créer de la métaprogrammation,
ils vont faire quelque chose...
Il sera le plus au mieux de temps, en fait.
C'est clairement, il n'y a pas de photo.
Tant qu'à une communauté, des mecs qui travaillent dessus,
ils sont plusieurs, mais toi, tu es tout seul.
Donc, forcément...
Donc, ça sera un plus long.
Donc, le client, il va payer plus cher.
Et à la fin, le produit, il sera moins bien.
Et puis, il sera difficile à maintenir,
il sera difficile à faire évoluer.
Exactement.
Et puis, objectivement, après, il y a aussi...
Enfin, on reprend un tout petit peu de hauteur.
Mais clairement, le cru de...
C'est chiant, quoi.
C'est un peu chiant, quoi.
Il n'y a aucune intéressante.
Et donc, en fait, le combo Asura et Serverless,
c'est magique, quoi.
C'est super magique,
parce qu'en fait, on vient...
toute la business logique, elle est faite en Serverless.
Et toute la partie, on va dire,
nana, recrude, tout,
elle est générée directement par Asura.
Ok, excellent.
Allez, deux dernières questions.
Toi, tu me dis que tu l'utilises plusieurs années.
D'habitude, tu l'éberges comment, toi, généralement ?
Enfin, même sur le dernier projet,
où vous n'êtes pas sur le progrès ?
Alors, sur le dernier projet,
le client a fait le choix de passer sur Azure.
Donc, du coup, il est ébargé sur Azure.
Par contre, sur mon petit projet avec mon client,
là, je suis passé directement sur la version clave.
Et en fait, comme il y a très peu de...
il est très peu demandé, la version tiers suffit.
Donc, j'ai mis une DB gratos sur Heroku,
et Asura et des fonctions sur Netlify terminées.
Et ça fonctionne ?
Et ça arrive.
Et ça fonctionne.
Après, que les choses soient claires,
c'est un petit projet avec peu de volumétrie.
Donc, ça passe largement.
Et au pire des cas,
je pense que le client serait content
de sortir la carte bleue pour payer,
parce que ça veut dire qu'il y a beaucoup de demandes
et qu'il y a beaucoup de business.
Mais en tout cas,
il y a largement possibilité d'utiliser
ce service-là à moindre coût.
Ouais, après, tu peux toujours commencer comme ça,
et puis après, tu migres sur un truc plus important.
Exactement.
Puisque tout est versionné,
c'est facile de migrer après.
Ouais, exactement.
Et moi, je voudrais quand même parler,
parce que là, on parle de Asura.
Il y a un autre service qui existe,
mais qui s'est mis en surcouche de Asura,
qui s'appelle N-Ost.
C'est une boîte suédoise,
qui en fait,
vient gérer et intégrer l'authentification.
Le storage.
D'accord.
Les fonctions à l'intérieur.
D'accord.
Et donc, en fait,
il utilise Asura comme crude,
et il vient créer tout l'écosystème autour,
qu'il faut rajouter,
parce que l'écosystème autour,
on l'a dit, c'est l'authentification.
Elle n'existe pas,
donc il faut utiliser un service tiers.
Si on veut gérer du stockage,
il faut qu'on crée nous-mêmes
notre SOI S3,
soit un système pour héberger des fichiers.
Et toutes ces fonctions-là,
il faut qu'on les mette
sur un serveur de service l'Es,
donc Netlify, et machin.
Et donc, ce qu'ils ont fait,
chez N-Ost,
ils ont pris Asura,
et ils ont remis une surcouche tout autour
pour créer tout un écosystème.
Et là, pour le coup,
ça tue le match,
parce que...
Oui, ils sont venus combler les manques d'Asura.
Exactement.
Après, ce qu'il faut voir,
c'est qu'Asura, c'est vraiment,
si on résume,
c'est un ORM,
un API Gateway,
et un générateur de crudes.
Donc, clairement, c'est ça.
Et si on veut rajouter d'autres fonctionnalités,
on va rajouter des microservices.
Mais rien que le corps
de Asura,
c'est déjà hallucinant
en termes de gain de temps,
de performance,
et de facilité
d'usage,
c'est vraiment hallucinant.
Oui.
Ok.
Et alors,
dernière question, et puis...
Oui, vas-y.
...côture de podcast.
Niveau performance,
qu'est-ce que ça donne,
parce que justement,
ça fait une sorte de Gateway
avant la base de données,
donc il y a du traitement,
avant d'atteindre les données,
et de les renvoyer.

En fait,
il n'y a pas de recalcule, en fait.
C'est...
Donc, c'est vraiment inodorant,
un color.
J'avoue,
n'a pas à avoir poussé
jusqu'au bout.
Par contre,
c'est une surcouche
qui est vraiment
infime et inodorant,
un color, quoi.
Donc,
le fait de passer
par Asura
ne va pas ralentir
tes requêtes.
Moi, je dirais même,
je pense que entre Asura
ou un resolver
fait à la mano,
qui n'est pas du tout optimisé,
je pense que
Asura est rapide.
Oui, oui.
Donc,
non, non, je ne me fais pas vraiment.
Il n'y a aucun souci.
Et en termes de
limite de perf,
je ne pourrais pas dire,
mais je sais qu'on est
à plusieurs dizaines
de milliers de requêtes
par seconde,
et ça pose pas de problème, quoi.
On ne fait pas de salice
à la Facebook, donc, ça va, quoi.
Voilà, après,
ce qu'il ne faut pas oublier,
c'est que,
ça reste du GraphQL.
Donc, si on fait une énorme query
avec plein de choses
nestées à l'intérieur,
évidemment, ça va être plus long,
quoi.
Mais la question, c'est,
est-ce qu'on a besoin
de toutes ces données
à ce moment-là,
est-ce qu'on ne peut pas différer
l'appel de toutes ces données-là ?

Après, en fait,
c'est l'optimisation,
c'est l'optimisation et de l'archi
vraiment au sein de l'application.
Par contre,
la puissance
et le moteur GraphQL,
le moteur à Soura,
il est très performant.
Et donc,
quoi, de toute façon,
là-dessus,
il n'y a aucun problème là-dessus, quoi.
Et alors,
cette fois, c'est vraiment la dernière.
Il y a un système de cash,
ou pas ?
Oui.
Oui, en fait,
c'est une fonctionnalité
qui sont rajoutées
il n'y a pas longtemps,
mais tu peux,
ça se fait sous forme de directive,
c'est-à-dire,
tu vas te décider que cette query-là,
tu vas la cacher,
parce que
tu as fait le choix...
Parce que ça change jamais,
tada tada...
Pour X raison,
et donc, tu viens la cacher
et en fait,
à Soura va gérer
ce cash
pour toi.
Alors, à savoir,
pour ceux
qui font du GraphQL,
on sait que c'est un peu compliqué,
le cash,
parce que c'est le client
qui demande,
donc,
on ne peut pas cacher
à l'avance.
Il y a plein de systèmes
qui ont été mis en place,
des Graph CDN,
sur Apollo Server,
ils ont trouvé,
il y a toute une librairie
qui vient optimiser
un peu ce cash.
Mais c'est vrai que c'est un problème
sur GraphQL.
En tout cas,
à Soura,
mais c'est vraiment récent,
ils ont mis un système de cash
en place
pour pouvoir optimiser ça.
Donc, côté front,
tu décides
cette requête,
et tout ça.
Exactement.
À Soura, ils sont automatiques,
enfin,
ils ne font pas automatiquement
en ce temps qu'ils décident.
C'est ça.
C'est génial.
Non, c'est cool.
Il faut tester.
Il faut tester.
La Dock est super bien faite.
C'est complètement matur
pour de la production.
Aucun problème là-dessus.

et on s'évite,
on gagne vraiment du temps,
et on s'évite plein de
de boulots pas trop,
trop, trop intéressants,
et on se concentre
sur la business logique,
et ça, c'est le plus important.
C'est une résolution de 2022.
Se concentrer sur la business logique.
Arrêter de faire des trucs chiant.
Ouais, je suis d'accord.
Je suis d'accord.
Ok, bah écoute, super.
Super, merci.
Moi, je vais tester,
ça me donne envie.
Claire mouille.
Parfait.
Voilà.
Et bah, on remercie tout le monde.
On remercie tout le monde
d'être restés jusqu'au bout de l'épisode.
Merci, on se dit à bientôt.
Merci à Ndid.
Merci à Ndid.
Et à bientôt.
Ciao.
Ciao, ciao.
...