Bienvenue sur Double Slash, le podcast dédié aux outils et aux techniques pour le développement
web.
Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash.
Comme d'habitude, nous sommes avec Alex.
Salut Alex ! Salut Patrick, salut tout le monde !
Donc Double Slash, le podcast indépendant le seul vrai lié à aucune agence, je le répète
maintenant à chaque fois.
Donc épisode spécial DB, basse de données.
La base de données est quand même super importante pour tout ce qu'on fait depuis le début
de l'informatique.
On a toujours eu besoin de stocker des données et évidemment ça a évolué.
Et on va parler de ça.
On va commencer, je vais dérouler un petit peu le sommaire.
On va partir sur les types de DB déjà.
On va commencer par les types de DB, SQL, NoSQL, tout ça.
Ensuite, on va parler un petit peu des hébergements de base de données qui sont disponibles.
Et on va passer après sur les nouvelles new SQL, tout ce qui est un nouveau système SQL
pour stocker avec des nouveaux paradigmes.
Donc ça, ce sera sur la fin de l'épisode.
Mais donc, on va commencer par les types de DB.
Alex ?
Carrément, après ce qu'il faut comprendre, c'est que moi je me suis rendu compte qu'on
utilise plein de DB, mais parfois pour des mauvaises usages.
Et un peu comme une boîte à outils, je pense qu'il faut vraiment avoir le bon outil pour
le bon usage.
Et on va voir, tout le monde a connu l'effervescence du NoSQL, du Mango DB, tout ça.
Mais en fait, pourquoi on a eu cet engouement ?
Et je pense qu'il y a eu une hype autour de ça.
Et je pense que c'est important de bien clarifier, il y a différents types de catégories de
base de données.
Et je pense de bien connaître ces catégories-là, ça peut nous aider justement pour faire
notre choix et comprendre les enjeux de notre choix technologique quand on choisit quelque
chose.
De toute façon, la hype, c'est dans notre métier.
Bien sûr.
Même toujours une belle chose.
Des nouveaux frameworks, un new system.
Il y aura toujours un influenceur ou un podcasteur.
C'est ce qui nous motive aussi.
C'est ce qui nous motive pour se motiver, pour coder.
Exactement.
Bon allez, on commence par la plus ancienne SQL.
La base de la base, c'est vraiment des relations classiques avec une hiérarchie,
des tables, des colonnes, avec des parents, des enfants.
Ça fait super longtemps que c'est mis en place.
C'est relativement stable aujourd'hui.
C'est une technologie qui est prouvée, qui est maturée.
Donc, voilà, on va dire, un reste.
L'argement est utilisé.
Exactement, que ça soit du MySQL, du Postgre, en open source ou de l'oracle, du SQLite,
les choses un peu plus légères.
On va trouver ça partout.
Même si sur les dernières versions de Postgre, ça fait déjà plusieurs versions, mais il
y a eu l'intégration directement du format JSON.
Donc, on peut vraiment stocker du JSON à l'intérieur d'une instance Postgre.
Donc, ça, c'est assez intéressant parce que ça va nous ouvrir un peu les possibilités.
C'était un réponse à tout ce qui était MongoDB, tout ça, pour pouvoir stocker des
données qui sont moins relationnelles.
Oui, moins structurées.
Quels sont ton avis un peu l'inconvénient des bases SQL ?
La vitesse peut-être.
Alors, peut-être la vitesse, si elles sont mal indexées.
C'est ça, souvent.
Si elles sont...
Oui, en fait, aujourd'hui, il y a des indexes où on peut utiliser ces indexes pour justement
optimiser la recherche.
Et c'est vrai que si on fait sur une requête, on va faire 20 000 joins, 2-3-4 joins pour
aller agréger différentes tables pour construire la requête.
C'est vrai que ça peut être assez long, d'où l'intérêt d'utiliser des indexes.
Et pour le coup, l'utilisation d'index va vraiment solutionner...
Ça va faire des gâpes vraiment monstrueux en termes de rapidité.
Après, pour le SQL, ce qui est vraiment avantageux, c'est vraiment tout ce qui est
relation entre l'étape, etc.
Et aussi, les cascades, quand on va supprimer un élément, ça peut faire des cascades pour
supprimer un élément qui est lié, etc.
Donc il y a vraiment des avantages à utiliser ce type de base de données.
Donc, c'est aussi pour ça, peut-être que c'est majoritaire.
Mais voilà, il y a quand même des inconvénients de...
Voilà, il faut bien optimiser.
Il y a beaucoup de développeurs qui utilisent des bases SQL, mais qui ne sont pas forcément
très au point pour faire les bons index, tout ça.
Donc, c'est vrai que c'est bien aussi de se former de temps en temps là-dessus.
Oui, je pense qu'on n'utilise pas, et en tout cas pas assez le plein potentiel de toutes
ces bases de données.
Je pense souvent aux fonctions posgrés.
Moi, j'utilise plutôt posgress.
Et en fait, on n'utilise pas assez souvent les fonctions.
Et en fait, les fonctions, on te permet de faire des choses, mais des trucs hallucinants.
Pareil, les vues peut te permettre d'agréger des données facilement au lieu de faire du
traitement en back-end.
Là, on va le faire directement au niveau du legeur de la base de données.
Donc, c'est plus rapide.
On ne transporte pas de la donnée pour rien.
C'est vraiment...
C'est souvent des technos qu'on touche du doigt, mais on ne va pas assez en profondeur.
Et on n'utilise pas le plein potentiel de ces technos-là.
Parce qu'on reste toujours dans ce qu'on sait faire.
Parce qu'elles arrivent par défaut, et puis on les prend comme elles sont.
Et donc, comme on avait des problèmes de vitesse, on a créé le no SQL.
Alors, des problèmes de vitesse, oui, mais aussi pour des données non structurées.
C'était un gros argument.
Mais l'idée, c'était de prendre un JSON classique.
Par contre, on ne connaît pas à l'avance, il n'est pas prédictible.
On ne sait pas exactement toutes les clés qu'on va avoir.
Donc, il est plus ou moins semi-structuré.
On ne sait pas exactement comment va être la structure du JSON.
Donc, on voudrait stocker ce document-là.
Et il n'y a pas toujours de relation.
Et en fait, le no SQL est parti de là.
Et le gros argument qu'ils ont mis en avant,
justement, c'était la rapidité d'exécution et la rapidité de requête.
Et pouvoir aussi traiter des énormes, des gros, gros volumes de données
avec une latence hyper faible.
Donc, c'était le gros, gros engouement qui a eu.
Et je pense qu'une boîte privée, MangoDB, pour ne pas les citer,
on réussit vraiment à faire une sorte de hype autour de ça.
Où ils ont réussi à base de marketing, à convaincre plein, plein de gens.
Effectivement, oui, c'est rapide, c'est super efficace.
Par contre, faire du MangoDB comme du SQL,
avec de la relation, avec des parents, des enfants,
je vois ça pas spécialement l'intérêt.
Et surtout, en fait, c'est super, c'est over compliqué.
Et on va dire qu'on détruit tous les avantages de l'outil
en essayant de twister un petit peu la techno.
Et donc, je vois pas toujours l'intérêt.
Parfois, c'est super intéressant.
Je pense que si on fait des statistiques,
des énormes bases de données de data,
où on va collecter beaucoup de data,
mais on sait pas exactement comment on va les recevoir.
Bon, là, l'avantage, c'est qu'on peut tout stocker.
On peut stocker à l'intérieur des objets,
des objets à l'intérieur nestés, tout ça.
On ne va pas parler que de Mango ou de NoSQL,
mais dans l'idée, c'est quand même assez puissant pour traiter
des gros volumes de données, des hyper rapides.
Par contre, attention à pas faire du SQL avec du NoSQL,
c'est un non-sens.
C'est souvent ce qu'on se retrouve à faire à un moment donné.
Il y a aussi un avantage sur tout ce qu'est NoSQL,
c'est qu'une table, tu peux avoir des structures différentes d'objets.
Donc, tu peux rajouter des valeurs.
Ce que tu ne peux pas faire en général dans du SQL,
tu as des colonnes et puis voilà, des colonnes, c'est des valeurs.
Et là, en NoSQL, tu peux rajouter des valeurs sur un objet
que tu insères dans une table à la volée.
Donc, tu vas te retrouver avec des objets qui ont des différentes valeurs.
En fait, pour moi, le NoSQL, c'est bien,
mais ça devient vite...
Enfin, je vais dire, le bordel, si tu ne structures pas bien.
Et puis, comme tu dis, ça correspond à un certain usage,
mais il ne faut pas forcément en mettre partout.
Donc, carrément.
Et pour le coup, dans les recherches sur l'épisode,
là, je suis tombé sur une petite base de données
qui est optimisée donc, qui est NoSQL,
mais qui est optimisée sur le temps réel.
Et en fait, il y a un layer de mise à jour.
Donc, il y a un client qui s'ouvre entre tous les clients,
vont s'ouvrir et quand il y a une modification qui est faite,
la modification est envoyée à tout le monde
et s'appelle ReSyncDB.
Donc, l'idée, c'est de repenser la DB, mais c'est tout en gissonne.
Et par définition, ça se synchronise automatiquement
sur tous les clients qui sont ouverts à ce moment-là.
Donc, c'est une sorte de push.
Alors, je ne sais pas si c'est du web push, du web socket
ou du serveur event,
mais je pense plutôt à du serveur event.
Mais je trouve ça super intéressant.
Il donne des exemples pour des highlights en gaming,
voilà, pour avoir le meilleur sur des choses comme ça.
Et là, c'est super intéressant
parce qu'on n'a pas besoin de coder ce système de synchronisation.
Il est fait automatiquement par la DB.
Donc, je trouve que c'est un super exemple
au lieu de repenser et de coder la chose dans notre back-end.
On peut s'appuyer directement sur la techno qu'il le fait directement.
Auti parfait pour faire du chat.
C'est parfait pour faire un chat
qui, voilà, chacun est dans un groupe, tout le monde reçoit une notification.
Mais en plus, c'est vrai que pour le coup,
c'est des structures qui ne sont pas forcément...
Enfin, il n'y a pas besoin de structurer vraiment la donnée, c'est du chat.
Donc, pour le coup, le NoSQL est vachement adapté.
Ouais, pas mal.
Carrément.
Carrément.
Du coup, les DB qui valuent, c'est du NoSQL, quoi.
Alors, en quelque sorte, oui.
Parce que c'est de la donnée qui n'est pas toujours structurée.
Donc, on pourrait dire que c'est une sous-famille,
une sous-catégorie des NoSQL.
Mais on va retrouver le plus connu qu'on connaît, c'est Redis.
Et évidemment, c'est le top.
Qui est directement sur une base de données en mémoire, quoi.
Là, pour le coup, ça va être très, très, très, très, très, très rapide.
Et c'est utilisé pour faire du cache, évidemment.
Pour stocker de la donnée.
Pour streamer des informations.
Et aussi, pour tout ce qui est broker.
Ou en fait, on va sur la gestion d'event,
en fait, on va emmagasiner des informations avec des Q.
Par exemple, des tâches qui sont à faire.
On va les stocker dans le Redis en une sorte de mémoire tampon.
Et on va les consommer au fur et à mesure.
Donc, ça, c'est beaucoup utilisé pour ça.
Et il y a Redis qu'on connaît, qui est assez ancienne.
Ouais, qui est partout.
Par contre, il y a une nouvelle techno qui s'appelle Dragonfly.
Qui, en fait, a pour but d'exploser en termes de perf Redis.
Mais c'est sûr.
Pourtant, c'est déjà très, très rapide Redis.
Donc, je sais pas comment ils font.
Mais en fait, j'avais lu l'article, si on le résume ultra rapidement.
C'est un problème de scalabilité.
En fait, Redis, pour passer à l'échelle,
ils sont obligés de déployer en horizontal.
Alors que Dragonfly va pouvoir verticaliser.
Et donc, ça va être beaucoup plus rapide.
Ils vont pouvoir aussi se décentraliser et distribuer tout ça.
On va en parler tout à l'heure,
sur toute cette notion de distribution.
Mais en tout cas, Dragonfly.
Là où ils ont été super malins,
c'est qu'ils ont repris la même API que Redis.
Forcément.
Et oui, ils sont malins.
Comme on dit toujours, il y a toujours une primeur.
Du coup, tu peux remplacer ton Redis facilement.
Exactement.
Sans changer le code.
Et les gars, c'est beaucoup plus rapide.
On regarde, essaye.
Et malin, en termes de nouveaux produits de façon...
C'est ce qu'on disait, il y a toujours une primeur,
celui qui arrive en dernier.
Parce qu'il bénéficie de toutes les expertises des anciens
qui ont construit un paradigme,
sur une architecture.
Et le nouveau paradigme vient changer la règle.
Donc intéressant.
Ok.
Ensuite, il y a un autre type de DB.
C'est Time Series.
Alors, je ne vois pas du tout ce que c'est.
Alors, en fait, les Time Series DB,
c'est des bases de données
qui sont basées sur le code.
Et puis, on va utiliser sur un repère temporel.
En fait, on va utiliser le temps.
Oui.
Comme base.
Donc, c'est beaucoup utilisé pour des statistiques,
pour enregistrer tout ce qui est capteur de IoT,
en fait, à un instant T.
La valeur, elle est là.
Donc, par exemple, pour du monitoring aussi.
Si on veut regarder les informations
d'un serveur, à l'instant T,
en fait, il y avait telle valeur.
Et donc, c'est évidemment du NoSQL.
Par contre, la valeur la prédominante,
c'est le temps.
D'accord.
Et donc, on va avoir Influx DB
qui est assez connu pour ça.
Sinon, il y a une note qui s'appelle
Time Scale.
Il y en a plein d'autres.
On est d'accord.
Mais dans l'idée,
ça va être très utilisé pour faire des graphiques,
des choses comme ça.
Et ça va pouvoir traiter
des quantités astronomiques
de données très rapidement
et d'avoir des clés de lecture
qui sont basées sur le temps
pour faire un affichage
plutôt intéressant.
Donc, si on refait tout simplement
de l'analytique, par exemple,
de l'analytique classique,
il y a toujours cette notion
de repères temporelles.
Et donc,
il y a des bases de données qui sont faites pour ça
et qui nous amènent une grande liberté
pour après, justement,
requêter les données basées sur le temps
de telle date à telle date.
Et voilà.
Ils ont un juste très, très spécifique.
Mais bon, ça existe.
C'est très utile.
Ok, ensuite, nous avons les types graphiques.
Alors, ça, c'est quoi ? Graphiques.
Alors, c'est des bases de données
au lieu d'avoir des colonnes
de valeur et
colonnes lignes.
En fait, on va représenter
la base de données
avec des entités, des nœuds
et des connexions.
Et
on va faire des recats
par rapport à ces connexions-là.
Un exemple spécifique, par exemple,
on va prendre un réseau social
classique Twitter.
J'ai des followers et j'ai des following.
Et bien, en fait, au lieu de prendre la personne
et d'appeler
on va dire, en SQL classique,
tous les followers,
là, on va appeler
la connexion follower entre
une entité
et en fait,
c'est la relation entre
les nœuds qui va être
aussi importante
que l'objet
ou la ligne par elle-même.
Donc, c'est très utilisé, justement,
pour les réseaux sociaux, dans les jeux vidéo
et pour les systèmes
de recommandations.
En fait, par contre,
là, ça change le paradigme.
C'est très social,

