Aller au contenu
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERPartager un flux
POURDevs backend
POURÉquipes de devs
SERVICESPipe
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERPartager un flux
POURDevs backend
POURÉquipes de devs
SERVICESPipe
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERPartager un flux
POURDevs backend
POURÉquipes de devs
SERVICESPipe
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERPartager un flux
POURDevs backend
POURÉquipes de devs
SERVICESPipe
POURQUOI HOODYHTTP-natif
PIPE · STREAMS PARTAGÉS · POSTGRES

Envoyez à un coéquipier l'état d'une base en une ligne

Un coéquipier tombe sur un bug que vous n'arrivez pas à reproduire. Sautez le fichier. Le pg_dump sur votre laptop streame directement dans son psql sur staging — pas d'upload, pas de lien, pas de download. Le pipe route les bytes.

Lire la doc Pipe API

Un chemin pipe. Deux curls. Aucun fichier intermédiaire.

L'API Hoody Pipe garde un pipe non établi pendant cinq minutes en attendant que l'autre côté se connecte. Quand vous êtes tous deux connectés, les bytes streament à travers. Rien n'est jamais écrit sur disque côté serveur.

pipe.containers.hoody.com/dev-snapshot
PUT · SENDERvous · dev

Streame le dump hors de pg_dump

# depuis votre laptop devpg_dump --format=custom dev \  | curl -T - \      https://pipe.containers.hoody.com/api/v1/pipe/dev-snapshot[INFO] En attente de connexion d'un destinataire…[INFO] Diffusion vers 1 destinataire…[INFO] Transfert terminé.

PUT (ou POST) avec un body en stream. Le serveur affiche des messages de statut sur votre terminal pendant que le pipe s'établit — utile pour voir quand l'autre côté s'est réellement connecté.

GET · RECEIVERcoéquipier · staging

Tire le dump direct dans psql

# sur leur shell stagingcurl https://pipe.containers.hoody.com/api/v1/pipe/dev-snapshot \  | pg_restore -d staging# rows importées · staging égale dev

GET sur le même chemin bloque jusqu'à ce que le sender se connecte. Les bytes que le sender écrit apparaissent comme corps de la réponse. Pipe vers pg_restore (ou psql) et le dump atterrit dans la base directement — jamais un fichier.

n=1 · fan-out par défautle pipe attend jusqu'à 5 minutes0 bytes stockés sur le serveur

Si vous voulez suivre la progression sans consommer un slot de receiver, pointe un troisième curl sur le même chemin avec ?progress et vous obtenez un dashboard HTML live affichant bytes transférés, vitesse et ETA.

À quoi ça ressemble en temps réel

Les quatre mouvements qu'il faut pour amener une DB dev sur le staging de votre coéquipier sans rien faire toucher au disque d'un serveur.

Message Slack → DB restauréeQUATRE ÉTAPES · UN PIPE
10:14 · BUG REPORT01

Coéquipier ne reproduit pas

« vous pouvez m'envoyer votre db dev ? »

Hier ça aurait voulu dire pg_dump, bucket S3, URL présignée et un collage Slack.

10:14 · PUT02

vous streamez le dump dehors

pg_dump dev | curl -T - …/pipe/dev-snapshot

votre terminal affiche « Waiting for 1 receiver to connect… » et reste là. Aucun fichier n'est créé localement non plus.

10:15 · GET03

Coéquipier lance le receiver

curl …/pipe/dev-snapshot | pg_restore

Le pipe s'établit dès qu'ils se connectent. Les bytes commencent à circuler de votre pg_dump direct dans leur pg_restore.

10:18 · DONE04

Staging égale dev

Transfer complete · 0 bytes sur le serveur

L'usage disque côté serveur reste à zéro. Le chemin pipe oublie que le transfert a eu lieu dès que les deux côtés se déconnectent.

Pourquoi un chemin bat un fichier

C'est le même nombre de commandes que vous taperiez pour un round-trip S3 — moins le bucket, le credential, l'upload, le download et le cleanup.

AUCUN STOCKAGE

Le serveur ne tient jamais les bytes

Hoody Pipe est un intermédiaire de stream, pas un service de fichiers. Le dump existe sur votre disque et sur le leur ; entre les deux, ce sont juste des bytes en vol. Rien à nettoyer, rien à fuir.

PAS DE GROS FICHIERS

La taille est bornée par le pipe, pas par la RAM

Pas de barre de progression d'upload à surveiller parce qu'il n'y a pas d'upload. Un dump de 40 GB circule à la vitesse que votre réseau et le pg_restore de votre coéquipier peuvent soutenir — le pipe forwarde, c'est tout.

OBSERVABLE

Ajoutez ?progress pour un dashboard live

Ouvrez le même chemin avec ?progress sur une troisième URL et observez les bytes transférés, la vitesse et l'ETA en temps réel. Jusqu'à 50 spectateurs par pipe, aucun ne consomme de slot de receiver.

L'état d'une base était une pièce jointe. Maintenant c'est un chemin.

Les fichiers sont du state au repos. Les chemins sont du state en mouvement. Le Hoody Pipe permet à un snapshot de base d'être le second — adressable, éphémère, et jamais posé sur un serveur que vous devez nettoyer plus tard.

  • pas d'upload
  • pas de download
  • aucun lien à partager

Ce que ça remplace

La plupart des outils utilisés pour partager une base dev sont des reliques de l'époque où on ne pouvait pas streamer des bytes entre deux terminaux en HTTP. Le pipe les rend tous inutiles.

  • AWS S3 + URL présignéeUn bucket, un credential, un upload et un lien de 24h
  • Dropbox / Google DriveSign-in, partage manuel, attendre la sync
  • Uploads de fichiers SlackPlafond 30 MB, puis « utilisez un vrai lien »
  • Services type WeTransferEmail obligatoire, pages de pub, fenêtres de rétention mystères
  • Workarounds dblink PostgresOuvrir un port sur dev pour que staging tire les rows en live
  • rsync via bastion SSHDeux clés SSH, un jump host et un fichier temporaire à chaque bout

Deux curls. Un chemin. Leur staging égale votre dev.

Lire le guide Pipe API

Lis les autres