Discussion :

[Bruno]

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.

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

[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.

[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?

[Anselme45]

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.

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!

[micka132]

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.

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.

[Shepard]

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.

[ji_louis]

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 - Visualiser dans une fen�tre � part

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 - Visualiser dans une fen�tre � part

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

[Anselme45]

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!

[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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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.

[Anselme45]

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

[micka132]

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!

[micka132]

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" ?

[Anselme45]

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?

[Anselme45]

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.