C'est une sorte de surcouche
qui te sépare
les choses en sorte de neugraphie.
Oui, c'est...
Pour ceux qui nous suivent sur YouTube,
on est allés voir
une des plus connues, c'est-à-dire, Neo4G,
4 Neo4G
et
visuellement, en fait,
là, on est obligés
de voir
un espèce de schéma, sinon,
on comprend pas exactement
ce que ça passe et à quoi ça
représente, commence
à se structure en clair. Mais c'est
vraiment de nœuds,
donc, un objet
et les relations
qui peuvent avoir entre elles
et après, on peut avoir différentes connexions
à travers différents nœuds.
Enfin, voilà, c'est là, pour le coup,
on change de paradigme
et il faut vraiment faire
l'effort de
repenser...
Je pense que la porte d'entrée
pour utiliser
ces bases de données et pas de données,
je pense qu'il faut vraiment faire l'effort
de 6 mètres,
de twister le modèle un peu
pour comprendre.
Ouais, pour comprendre le truc,
sinon, ça me paraît
assez difficile.
Et le dernier type de DB,
une qui est très utile aussi,
c'est les DB pour la recherche,
spécifique à la recherche.
Et ouais, parce qu'en fait,
sur du SQL, alors oui,
on va avoir des fonctions
de full text search,
mais voilà,
si je veux faire
un moment donné, il faut que
j'aille requêter toutes
les entités qui ont le mot
Batman dedans.
Voilà, j'ai une base de données avec des films,
mais je veux
tout ce qu'il y a sur Batman.
Bon, à un moment donné, je vais vite
être limité par la performance
de la requête SQL
et par définition,
elle ne sait pas
où aller chercher dans les entités.
Donc, c'est là où il y a des technologies
qui se sont mis là-dessus, justement,
sur
cette fonctionnalité de recherche,
en fait.
Et c'est vraiment un modèle
à part, c'est
une architecture vraiment spécifique.
Alors, historiquement,
la plus ancienne, c'était Elastic Search.
Même s'il y avait Tabsense,
il y en avait tout, mais la plus grosse
pendant longtemps a été
Elastic Search.
C'est super bien, c'est super pratique.
Par contre,
à configurer, c'est
un enfer, un enfer total.
C'est ça.
Ce qu'on essayait,
le same.
Après, il y avait aussi des gens
qui se sont spécialisés
dans ces
systèmes de recherche,
pour justement, en fait,
amener leurs expertises
et dire, ok, moi, je me suis spécialisé
dans l'optimisation
de la base de données Elastic Search
pour faire de la recherche pertinente.
Donc là, on va aller dire, ok,
quel mot-clé,
sur quel mot-clé, quelle est la pondération,
le titre
à plus de valeur que la description,
la catégorie à moins de valeur que la description.

