PostgREST : un serveur web autonome qui fournit une API RESTful à partir de n'importe quelle BD PostgreSQL

Version imprimable

30/12/2022, 09h15
Bruno

1 pièce(s) jointe(s)

PostgREST : un serveur web autonome qui fournit une API RESTful à partir de n'importe quelle BD PostgreSQL

PostgREST : un serveur web autonome qui fournit une API RESTful à partir de n'importe quelle base de données PostgreSQL,
il permet de contourner les ORM

PostgREST est un serveur web autonome qui transforme votre base de données PostgreSQL directement en une API RESTful. Les contraintes structurelles et les permissions de la base de données déterminent les points de terminaison et les opérations de l'API.

Selon ses concepteurs, l'utilisation de PostgREST est une alternative à la programmation manuelle CRUD. Rappelons que l'acronyme informatique anglais CRUD (pour Create, Read, Update, Delete) désigne les quatre opérations de base pour la persistance des données, en particulier le stockage d'informations en base de données.

« PostgREST est performant, stable et transparent. Il nous permet d'amorcer des projets très rapidement et de nous concentrer sur nos données et notre application au lieu de construire la couche ORM. Dans notre cluster k8s, nous exécutons quelques pods par schéma que nous voulons exposer, et nous augmentons/réduisons en fonction de la demande. Nous ne pourrions pas être plus heureux », déclare Anupam Garg de Datrium, Inc.

Pièce jointe 631635

L'écriture de la logique métier entrave souvent la structure de la base de données. Le mapping objet-relationnel est une abstraction peu fiable qui conduit à un code impératif lent. La philosophie PostgREST établit une seule source déclarative de vérité : les données elles-mêmes.

PostgreSQL, un système de gestion de données connu pour sa fiabilité et sa robustesse, bénéficie de plus de 25 ans de développement open source par une communauté mondiale de développeurs. Il s’agit de l'un des systèmes de gestion des bases de données open source les plus avancés. Il est riche en fonctionnalités, avec des types de données robustes, une indexation puissante et un large éventail de fonctions intégrées que peuvent être utilisé pour simplifier la pile de données et permettre aux développeurs de se concentrer sur la création de son application.

Le PostgreSQL Global Development Group a annoncé le 13 octobre la sortie de PostgreSQL 15, qui s'appuie sur les améliorations de performance des versions récentes avec des gains notables pour la gestion des charges de travail dans les déploiements locaux et distribués, notamment un tri amélioré. Une version aui améliore également l'expérience du développeur avec l'ajout de la populaire commande MERGE.

Programmation déclarative

Il est plus facile de demander à PostgreSQL de joindre des données pour vous et de laisser son planificateur de requêtes s'occuper des détails que de parcourir vous-même les lignes en boucle. Il est plus facile d'attribuer des permissions aux objets de la base de données que d'ajouter des mécanismes de protection dans les contrôleurs. (C'est particulièrement vrai pour les permissions en cascade dans les dépendances de données.) Il est plus facile de définir des contraintes que d'alléger le code avec des contrôles d'intégrité.

PostgREST a une portée ciblée. Il fonctionne bien avec d'autres outils comme le serveur web Nginx. Cela oblige à séparer proprement les opérations CRUD centrées sur les données des autres préoccupations.

« J'aime le fait que PostgREST ne fait qu'une chose, et une chose bien. Alors que PostgREST se charge de combler le fossé entre notre serveur HTTP et la base de données PostgreSQL, nous pouvons nous concentrer sur le développement de notre API dans un seul langage : SQL. Cela place la base de données au centre de notre architecture, et nous a poussé à améliorer nos compétences en programmation SQL et en conception de bases de données », Eric Bréchemier, ingénieur données, eGull SAS.

Avec PostgREST, aucun ORM (Object-Relational Mapping) n'est impliqué. La création de nouvelles vues se fait en SQL, avec les conséquences connues sur les performances. Un administrateur de base de données peut désormais créer une API à partir de rien, sans une programmation personnalisée.

L’ORM est un type de programme informatique qui se place en interface entre un programme applicatif et une base de données relationnelle pour simuler une base de données orientée objet. Ce programme définit des correspondances entre les schémas de la base de données et les classes du programme applicatif.

Voici, ci-dessous, quelques avis sélectionnés par l’équipe en charge de PostgREST :

« Je dois juste dire que l'utilisation du CPU et de la mémoire par rapport à notre API basée sur Node.js/Waterline ORM est ridicule. Il est même difficile de la pousser au-delà de 60/70 Mo alors que notre API actuelle atteint constamment 1 Go en fonctionnant sur 6 instances (dynos) », Louis Brauer.

