MongoDB

#JaiDécouvert que wal-g ne se limite pas au support de PostgreSQL : il prend également en charge MySQL, MS SQL Server, et ajoutera bientôt le support de MongoDB et Redis.

WAL-G is an archival restoration tool for PostgreSQL, MySQL/MariaDB, and MS SQL Server (beta for MongoDB and Redis).

-- from

Je rassemble ici quelques notes au sujet de projet Hasura.

À l'origine, Hasura était uniquement un moteur GraphQL open-source qui se branchait directement sur une base de données PostgreSQL. Le projet a commencé en 2018, bien que le site web soit plus ancien — 2015.
D'après le dépôt GitHub, les premiers développeurs d'Hasura sont Shahidh K Muhammed, Vamshi Surabhi, Aravind Shankar et Rakesh Emmadi, tous basés à Bangalore, en Inde.

En 2019, dans un cadre professionnel, j'ai choisi d'utiliser un autre moteur GraphQL : PostGraphile.

Début 2020, j'avais également identifié Hasura et Supabase comme alternatives.

J'avais choisi d'utiliser PostGraphile pour plusieurs raisons :

• Supabase était encore un jeune projet, lancé en octobre 2019.
• Hasura était codé en Haskell, un langage que je ne maîtrise pas. En revanche, PostGraphile, développé en JavaScript, m'inspirait plus confiance, car je savais que j'avais les compétences nécessaires si je devais intervenir sur son code source, par exemple, pour corriger un bug.
• D'autre part, PostGraphile n'était pas financé par des Venture capital, ce qui m'inspirait bien plus confiance sur son avenir que Supabase et Hasura.
• J'apprécie énormément la façon de travailler de Benjie. J'apprécie sa manière d'organiser ses projets, ses documentations et ses choix techniques. Je pense que notre doctrine est assez similaire.

Quatre plus tard, je constate que PostGraphile a choisi de rester concentré sur un seul objectif : être un moteur GraphQL, tandis que Supabase et Hasura, bénéficiant d'un financement par des Venture capital, ont diversifié leurs offres.

Alors que PostGraphile se limite au support de PostgreSQL, Hasura peut se connecter à Mysql, MongoDB, Clickhouse, Elasticsearch…
Et d'après la documentation, Hasura permet d'exposer, en plus d'une API GraphQL, une API REST (RESTified Endpoints).

Quel est mon rapport aux langages typés ?

Pour bien comprendre mon approche des langages typés, il est utile de revenir sur mon parcours.

Enfant, j'ai commencé par du Locomotive Basic (non typé), j'ai ensuite fait beaucoup de Turbo Pascal (typé) et un peu de C, C++ (typé).

À cette époque, je préférais les langages typés pour des raisons de performances.

En 2000, j'ai vraiment aimé utiliser à nouveau des langages non typés, comme PHP et surtout Python qui a été pendant très longtemps mon langage de prédilection.

J'ai à nouveau beaucoup pratiqué un langage typé de 2013 à 2018 : Golang.

Aujourd'hui, je considère qu'il est souvent plus facile et plus rapide de programmer dans un langage non typé, notamment grâce au Duck Typing. Cependant, je reconnais que les langages typés offrent des avantages indéniables, notamment en matière de refactoring de code.

Je pense qu'il est préférable d'utiliser un langage typé sur un projet critique.

Je pense qu'il est préférable d'utiliser un langage typé pour les programmes qui manipule des données complexes et divers.
C'est, par exemple, pour cela que ne suis pas un utilisateur de MongoDB. Je préfère une base de données PostgreSQL où tout est bien typé.

Il ne me viendrait pas à l'esprit d'implémenter une base de données ou un moteur web dans un langage non typé.

Par contre, je suis moins convaincu par l'utilisation d'un langage typé pour les applications d'interface utilisateur lourde ou web.

Lorsqu'une équipe de développement travaillant sur un code commun atteint une certaine taille — je n'ai aucune idée de ce nombre — je suis convaincu qu'il devient préférable d'utiliser un langage typé.