IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bruno

61PARTAGES

14  0 
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.


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.

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

Source : PostgREST

Et vous ?

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

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

Voir aussi :

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

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

IvorySQL : un PostgreSQL open source compatible avec Oracle, pourrait répondre au besoin de migrer des applications Oracle vers l'open source Postgres

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Shepard
Membre expérimenté https://www.developpez.com
Le 30/12/2022 à 13:58
Citation Envoyé par micka132 Voir le message
La conception de la BDD n'a pas grand chose à voir dans la sécurisation.

Comment ça ?

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.
6  0 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 30/12/2022 à 11:53
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.
5  0 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 30/12/2022 à 12:26
Citation Envoyé par micka132 Voir le message

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 Voir le message

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!
5  0 
Avatar de ji_louis
Membre régulier https://www.developpez.com
Le 30/12/2022 à 17:04
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 : Sélectionner tout
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 : Sélectionner tout
 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..
3  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 30/12/2022 à 12:05
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?
2  2 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 31/12/2022 à 12:23
Citation Envoyé par micka132 Voir le message
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!
1  1 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 02/01/2023 à 14:14
Citation Envoyé par la-source Voir le message
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!

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...
1  1 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 14/01/2023 à 11:49
Citation Envoyé par micka132 Voir le message

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?
0  0 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 14/01/2023 à 11:54
Citation Envoyé par micka132 Voir le message
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.
0  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 30/12/2022 à 13:44
Citation Envoyé par Anselme45 Voir le message
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 Voir le message
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.
1  2