« J'ai vraiment apprécié le fait que, tout à coup, j'écrivais des microservices en SQL DDL (et en fonctions JavaScript v8). J'ai évité tellement de textes passe-partout. L'instant d'après, nous avons réécrit entièrement une application Spring+MySQL en 6 mois. Littéralement 10x plus rapide, et le code était super concis. L'ancienne application avait nécessité 3 ans et une équipe de 4 personnes pour la développer », Simone Scarduzio.

:fleche: Mettre en place une API RestFull depuis n'importe quelle base de données PostgreSQL

Source : PostgREST

Et vous ?

:fleche: Que pensez-vous de PostgREST ? L'avez vous déjà utilisé ?

:fleche: Peut-on considérer PostgREST comme une plus-value pour PostgreSQL ? Sinon, connaissez-vous des similitudes dans d'autres SGBD ?

Voir aussi :

:fleche: PostgreSQL 15 est disponible, elle améliore de l'ordre de 25 % à 400 % ses algorithmes de tri en mémoire et sur disque, et apporte la populaire commande MERGE

:fleche: PostgreSQL : Supabase annone la mise en libre accès de Postgres-wasm, un serveur PostgreSQL qui fonctionne dans un navigateur

:fleche: IvorySQL : un PostgreSQL open source compatible avec Oracle, pourrait répondre au besoin de migrer des applications Oracle vers l'open source Postgres
30/12/2022, 11h53
Anselme45

Nous utilisons PostgREST depuis pas mal de temps et il faut dire que la solution est très efficace et particulièrement stable.

Nous avions une solution basée sur Posgtresql que l'on a décidé de transformer en solution Cloud.

Nous avons simplement ajouté une couche REST à l'aide de PostgREST sans avoir à changer un bit dans la base de données d'origine.

Avec plusieurs clients utilisant notre plateforme Cloud depuis plus d'une année, nous n'avons pas eu un seul problème avec PostgREST.

Par contre pas d'avis sur la dernière version annoncée parce que pas encore testée.
30/12/2022, 12h05
micka132