Il y avait tout ce système.
Par contre, on arrive... Du coup,
c'était pas accessible à tout le monde.
Il fallait déjà trouver quelqu'un
qui sache le configurer, etc.
Exactement. Il y avait
une grosse porte d'entrée et un gros frein de technologie.
Et derrière, il y avait aussi
une infrastructure à mettre en place
qui est assez lourde.
Mais qui se fait ?
Mais ça, c'était avant.
Parce que maintenant,
y a Melly Search.
Alors, y a Melly Search
ou Algolia.
Oui, exactement.
On peut parler de Algolia.
Les deux.
Exactement. En fait,
le système
c'est
un service de recherche
exactement pareil.
On va indexer des documents.
Et ces documents-là
vont être accessibles
via
une barre de recherche.
Donc, c'est vraiment une barre de recherche
à la Google. On va taper
par exemple,
Bautman. On va même pouvoir
faire une tipeau.
Et lui, en fait,
dans les configurations, on va
configurer ça, mais de manière assez facile
et assez explicite.
Merci, Ladoc, qui est très bien fait.
Mais l'idée, en fait, c'est
de devenir intégré un moteur de recherche
à l'intérieur de notre application
basé sur des documents.
Par contre, c'est une base de données
qui est spécifique et dédiée
à la recherche. Donc, ça veut dire qu'il y aura sans doute
un réplica de données
qui est indexé
pour la recherche.
Donc,
c'est là où, pour le coup, Melly Search
vient,
c'est beaucoup plus facile à installer
après un métier.
Et c'est assez facile
à mettre en place.
En fait, la seule chose que tu as à faire
au niveau de ton site, mis à part
installer Melly Search ou utiliser la service cloud,
c'est de synchroniser, en fait,
quand tu vas créer
ou update un élément,
de le synchroniser avec Melly Search
pour que ta base de recherche reste synchro.
Mais c'est plutôt facile. Il y a des API pour le faire.
C'est hyper simple pour le télétris.
Et de temps plus, ils ont fait
tout un SDK
pour chaque langage.
Pour toutes les technologies.
Et l'idée,
moi, je serais plutôt d'avis d'utiliser,
si on utilise du Postgre, par exemple,
on a des hooks qui nous permettent de dire
à la création
ou à l'update,
tu vas déclencher quelque chose.
Et donc, ce quelque chose,
ça va être, par exemple, une fonction serverless,
pourquoi pas,
qui prend en fait la nouvelle identité
et qui vient l'updater directement
sur Melly Search.
Donc, ça, c'est super pratique
parce qu'on a une base de données
de recherche qui est tout le temps
à jour et tout le temps synchronisée.
Et qui est surtout ultra
rapide. C'est aussi l'intérêt
d'algoglier au Melly Search.
Et on a un petit faible pour Melly Search,
parce que déjà, ils sont venus
sur le podcast, je ne sais plus quel épisode.
Il y a un petit moment.
Qui sont en France et qui sont faits
avec du Rust, donc il n'y a pas plus
Rapingo, vraiment.
Et donc, soit vous pouvez l'héberger
vous-même avec un système
de cœur ou je ne sais plus quoi.
Et sinon, il y a le service cloud
qui est accessible en tarif dans les premiers niveaux.
Donc, c'est vraiment
très simple. On en parlait juste avant l'épisode,
mais c'est vraiment très simple de avoir une recherche super efficace
sur un site aujourd'hui
en 2030.
Exactement.
Exactement.
Et quand tu parles
de cloud
et débergement,
ce qu'il faut comprendre, c'est que depuis tout à l'heure
on parle de différentes DB.
Par contre, ces différentes DB, il faut les mettre
sur internet, accessible,
sur internet. Et pendant
très longtemps, on prenait
une machine. Ok, on mette
notre DB dedans. C'était notre DB.
Et en fait,
est venu de plus en plus
ce système
de service
hébergé, où en fait
au lieu de gérer une machine
d'installer la DB
en local sur la machine
et de gérer
toute la problématique qu'on peut avoir
d'autoscale, de
backup,
de déploiement vertical,
par exemple, horizontal.
Un moment donné, il faut augmenter la machine.
Elle est limitée. Donc on met un réplica.
On met un système d'architecture
parce que je veux que ça
y ait maître esclave. Donc on enregistre la
donnée, on la réplique.
Voilà, tout ça,
ça demande un savoir-faire du temps.
Et en fait,
ouais, hashtag DevOps
évidemment. Et en fait,
est venu
on va dire, depuis
pas mal de temps, mais ça prend
de plus en plus de place des services
qu'on dit
DB as a service. C'est vraiment de la base
de données en tant que service
où là on met la carte bleue, on
choisi l'instance, ok je veux du post-gray,
je veux du mango DB, et on
récupère directement une string
de parametteurs
et toute la gestion
des backup
du scaling
se fait automatiquement.
Et donc ça, c'est
quand même assez intéressant
et alors tout le monde le propose
que ça soit
scaleway, Amazon,
DigitalOcean, pour des
machines physiques.
Par contre, il y a d'autres services
qui sont venus en surcouche
et souvent c'est quand même Amazon
derrière, mais c'est
de la surcouche quoi.
C'est aussi au fait que
les applications on utilise de plus en plus
le cloud, les edges, tout ça. Donc on a
de moins en moins de serveurs, nous-mêmes
en fait en tant que développeurs
ou service, on n'a pas de serveurs forcément. Donc
on a besoin d'un truc comme ça disponible
à ce service et puis ça
nous enlève toute la complexité comme tu dis.
C'est vrai que même si Amazon tout ça
propose des bases de données en cloud,
il faut quand même toutes les configurées,
les droits, etc. c'est compliqué. C'est vrai que
maintenant il y a des nouveaux services qui sont
hyper simples à utiliser.
Évidemment il faut toujours mettre la carte bleue,
mais ça à un moment donné faut toujours la mettre.
Mais bon, on gagne
du temps aussi de développement et de configuration.
Donc c'est aussi du temps
qu'on aurait payé un développeur, tout ça.
Exactement. Après
je ne sais pas toi, mais
moi je vois une tendance quand même, sur tous les services gratuits
ça
ça se ferme de tout.
On va dire l'offre
free, elle se réduit
de plus en plus. De moins en moins free.
Mais en même temps
quand on voit le prix des serveurs, de pour faire
tourner des serveurs, tout.
Et donc il y a un peu
une période de crispation, on va dire
sur la partie gratuite, même si on arrive encore
à trouver des services gratuits.
On arrive encore. Mais on sent
que c'est de moins en moins généreux
et que la fin du tout
gratuit arrive.
Et en même temps
ça se tient aussi.
C'est normal. Ils nous ont donné
le goût.
C'est un peu comme le dealer de drogue, la première dose.
Et maintenant on est à croix et maintenant il faut
payer.
Après c'est vrai qu'il y a des coûts de structure
et les start-ups en ce moment c'est un petit peu plus dur.
Donc ça se resserre un petit peu.
Et tu parlais
de Edge tout à l'heure.
On a parlé de serverless.
On va pas faire
la hype si c'est bien ou si
c'est pas bien le serverless. C'est pas le but.
Par contre on voit qu'il y a quand même une tendance
où il y a de plus en plus
de services qui sont
sur du serverless. Mais il y a aussi
cette tendance. Et on a
parlé sur l'épisode sur le Edge
justement de devenir
de tout répliquer
d'être au plus proche
de l'utilisateur. Parce qu'aujourd'hui
on va
avoir des clients en Europe. Mais
parfois ces clients vont bouger en Australie
aux Etats-Unis. Et donc
il y a cette idée de répondre au besoin
au plus proche.
Et cette idée
de service et de distribution
de services, elle est super
importante pour
ces histoires
de serverless aussi. Parce que
en fait, ce qu'il faut comprendre c'est que
quand un client vient se connecter
à une base de données, il y a une
poule de données qui est
ouverte. En fait c'est une poule de connexion
et cette poule de connexion
elle est limitée. Donc
il faut qu'on optimise
ces ouvertures.
Sauf qu'on peut faire passer plusieurs clients
dans une seule connexion de la poule.
En clair, c'est un vrai problème
pour la base de données.
Alors pour nous souvent développeurs,
on n'a pas à gérer ça. On va avoir un ORM
qui va gérer ça.
Mais quitte justement de toutes ces
services
de DB
qui justement, eux, vont répondre
à ce problème-là. Ils vont optimiser
le poule de connexion directement
pour nous. Je pense à
Prisma qui avait sorti
un service, qui a toujours
un service où en fait
on va avoir une base de données, une instance
de base de données. Sauf que si j'ai
100 personnes
qui se connectent avec 100 serveurs last
function différentes
là, ça va péter
parce que la poule de connexion est
limitée. Et donc en fait le data
c'est Prisma,
data proxy ou tout ça.
En fait, toute la poule de connexion
gérée par ce service-là qui va
optimiser la connexion avec
la DB. Et c'est un gros
gros problème
qui résout
justement quand on passe
par ces DB as a service
où on n'a pas à gérer
ce flux-là.
Caramment, en fait, au-delà
de poser la base de données
au plus près de l'utilisateur,
de toute façon ils seront toujours mieux optimisés
que ce que tu pourrais faire sur un serveur perso, tout ça.
Parce que c'est leur métier,
parce qu'ils font ça bien. Donc,
tu auras toujours une base de données qui sera plus rapide.
Donc, dans l'idéal, c'est
utiliser ces services-là.
Oui, carrément.
Et je pense par exemple
à Upstache,
qui est l'idée,
c'est... Oui, Upstache. Alors, je ne sais pas.
C'est si, oui.
Non mais le nom est marrant.
Oui. Et pour le coup,
c'est
pour du Kafka ou pour du
du Redis.
Et on va pouvoir
en 10 secondes,
on a monté
une DB
Redis. Enfin, non, on n'a pas monté.
On a accès
à une DB
Redis qui va être
répliquée ou pas avec
un
rating où voilà, c'est
limité à 10 000 commandes
jour. Bon.
Pour la partie free.
Oui, pour la partie free.
Et donc après, on va payer
au nombre de commandes.
Et il y a aussi une tendance
qui est un petit peu
justement sur ces DB As-a-Service.
Au lieu de payer
des trucs
fixes, enfin des prix fixes
avec des forfaits
qu'on ne consomme pas
la données,
la tendance quand même est
aux As-a-Service.
C'est-à-dire, tu paies ce que tu consommes.
Ouais. Alors, ce qui est
un petit peu plus faire, en
termes de, enfin je trouve ça
beaucoup plus équitable, parce que
c'est intéressant. Par contre, le
problème, c'est que le calculateur
en fait, quand tu vas avoir ton client
et tu lui dis bah tu vas payer ce que tu vas consommer
Ouais, mais combien je vais payer?
Bah, je sais pas.
Je sais pas.
C'est classique, mais c'est classique d'Amazon.
Mais bon, ce qui est bon, c'est service
utilisé d'Amazon en arrière-plan, donc
c'est aussi pour ça que ça représente
un peu ce système. Mais c'est vrai que
c'est compliqué de pas savoir
combien tu vas payer. Alors, souvent
il y en a qui proposent des calculateurs, mais
c'est pas toujours disponible.
Ouais, et en fait, c'est super
difficile quand un service
qui a à peu près moyen,
ok, mais si, enfin, moyen
en termes d'usage, c'est-à-dire ok, j'ai
déjà des clients,
j'ai déjà un business,
par contre, j'ai pas spécialement
des outils de monitoring précis
pour savoir combien de fois
je vais taper mon redis.
Donc, pour faire des
calculs, en fait, c'est que
aux doigts mouillés, quoi.
Donc, souvent, tu mets ta carte bleue,
tu fais la transition technologique,
tu payes
et tu payes ta première facture, pis à ta première facture
c'est un peu la surprise, quoi.
Ok, c'est 200 balles. Ah ok, c'est 2000 balles.
Ah, ok, ça va pas le faire.
Mais bon, après, on peut avoir
quand même des tendances pour savoir
à combien on est, si on est loin
ou pas, quoi.
Dis donc, si tu as installé un système comme ça, il vaut mieux
tester.
Voilà, tu regardes combien ça consomme par jour.
Ouais.
Donc, faut tester avant de tout balancer
dessus, parce que...
Ouais, mais ton prix d'installation,
une migration technologique, ça coûte toujours
du temps, de l'énergie,
enfin, donc c'est de l'argent.
Ok,
enfin, c'est pas aussi facile
de dire, ok, je déploie que la
moitié de mon infras là-dessus,
voilà, parce que...
Là, tu vois, 10 000, ça peut aller très vite,
pour la partie free.
10 000, il suffit que tu fasses des appels
redis pour afficher
chaque service, enfin chaque page,
où tu fais une dizaine d'appels
à redis. Et ça peut aller très vite.
En fonction du nombre de visiteurs.
Donc après, bon, il faut voir, mais...
Toujours est-il
que toutes ces
services-là, souvent
offrent des solutions
qui s'appellent distribuer, c'est-à-dire.
En fait, l'intégralité des données
va être géorépliquée.
Et surtout, en fait,
il va y avoir une disponibilité
et une performance accrue,
parce que, au lieu d'être
centralisé sur une seule machine,
l'information
et toutes les requêtes vont être splité
en différentes
machines. Donc ce qui va leur donner
une grande...
un taux de réponse hyper
rapide. Ils vont être
géorépliqués.
Par contre, ça amène
un gros problème, mais ça,
il adore un color pour le développeur.
Par contre, il faut garder
les fondamentaux d'une base de données.
C'est-à-dire qu'elle soit safe,
on ne va pas développer le acide,
mais atomique, cohérent,
et tout ça.
Mais c'est un gros, gros
défi technique.
Oui.
Pour conserver
la même chose
sur des données qui changent, en fait.
C'est ça, en fait, le défi.
Il y a des données qui changent tout le temps et qui font...
Et sur des gros volumes,
en fait, ça va être géorépliqué
partout. Il faut que ça soit consistant
partout.
Mais l'idée, c'est au lieu
d'avoir...
En fait, le concept
de distribuer, c'est assez simple. C'est au lieu d'avoir
une seule machine. On va avoir
plusieurs machines qui vont répondre
en même temps. Donc,
voilà, au lieu de faire une machine
qui fait une tâche, il y a
cinq machines qui vont faire 0, 22
de la tâche. Et comme ça,
ça va être beaucoup plus rapide. Et on va
pouvoir aussi scaleer
dans tous les sens. Donc ça,
c'est plutôt
intéressant. Et cette tendance
est à la distribution.
Ok.
Ok, ok.
Tu as un upstage.
Il y a plein de quails aussi,
je crois.
Alors,
j'ai pas compris...
J'ai pas compris, excuse-moi.
Tu as un niveau de service
de base de distribuer. Tu as donc
upstage, tu as d'autres ?
Ouais, ouais. Complètement,
tu vas avoir...
comment ?
You got bytes
DB qui va être
pareil sur le même système.
Par contre, là, c'est du post-gray
et du multi-cloud.
Ce qu'ils appellent multi-cloud,
ça va être...
c'est exactement le même concept
de... enfin, c'est de la DB
post-gray distribué.
Ok.
Donc, et pareil,
as a service.
Donc, on va retrouver
la même chose
que sur des DB
classiques, avec
toute cette notion de service, analytics, tout ça,
et directement
sur le cloud, directement
accessible depuis...
Là, en termes de pricing,
là, ils sont à combien ? You got bytes ?
Tectec, en termes de pricing...
Ils ont peur de donner les prix.
Ouais, ça, c'est mauvais, ce que j'ai l'air à dire.
J'ai pas regardé...
J'ai pas regardé...
Il faut que je... je regarde
pricing...
Non. Ah ouais, le formulaire.
Contact.
Donc, du coup, il y a pas...
à mon avis, il y a pas de fritière,
et c'est un service direct, quoi.
Ok.
Ok, il y a une autre ou...
Oui, il y en a plein d'autres,
et la liste
est monstrueuse.
Donc, de toute façon, ce qu'il faut comprendre, c'est que
sur... pour la préparation de cet épisode,
je me suis cantonné
à vraiment...
celle que je trouvais le plus intéressant,
ou la plus solide, ou...
peut-être celle qu'il y avait même, peut-être le meilleur
en marketing. Mais...
l'idée était plus de parler
du concept, que vraiment
des... des...
des DB en... en elle-même,
et je voulais pas me faire
l'ambassadeur de toutes ces DB-là,
même si...
il y en a qui... que je porte un petit peu plus
dans mon coeur.
Ok.
Ce qui...
Qu'est-ce qui me...
Ouais.
Non, non, pas de problème. Moi, ce qui...
ce qui m'intéresse aussi, sur...
sur cette...
sur cette nouvelle tendance, en fait,
de... de... de distribuer,
c'est qu'il y a eu, quand même,
un gros avantage
à... à ça, c'est qu'ils ont
bougé un peu les technos,
c'est-à-dire, en faire du post-gré
OK, du MySQL OK.
Par contre, ils ont utilisé
un truc qui est assez intéressant, qui s'appelle
le... le YAL. Alors, le...
le YAL, c'est quoi ?
C'est, en fait, une
écriture de...
à chaque fois qu'on est... qu'on implémente
une ligne, en fait, on va...
c'est comme des logs
dans des DB. Et le gros avantage
de faire ça, c'est qu'ils vont pouvoir faire, en fait,
du branching
de database. Alors, pour
expliquer le concept de... de... de branching,
on connaît tout ce GitHub
avec du code qui est versionné
en différentes branches. Ça,
on... on... on sait tous. On peut
déjà versionner notre code avec
les fichiers de migration, mais
les fichiers de migration, c'est que
pour la structure de la DB,
c'est pas pour les données
à part entière. Et ben, en fait,
avec ce système de
lecture, en fait, des logs
de la DB, ils vont enregistrer
tous ces logs dans des fichiers
dans des... dans des bases
de données textes, dans des... dans
des documents, en clair, sur
des S3, par exemple, et ils vont pouvoir,
en fait, reconstruire
la DB à partir d'un certain
point. Et c'est ce que fait Planet
Scale ou
Neon DB.
Et en fait, moi,
j'ai vu ce concept-là chez... chez
Neon DB et je me suis dit
comment ils font, en fait ? Comment ils font ?
Je... je comprends pas. Je comprends pas
est-ce qu'ils font...
ils multiplient les instances de... de DB
pour autant de branches
qu'on a, ou... enfin,
comment ils font ? Et en fait, ils ont fait une
super conf... ils ont fait
une sorte de conf... une suren journée
où, en fait, ils expliquent tout
le concept et toute la techno qui est à
derrière. Et en fait,
voilà, c'est une sorte de bière
à trois bandes,
où, en fait, quand l'information
elle rentre, elle passe par un
système de... de log qui s'appelle
des IAL, exactement, c'est
vraiment interne à...
à... à... à Postgre.
Mais ce qu'il faut comprendre, c'est un
système de... de... de journal.
Et... tous ces journaux,
en fait, ces logs sont enregistrés
en tant que micro-transactions
et ces micro-transactions sont sauvegardés
sur un S3, ce qui nous permet, en fait,
de faire un... du
branching. Et là où c'est hallucinant,
c'est que... le... le temps... le temps de
réponse est...
microscopique, quoi.
Donc, en gros, c'est...
toutes les data qui sont enregistrées et
facées, etc., tout ce qui a modifié... qui est
tout ce qui est modifié et sauvegardé dans un fichier
comme une sorte de scénario, en fait.
Exactement. Et donc... et donc, tu peux
rejouer ce scénario pour un moment donné
pour revenir en arrière
ou avancer, etc. Donc, tu as vraiment une version
de ta base de données, de la data, on parle.
Pas de... pas de la structure.
Mais donc, bah, tu peux...
en fait, tu as une base de données qui est
complètement... bah, déjà, le backup,
c'est... il y a même plus de problèmes de backup,
puisque tu peux... parler en avant, en arrière,
retourner en le futur, etc.
C'est exactement ça. C'est... ok, je reviens
à tel point et...
donc, en fait, on ne peut plus, par exemple,
ah, j'ai perdu mes données, quoi. Ah, j'ai perdu
mes données, j'ai... j'ai... j'ai scratché
toute la DB. Là, ça n'existe pas.
Ça, c'est pas grave. Ok.
Retour vers le futur et...
et je reviens. Et...
pareil sur l'intégrité
des... des... des data dans... dans des branches.
Euh... bah...
voilà. C'est... c'est... c'est assez
hallucinant, c'est assez bluffant.
Et... et c'est...
c'est super pratique, quoi.
Ouais, carrément.
Ça, c'est... c'est les seuls à le faire,
le second scénario 6 dans de la 2, à la 2.
Alors, peut-être que...
je... je... je... dans mes recherches,
je n'ai pas poussé suffisamment.
Mais ça, c'est le plus connu. Ouais, on...
on va dire, euh...
PlanetScale est déjà assez...
assez balèze en termes de... de... de développement.
Néon...
sont... c'est encore nouveau.
Euh... je pense. Donc, PlanetScale est...
je pense, à maturité.
Euh... Néon...
il... il... il y arrive,
au fur et à mesure, mais en tout cas, ils sont
déjà... déjà implémentés.
Mais, euh... beaucoup moins que... que PlanetScale,
je pense. Et il y a sans doute d'autres
services qui existent. Ouais.
Que je... que je connais pas.
Euh... mais euh... qui... qui sont...
qui font, en fait, ce même système de
branching. Tout ce qui est data, de base
de données, c'est quand même sensible,
sur... sur les projets. Donc, il vaut mieux partir
sur un... sur un... sur un service qui est quand
même... relativement stable et connu,
qui va pas disparaître dans 2 mois, quoi.
Ouais. Après, euh... Néon, il
vient de lever, je sais pas combien, d'argent.
C'est que des anciens de chez Microsoft.
Euh... pour le coup, euh...
Bah... Ceux qui s'en fait virer dans les... dans
les... dans les vagues de licenciement, là.
Euh... Non, non. Ils sont partis il y a... il y a
2 ou 3 ans. Euh... Bon, ça va. Donc euh...
Donc, non, non, non. Pour le coup, c'est...
c'est quand même... c'est quand même...
solide, quoi. C'est vraiment ça. Ok.
Non, ça a l'air vraiment prometteur, hein. Je... je sais pas après, si ça va être...
répliqué sur d'autres services,
ou même directement dans Postgre, mais...
c'est... c'est vraiment top.
Ah, je pense pas que Postgre
puisse faire ça en natif, en fait.
Ouais, c'est difficile. Parce que c'est... c'est vraiment
une surcouche, euh... système, euh...
c'est une architecture, euh... par-dessus, quoi.
Donc euh... intégrer ça en natif, ça me...
ça me paraît un petit peu difficile, je pense.
Ouais, je pense. Ok.
Ouais, c'est super, tout ça. Et euh... on va passer
sur la dernière partie. Alors, tout ce qui est...
nouvelle, euh... enfin, new SQL, tous les
nouveaux services de base de données et tout ça.
Qui sont disponibles. Ouais.
New SQL, euh... alors...
la... la... la définition de
new SQL, je sais pas si c'est
officiel ou pas, mais en tout cas,
euh... c'est toutes ces... toutes ces
nouvelles technologies, justement, qui viennent
euh...
bénéficier de tous les héritages,
de ces SQL, no SQL, de ces...
données structurées, non structurées,
de ces ORM, de ces trucs...
de ces services distribués.
En fait, on voit qu'il y a...
une fusion, en fait, entre...
entre le no SQL et le SQL.
Euh... le... le paradigme, en fait,
de tous ces nouvelles DB, en fait,
ils disent, pourquoi choisir ?
Pourquoi choisir ? Euh... parfois, on a besoin
d'avoir quelque chose de structuré.
Parfois, on n'a pas besoin. Et bah...
nous, on va faire une base de données qui... qui donnent
accès au 2, quoi.
Donc, ça, c'est... c'est un peu la...
la tendance de... de new SQL.
Et on se dit... et ils se...
bah... nous, au lieu de passer par un ORM,
donc, en fait, qu'il y ait une couche
qui va interroger la DB,
bah, on va donner des accès à pays
pour consommer la... la DB,
directement. Mais dans...
dans la brique native, quoi.
Donc, on va avoir souvent soit...
un query language qui est propre à la...
à la... à la...
Au service ?
À la... au service, exactement.
À la base de données. Je pense...
en fait, les... les premiers qu'on lancé
un peu cette idée-là,
c'était FonaDB.
Qui avait fait un... qui avait fait beaucoup de bruit
quand ils étaient sortis il y a
3-4 ans maintenant, je pense.
Ouais, c'est...
Et... et en fait...
moi, le premier, c'était intéressant.
J'avais joué avec...
ils donnaient en fait un accès à pays
directement en GraphQL à leur données.
Donc, c'était super intéressant parce que
on venait structurer nos... nos données
et on avait la pays instantanément.
Et donc, ça, ça, c'est...
c'est super... super intéressant.
Par contre, si on voulait faire des...
des queries un petit peu plus poussées,
on était obligés de passer par leur propre
langage de query.
Et là, voilà...
ça, c'était un peu dur, quoi.
Ouais, c'est peut-être un... c'est peut-être un peu le défaut.
C'est qu'à chaque fois, ils ont un langage propre
et il faut à chaque fois apprendre un nouveau langage
des queries...
Ouais.
Spécifiquement.
Exact... exactement.
Et moi, le plus gros...
le plus gros frein que je voyais, c'est que
c'était surtout propriétaire.
Ouais.
Et c'est une techno propriétaire.
Donc, c'est une boîte noire.
On... on sait pas trop.
Par contre,
il y a de la scalabilité dans tous les sens.
Et... et en fait,
c'est un... c'est un peu...
la... tendance, c'est...
OK, c'est un service qui est
full-cloud, ou...
et là, on va le voir sur...
sur les nouvelles.
Je pense à SurilDB,
où là, c'est...
c'est la fusion entre tout.
Il faut tout.
Non mais clairement,
c'est hallucinant, parce que...
en fait, quand tu lis la doc,
tu dis OK, c'est l'USQL.
Mais tu peux faire aussi du NoSQL.
Tu peux mettre de la donnée
JSON, machin. OK.
Mais tu peux faire du KValue.
Ah, OK.
Mais tu peux aussi nommer les relations
et faire du graph...
de la base de données graph.
Ah, OK.
Et on a un système de...
type de full text search.
Donc tu peux faire aussi du search.
Et là, tu fais, wow, c'est...
c'est quoi, ce truc ?
Et donc, en fait, c'est... c'est là
où ils ont un argument marketing, où ils disent, voilà,
c'est la... la DB ultime.
Tu... tu fais tout avec.
Évidemment,
c'est sur le cloud.
Le gros avantage aussi, c'est que tu peux
l'auto héberger chez toi.
Donc tu peux l'héberger
sur ta machine.
Donc là, tu dis, wow, ça commence
intéressant. Tu peux mettre
ton layer de sécurité directement dans la DB.
OK.
Et...
tu veux faire du schéma.
C'est bien, tu donnes le schéma. Tu veux pas mettre de schéma.
Tu mets pas le schéma, c'est pas grave.
On prend le schéma à la volée. OK.
C'est à dire, tu cohéries
directement du navigateur, je vois là, sur le...
Exactement. Exactement.
C'est... c'est exactement ça.
C'est bye bye, bye bye les ORM.
Et limite, bye bye,
le back end.
Quoi? Quoi? Quoi? Quoi?
Bah ouais, en fait, c'est ton navigateur,
ton client front, qui va directement
taper... du coup.
C'est l'occasion de sortir
ta phrase favorite.
Ah oui!
Front is the new back.
Front is the new back, les gars. Évidemment.
Bon, j'ai pas mis le t-shirt aujourd'hui.
Mais... mais dans l'idée...
Tu peux directement faire des queries de ta web app
sur ta base de données. Ça, c'est quand même très fort.
Ouais.
J'imagine qu'il y a quand même des clés différents
entre la version client et la version de
back end.
Ou tu peux accéder que des lectures.
Après, il faut aller voir,
il faut creuser.
Mais en tout cas, c'est une fonctionnalité
qui sort. C'est puissant ça, très puissant.
Et pareil, ils disent
ok, tu veux... tu veux utiliser du GraphQL?
Vas-y. Du reste? Du WebSocket?
Ouais. Vas-y. Nous, on a...
On a les plugs pour...
On a les plugs pour faire ça.
Et ils ont fait quand même leur propre
langage de query qui s'appelle
SerilQL.
Donc Query Language.
Donc, qu'il aurait propre.
Et pareil, on met la petite sur couche
de...
de RealTime Live Query.
Donc, en clair,
quand ça rentre
d'un côté, BIM,
c'est mis à jour directement
de l'autre côté, quoi.
Mais oui.
Mais c'est la DB Ultimate, c'est...
C'est la DB Ultimate.
Et du coup, ils disent
mais tu sais quoi, tu veux...
Tu te prends pas la tête.
Ça...
Ça se cale dans...
Dans tous les sens, tout.
Toi, tu s'occupes de rien.
Nous, on s'occupe de tout, quoi.
Donc, non, c'est quand même
assez... assez puissant.
Et évidemment
du...
du Edge, enfin,
du WebAssembly, si tu veux
le porter toi-même quelque part.
BIM.
Tu peux intégrer ça directement dans...
Donc,
Clarence, c'est quelque chose
je pense qu'il faut surveiller.
Elle est pas mal, elle est pas mal.
Quel tarif, alors ?
Parce que là, c'est tellement...
C'est tellement beau que...
En plus, c'est un tarif intéressant.
Alors, ils ont un service...
Ils ont un service...
Cloud, par contre...
Et ça,
et celle-là, tu peux l'auto-héberger, surtout.
C'est ça, le terrain, quoi.
Oui, exactement. Ouais, tu peux...
Avec toutes les fonctions qu'ils annoncent là,
en auto-héberger, tu peux aussi avoir...
Alors, soit tu l'amais sur un docker
classique, soit tu l'amais
en natif, via
brouhours, enfin voilà,
tu l'installes, on va dire,
classique, quoi.
Par contre, le service
Cloud,
je sais pas...
Par contre, ils sont en
waiting list, tu vois. Donc, ils sont pas encore
ouverts, en total.
Donc, la question, c'est, est-ce que...
Par contre, je sais que ça fait
déjà un ou deux ans qu'ils sont
déjà dessus.
Ouais, tu vois, la Beta,
ça fait un dans July
2022. Par contre,
les gars, ils bossent dessus
depuis plus longtemps, j'ai vu...
J'ai vu sur la recherche,
j'ai vu ça.
Mais donc, ce qui est
intéressant, c'est quoi ?
Je pense que, là, en fait, il y a
une sorte d'agglomérin.
Est-ce que ça va prendre ?
Est-ce que c'est de la hype ?
Est-ce que, en fait,
la promesse que
SurilsDB fait,
est-ce qu'elle va vraiment être
honorée ? Ça, j'en sais rien.
Par contre, je pense que
pour... Ouais, si on est un peu curieux
et on a envie de
tester, c'est tout de
cette nouvelle fonctionnalité, clairement,
je pense que ça vaut vraiment le coup de jouer avec.
Ils sont encore en Beta.
Ils sont en V1, Beta, Beta.
Donc, ils sont proches de la version
1 finale. Donc, je pense que ça devrait
pas tarder à
sortir. Ils ont, évidemment,
tous les clients,
tous les SDK
qui vont bien et tout ça.
Donc, là, c'est super intéressant.
Ouais, et vraiment...
Et c'est là où
je pense qu'on va rentrer dans une nouvelle
éart de
SQL, des bases de données.
Je pense que la base de données classique
sur un docker
ou sur une machine
qu'on déberge nous-mêmes,
je pense qu'on va vite être limité
en termes de fonctionnalité. Ou alors, on va recoder
la roue et on va
réinventer le fil à couper le beurre.
Donc, c'est pas intéressant.
Je pense que ces nouvelles technologies
peuvent amener vraiment
un gain de productivité
hallucinant et surtout des
fonctionnalités super intéressantes.
Ouais, on est d'accord.
Après, il y a toujours une question de tarification.
Comme tout.
Il faut voir si c'est intéressant ou pas.
Après, est-ce que SurilDB
ne peut pas en faire trop, peut-être ?
Parce que ça fait quand même beaucoup
de choses disponibles. Alors, je me demande
si, à un moment donné, vous voulez tout faire, est-ce que c'est vraiment
la bonité ?
C'est exactement le truc.
C'est est-ce qu'ils sont en capacité
de vraiment faire
ce qui a marqué, tu vois,
est-ce qu'ils répondent à leurs promesses ?
Est-ce qu'ils vont vraiment, vraiment, répondre
à leurs promesses ou pas ?
Ou
comme beaucoup
dans la tech, quoi, il y a
une grosse partie de marketing,
de développeurs advocate et
de voilà
où on va vendre, on va peut-être
survendre la techno
derrière et
j'en sais rien,
j'ai pas ma boule de cristal. Par contre
sur le papier, ça a l'air pas mal.
Est-ce que c'est à maturité
pour passer en prod, je pense pas,
à titre personnel, je pense pas.
Par contre, je pense qu'il faut garder un oeil
dessus, parce que potentiellement
ça peut vraiment déboiter.
Si vraiment, ils arrivent à faire
tout ce qui est
annoncé.
La promesse, elle est assez forte.
Donc, à regarder,
à voir.
Bon, bon, bah écoute,
intéressant tout ça, on voit que
malgré tout le monde de la base
de données évolue et
de nouveaux services qui sortent, qui sont
intéressants, qui proviennent beaucoup de choses.
Donc, ça fait plaisir de voir
quelque chose qui n'est pas forcément toujours agréable au niveau
du développement, la base de données, les enquêtes,
query, tout ça, machin.
Donc, c'est cool, il y a des beaux services, surtout moi,
ce que je trouve génial, c'est le
système plan-scale avec
le versioning.
C'est ouf, hein.
Donc, ça donne envie de tester tout ça,
tu vois, tu as envie de
passer le dimanche à tester, tu vois.
Bien, carrément.
T'as quelque chose à rajouter encore ?
Bah écoute, non, non,
rien, je crois qu'on a fait le tour.
On a fait un peu
de rappel des fondamentaux
de l'ADB, et puis voilà,
et puis je pense qu'il faudra surveiller
tout ça. Et je
pense qu'on
sous-estime trop souvent,
en tout cas, moi qui
vient plutôt
du front et du back,
et c'est vrai que je viens pas,
j'ai sous-estimé trop souvent
les compétences en DB,
et je pense qu'on les sous-estime
trop, et on peut faire
beaucoup, beaucoup de choses
avec l'ADB, et
je pense que se former, ou
pousser un petit peu plus nos compétences
sur de la DB pure,
je pense que c'est pas
perdu.
C'est pas perdu.
Je suis pas perdu.
Bon, j'ai d'accord.
Bon, super. Merci Patrick.
Merci à toi.
Merci à tout le monde d'être restés
jusqu'au bout de l'épisode, et puis on vous dit à bientôt.
On se retrouve bientôt, ciao.
Ciao, ciao.
Retrouvez Double Slash
sur la plateforme de podcasts préférés,
et sur le site internet du podcast
www.slash-podcast.fr
Sur le site, vous allez retrouver
tous les liens de l'épisode, les références
évoquées durant l'émission.