Fast jeder von uns kennt sicherlich Postman Ein sehr mächtiger API-Client der schon einen gewissen Industriestandard bildet. API Definitionen lasse sich dort veröffentlichen und Collection mit Beispiel-Requests leicht teilen.
Das ist schön, allerdings geht man bei Postman immer mehr den Weg, dass die Software eine reine SaaS Lösung wird (oder schon ist?).
Da ich eine Vorliebe für Open Source und Self-Hosting habe, war mir die fehlende Kontrolle ein Dorn im Auge. Es geht auch darum, dass man sich bewusst ist was man da eigentlich macht. Im folgende Blog-Post geht es darum, wie wir wieder die die Kontrolle zurückbringen können! Bruno ist dann ein Tool, dass hier hilft.
Die Rückkehr der Kontrolle
Wir leben in einer Zeit, in der viele Entwickler ihre Tools in der Cloud betreiben. Dabei liegt oft eine riesige Menge an sensiblen Daten in den Händen von Dritten. Postman ist ein beliebter API-Client, der viele nützliche Funktionen bietet, aber die Tatsache, dass dort auch die Zugangsdaten und API-Schlüssel gespeichert werden, kann für viele Entwickler ein Albtraum sein. Bruno hingegen verfolgt einen anderen Ansatz: Es wird lokal ausgeführt und hilft dir, deine Daten in der Hand zu behalten. Es gibt keinen Cloud-Zwang (da es keine Cloud gibt), und das kann auch ein riesiger Vorteil sein!
Anmerkung: Falls ihr als Team lieber einen Server betreiben wollt, dann ist vielleicht noch das Tools Hoppscotch interessant.
Stell dir vor, du arbeitest an einem Projekt und legst sensitive Daten in die Cloud. Die Frage, wer Zugriff darauf hat und wie sicher diese Daten sind, lässt dich wahrscheinlich nicht ruhig schlafen. Bruno löst dieses Problem, indem du alle Collections als GIT Repository ablegen kannst. Requests und Environments werden als einfache Dateien gespeichert, die versioniert werden können. Das bedeutet, du hast immer die volle Kontrolle über deine API-Interaktionen.
Beispiel Dateibaum:
.
├── environments
│ ├── ddev.bru
│ └── production.bru
├── GraphQL
├── REST
│ ├── assets
│ ├── collections
│ ├── forms
│ ├── globals
│ ├── navs
│ ├── taxonomies
│ ├── users
│ ├── folder.bru
│ └── test.bru
├── 'REST private'
│ ├── Collections
│ ├── Entries
│ ├── Taxonomies
│ ├── Users
│ └── Ping.bru
├── bruno.json
└── collection.bru
Eine .bru Datei ist leicht versionierbar.
Hier sieht man warum das so ist:
meta {
name: List Articles (id, title, date)
type: http
seq: 1
}
get {
url: {{rest_api_private_base}}/collections/articles/entries?page=1&limit=10&fields=id,title,date
body: none
auth: inherit
}
params:query {
page: 1
limit: 10
fields: id,title,date
}
Die fehlende Cloud-Synchronisation wird durch das für Entwickler bekannte GIT pull/push ersetzt.
Postman selbst bietet das Arbeiten in Teams (>3 Personen) nur in der kostenpflichtigen Version an. Mit Bruno steht einer Team-Arbeit also keine fehlende Lizenz im Weg.
Einige Teams die mit Postman arbeiten, haben die Collections regelmäßig exportiert und in lokale Workspaces wieder importiert. Das ist fehleranfällig da man gerne mal eine veralteten Export einer Collection importiert hatte. Dank GIT passiert so etwas bei Bruno nicht. Und falls doch mal was kaputt ist, dann hilft GIT eine alte Version wiederherzustellen.
Sicherheit durch .env Dateien
Ein weiteres Highlight ist, dass Bruno die Möglichkeit bietet, Credentials in .env Dateien auszulagern. So können sensible Informationen nicht nur sicher gespeichert, sondern auch von der Versionierung ausgeschlossen werden. Das ist besonders wichtig, um zu verhindern, dass solch sensiblen Daten versehentlich in ein öffentliches Repository gelangen. Hier hilft eine einfach .gitignore Datei dies zu verhindern.
Um das nicht zu vergessen habe ich mir ein kleines Bash-Script gebaut:
#!/bin/bash
if [ ! -f "bruno.json" ]; then
echo "run this command in the directory of the bruno collection"
exit 1;
fi
# Create .env.sample only if it does not exist
if [ ! -f ".env.sample" ]; then
touch .env.sample
fi
# Create .env only if it does not exist
if [ ! -f ".env" ]; then
touch .env
fi
# Create .gitignore if it does not exist
if [ ! -f ".gitignore" ]; then
touch .gitignore
fi
# Check if ".env" is already in .gitignore before adding it
if ! grep -q "^\.env$" .gitignore; then
echo ".env" >> .gitignore
fi
# Initialize git only if the .git directory doesn't exist
if [ ! -d ".git" ]; then
git init --initial-branch=main
fi
in einer .env Datei können dann die Credentials abgelegt werden:
MY_PASSWORD=super-geheimes-passwort
Die Variablen kann dann in einem Environment einfach referenziert werden.
{{ process.env.MY_PASSWORD }}
In Bruno können nun die Variablen (muss kein Secret) sein direkt integriert werden. Hier seht ihr ein Beispiel mit Vererbung von Variablen.
REST, GraphQL, ...
In Postman kann man ganz hervorragend mkt REST und GraphQL Schnittstellen kommunizieren und diese auch sehr gut konzipieren.
Kann Bruno hier mithalten?
Ehrlicherweise ist Postman hier noch etwas vorraus. Das betrifft aus meiner Sicht überwiegend den GraphQL Client der sehr komfortable ist. Das bedeutet aber nicht, dass Bruno hier nichts kann. Bruno beherscht es auch ein GraphQL Schema zu laden und eine entsprchende Autovervollständigung anzubieten. Auch kann eine Doku des geladenen Schema angezeigt werden. Man kann auch direkt aus de, Graphl Query Editor an die richtige Stelle in der Doku springen.
Habt ihr schon einmal eine native GraphQL Collection in Postman angelegt und versucht diese zu exportieren? Falls der Export-Link fehlt, dann habt ihr keine kostenpflichtige Team Funktion. Das teilen von GraphQL Collection ist nur noch über die Team Synchronisation möglich.
Bei Anfragen an eine REST Schnittstelle finde ich es wichtig, dass ich z.B. Variablen im Pfad verwenden kann. Das wird inzwischen von Bruno gut unterstützt. Hier fehlt mir auf den ersten Blick nicht viel. Wo Postman noch die Nase vorne hat ist u.a. der Bereich des API Design und andren Schnittstellen Arten. So fehlt in Postman gerade noch die Unterstützung von gGRPC, WebSockets, Socket.IO, MQTT.
Flexibles Skripten und eine schnelle UI
Ein weiterer Vorteil von Bruno ist die Möglichkeit, JavaScript-Code innerhalb der Collection auszuführen. Das bedeutet, dass du deine Tests und API-Interaktionen flexibel gestalten kannst.
Im Gegensatz zu Postman kannst du sogar NPM Pakete in deiner Collection installieren. Diese Funktion, die du durch einen einfachen Klick im "Safe Mode" aktivieren oder deaktivieren kannst, eröffnet ganz neue Möglichkeiten für die Automatisierung und Flexibilität deiner API-Tests.
Hier hat man wieder selbst die Kontrolle da alles auf der lokalen Maschine stattfindet. Kein Cloud-Anbieter verbietet mir die Installation eines nützlichen Pakets.
Collections lassen sich in Bruno in der Benutzeroberfläche hinzufügen und auch wieder entfernen. Das wirkt auf den ersten Blick banal, hilft aber die Performance der UI hoch zu halten.
Wer viele Collections hat, muss diese nicht alle gleichzeitig in der UI vorhalten.
API Tests
Auch das Erstellen von Assets und richtigen API Tests ist in Bruno möglich. Die API Tests können auch über einen CLI Runner ausgeführt werde.
Im Bildschirmfoto sieht man einen einfachen Test-Case mit Javascript. Ihr könnt hier aber auch deutlich komplizierte Tests erstellen.
Für diesen einfachen Test hätte man auch die Assert-Funktion nutzen können.
Ein Blick in die Zukunft
Ein weiterer wichtiger Aspekt von Bruno ist, dass die Entwickler aus Indien bewusst darauf abzielen, die Features immer mit dem Fokus auf Entwickler zu erstellen. So gibt es keine Fokus auf dem Thema API Monitoring da man hier in der Regel eine Cloud-Plattform braucht.
Aber die Entwickler hinter Bruno müssen doch irgendwie Geld verdienen?
Zur Finanzierung des Unternehmens hinter Bruno, gibt es eine eine kostenpflichtige Version, die zusätzliche Funktionen wie einen integrierten GIT-Client bietet. Auch eine Enterprise Version für große Unternehmen die z.B. eine Auslagerung der Secrets in ein Vault bietet ist zum Geld verdienen als Angebot vorhanden.
Wichtig ist jedoch, dass die grundlegenden Funktionen alle in der kostenfreien und auch quelloffene Version bleiben – das ist ein echter Gewinn für die Open Source Community!
Die Entwickler haben zudem ein Manifest veröffentlicht, das die Grundwerte der Softwareentwicklung festhält. Es soll verhindert werden, dass externe Investoren die Kontrolle über das Projekt übernehmen und daraus eine Cloud-Lösung machen. Bruno bleibt ein lokales Tool, das den Bedürfnissen der Entwickler dient und nicht der Profitmaximierung.
Umstellung leichter als gedacht
Bruno ist aus meiner Sicht ein eine erfrischende Abwechslung in der von Cloud-Systemen (eine ähnliche Geschichte hat auch das Tool Insomnia) die API-Client Landschaft dominieren. Hier ist ein Milliarden-Dollar Markt entstanden der gegenfinanziert werden muss. Genau deswegen braucht es ein Tool wie Bruno um nicht zu abhängig zu sein. Ein Tool, das die Kontrolle zurückbringt und dir ein sicheres Gefühl gibt. Wenn du noch nie mit Bruno gearbeitet hast, ist jetzt der perfekte Zeitpunkt, um es auszuprobieren.
Bruno bietet den Import/Export von Postman Collections (und auch andere Formate) an. Das klappt auch erstaunlich gut. Beim Import kann es aber trotzdem zu Problemen kommen, wenn Spezialfunktionen in Skripten verwendet wurden. Oder es wurde eine Authentifizierungsverfahren verwendet, was in Bruno noch nicht abgebildet wurde.
Ich selbst habe alle meine (ca. 50 Postman Collections) inzwischen in Bruno und vermisse Postman überhaupt nicht mehr. Falls mir jemand eine Postman Collection schickt (passiert im beruflichen Umfeld), klappt das zu 95% bereits jetzt gut mit Bruno.
Es schläft sich auf jeden Fall besser, wenn man alle Credentials selbst besitzt.
Fazit
Bruno bietet vielleicht nicht alle Funktionen die SaaS Lösungen jetzt anbieten. Aber die brauche ich oft auch nicht da diese oft den Fokus eines API-Clients verloren haben. Bruno holt die Kontroller wieder auf die eigene Maschine zurück. Probier es einfach mal aus.