J'ai du mal à comprendre l'avantage de la couche Rest.
Je vois bien le gain d'exécution à avoir directement la sérialisation en JSON, mais j'ai un peu plus de mal à avoir l'appel direct aux données. Intuitivement ça va à l'encontre des bonnes pratiques en vigueur, mais bon j'ai bien conscience que les bonnes pratiques d'hier ne seront plus celles de demain (#fashion).
Par contre là ou j'ai une grosse interrogation c'est sur l'utilité d'avoir du REST. Quel avantage par rapport à un une requête SQL directement dans un POST ?
C'est un peu comme s'il fallait encore se farcir un nieme pseudo language (comme https://www.odata.org/), alors qu'ici on pourrait clairement avoir la requête directement.
Au delà de ça comment sont gérés les requêtes légitimes du pirate qui veut accéder à n'importe quoi?
30/12/2022, 12h26
Anselme45

Citation:

Envoyé par micka132

Par contre là ou j'ai une grosse interrogation c'est sur l'utilité d'avoir du REST. Quel avantage par rapport à un une requête SQL directement dans un POST ?
C'est un peu comme s'il fallait encore se farcir un nieme pseudo language (comme https://www.odata.org/), alors qu'ici on pourrait clairement avoir la requête directement.

Tu t'évites déjà à devoir faire appel à des driver X ou Y pour permettre la connexion entre le client et la base de données!!! Je peux te dire que lorsque tu as un système hétérogène avec des clients développés pour différentes plateformes et différentes plateformes qui doivent se connecter à ta base de données, c'est un vrai plaisir de remplacer un douzaine de drivers différents (souvent développés par des sociétés tierces dont tu es dépendant) par du REST pour tout le monde.

Le plus souvent avec ces drivers les échanges de données se font en clair. Avec REST, tu peux sécuriser ton échange de données.

Citation:

Envoyé par micka132

Au delà de ça comment sont gérés les requêtes légitimes du pirate qui veut accéder à n'importe quoi?

REST n'est que le mode de communication. Ce n'est pas parce que tu utilises REST qu'il faut concevoir sa base de données n'importe comment et en faire un "moulin" ouvert à tous les hackers!
30/12/2022, 13h44
micka132

Citation:

Envoyé par Anselme45

Tu t'évites déjà à devoir faire appel à des driver X ou Y pour permettre la connexion entre le client et la base de données!!!

Tu sembles confondre REST et service web (et même peut-être plus largement avec serveur).
Ma question ne concerne que l'intérêt d'avoir un pseudo langage de requête au lieux de fournir à ce service web directement la requête SQL via POST.

Peut-être est-ce que ça à voir avec la sécurisation de ma 2eme question.

Citation:

Envoyé par Anselme45

Ce n'est pas parce que tu utilises REST qu'il faut concevoir sa base de données n'importe comment et en faire un "moulin" ouvert à tous les hackers!

La conception de la BDD n'a pas grand chose à voir dans la sécurisation. Ma question est comment tu empeches le hacker de faire un select * from user, dès lors que l'utilisateur qu'utilise PostgREST pour se connecter à Postgres à bien le droit de le faire.
30/12/2022, 13h58
Shepard

Citation:

Envoyé par micka132

La conception de la BDD n'a pas grand chose à voir dans la sécurisation.

Comment ça ? 8O

Lors de la conception de ta BDD, tu es sensé créer les rôles/logins qui vont avec et les attribuer aux bonnes personnes. La gestion des droits est tout un pan des SGBDR (principalement via GRANT/REVOKE mais aussi avec les row-level-access-control par exemple). Toute personne qui se connecte à une base de données correctement conçue avec le rôle qui lui est attribué peut normalement exécuter n'importe quelle requête SQL sans compromettre la sécurité et les données des autres utilisateurs.

Maintenant la prudence recommande de ne pas donner directement accès à l'interface SQL aux utilisateurs. Et du coup effectivement présenter des procédures stockées/vues via PostgREST est de mon point de vue mieux que passer des commandes SQL directement via un service REST.

D'un point de vue architectural également, le client n'a pas à savoir que le service REST utilise du SQL, ce qui permet au responsable du service REST de passer un jour à une autre technologie sans affecter les utilisateurs de son service.
30/12/2022, 17h04
ji_louis

Citation:

Ma question est comment tu empeches le hacker de faire un select * from user, dès lors que l'utilisateur qu'utilise PostgREST pour se connecter à Postgres à bien le droit de le faire.

En utilisant une procédure stockée que le DBA (responsable de la base de données) aura calibré, ce n'est pas une requête SQL qui passe par le réseau (si c'est cela qui t'inquiète) mais quelque chose du style :

Code:

nom_procedure(critere1, critere2, etc)

C'est ça qui passe par PostgREST. Du côté de la base de donnée, la procédure stockée aura une requête paramétrée du style (pour les plus simples en lecture):

Code:

select * from ? where ? group by ...

Mais c'est habituellement beaucoup plus chiadé parce que tu y inclus les règles de sécurité et les règles de gestion de l'application de manière totalement invisible pour le client.

J'utilisais déjà cette manière de faire il y a 25 ans, c'est solide, efficace et simple, surtout quand on bosse avec des intervenants extérieurs..
31/12/2022, 12h23
Anselme45

Citation:

Envoyé par micka132

Tu sembles confondre REST et service web (et même peut-être plus largement avec serveur).
Ma question ne concerne que l'intérêt d'avoir un pseudo langage de requête au lieux de fournir à ce service web directement la requête SQL via POST.

Peut-être est-ce que ça à voir avec la sécurisation de ma 2eme question.

La conception de la BDD n'a pas grand chose à voir dans la sécurisation. Ma question est comment tu empeches le hacker de faire un select * from user, dès lors que l'utilisateur qu'utilise PostgREST pour se connecter à Postgres à bien le droit de le faire.

Je ne confonds rien par contre je peux te dire que ton commentaire démontre que tu ne connais pas ce que tu te proposes de commenter. On ne peut pas tout connaître mais il est toujours utile de rester humble quand on pose des questions dans un domaine où l'on n'excelle pas. Cela évite de passer pour un "coui...on".

Amitié et tous mes voeux de bonne année pour 2023! :chin:
02/01/2023, 12h17
la-source
Je trouve cette librairie extrêmement passionnante, cependant, après une lecture attentive de leur documentation, je reste perplexe sur la couverture de l'ensemble des cas d'usage d'une API.

Plus particulièrement, imaginons une facture et ses lignes de facture, c'est un ensemble cohérent et dans une API Rest on souhaiterait, lors d'un ajout, pouvoir enregistrer l'ensemble d'une traite en faisant quelque chose du style:
Code:

1 2 3 4 5 6 7 8 9 10 11 { "number": 4, "date": "2011-10-05T14:48:00.000Z", "lines": [ { "quantity": 1, "product": "Product 1", "price": 2.3 } ] }
Comment faire avec PostgREST ? la seule façon que je vois est de réaliser 2 requêtes, une première pour la facture et une seconde avec les lignes de détail, ce qui me gène c'est que si je souhaite réaliser un traitement tel que l'envoi de la facture par mail, j'avais dans l'idée de faire un LISTEN / NOTIFY dans l'application backoffice (pour éviter de devoir faire appel à une autre API une fois la facture enregistrée). La seule méthode que je vois serai donc d'avoir une colonne status qui devrait, une fois les lignes de détail enregistrées, être modifiée (troisième requête) pour pouvoir réaliser une action à cette modification.

Je trouve que cela est un peu dommage.
02/01/2023, 14h14
Anselme45

Citation:

Envoyé par la-source

Je trouve cette librairie extrêmement passionnante, cependant après une lecture attentive de leur documentation je reste perplexe sur la couverture de l'ensemble des cas d'usage d'une API.

Plus particulièrement, imaginons une facture et ces ligne de facture, c'est un ensemble cohérent et dans une API Rest on souhaiterai lors d'un ajout pouvoir enregistrer l'ensemble d'une traite en faisant quelque chose du style:

...

Comment faire avec PostgREST ?

Ah bon? On ne doit pas vivre dans le même monde! :mur:

La solution est simplissime et en une seule requête, tu peux faire des choses bien plus compliquée!!!

Une fonction codée dans la base de données Postgresql que tu appelles via PostgREST!!! Et la fonction en question va te retourner un une seule requête l'info sous la forme que tu veux, sous forme de tableau, sous forme de document JSON, etc...
05/01/2023, 12h10
micka132

Citation:

Envoyé par Anselme45

Je ne confonds rien par contre je peux te dire que ton commentaire démontre que tu ne connais pas ce que tu te proposes de commenter. On ne peut pas tout connaître mais il est toujours utile de rester humble quand on pose des questions dans un domaine où l'on n'excelle pas. Cela évite de passer pour un "coui...on".

Effectivement, quand on pose une question, c'est qu'on ne connait pas.
En revanche ta réponse avec les drivers, qui n'a absolument ni de près ni de loin, un quelconque rapport avec les avantages spécifiques de REST, ne laisse pas supposer que tu maitrises le sujet, tout en utilisant le produit. Perso ça me fait peur.
Je te signales, qu'en tant qu'utilisateur, tu n'as toujours pas était capable de répondre à ma question de l'intérêt de REST, à la place de l'utilisation d'un simple POST. Je ne prétends pas qu'il n'y a pas d'avantage, je pose la question pour qu'un expert puisse me répondre...S'il n'y en a pas (d'expert, ou d'avantage) c'est pas bien grave!
05/01/2023, 12h33
micka132

Citation:

Envoyé par ji_louis

En utilisant une procédure stockée que le DBA (responsable de la base de données) aura calibré

Merci pour la réponse,
Mais est-ce une solution, ou c'est LA solution ?
Là au final si je comprends bien ta proposition, tu vas devoir faire des procédures stockées "métiers" dont certaine vont par exemple être à base de jointure.
Mais alors à quoi sert le système de requêtage que propose PostgREST ? De faire des joins sur les résultats des procédures stockées (me semble peu performant)?

Par ailleurs, je n'ai rien contre les procédures stockés, c'était extrêmement à la mode il y a 20 ans, beaucoup moins (voire totalement ringard) ces dernières années, est-ce que ce PostgRest est une proposition pour faire revenir sur le devant de la scène les "procstock" ?
14/01/2023, 11h49
Anselme45

Citation:

Envoyé par micka132

Par ailleurs, je n'ai rien contre les procédures stockés, c'était extrêmement à la mode il y a 20 ans, beaucoup moins (voire totalement ringard) ces dernières années, est-ce que ce PostgRest est une proposition pour faire revenir sur le devant de la scène les "procstock" ?

Tu as raison micka132, aujourd'hui la mode est au cloud piratable qui permet de vendre les données volées sur le darknet grâce à l'usage de technologies à la mode que personne n'a pris la peine de fiabiliser...

Mais pourquoi donc faudrait-il revenir en arrière avec des technologies bien plus sûres?
14/01/2023, 11h54
Anselme45

Citation:

Envoyé par micka132

Effectivement, quand on pose une question, c'est qu'on ne connait pas.
En revanche ta réponse avec les drivers, qui n'a absolument ni de près ni de loin, un quelconque rapport avec les avantages spécifiques de REST, ne laisse pas supposer que tu maitrises le sujet, tout en utilisant le produit.!

Est-ce que tu as déjà développé une application "client-serveur" dans ta vie? A la lecture de tes commentaires hautains, j'en doute!

Si c'était le cas, tu aurais connaissance des différentes méthodes et architectures utilisées pour le faire...

Mais, je ne vais pas ergoter plus longtemps, le ton condescendant que tu prends dans tes commentaires ne donne pas envie de converser avec toi.