Jedno miejsce dla requestów, protokołów i szybkiego debugowania.
OmniPort powstał jako własna aplikacja desktopowa do pracy z API i protokołami, które często pojawiają się przy integracjach, debugowaniu i budowaniu narzędzi technicznych. Celem nie było stworzenie kolejnego prostego klienta HTTP.
Chodziło o jedno miejsce, w którym developer może szybko sprawdzić request, zapisać go w kolekcji, przeanalizować odpowiedź i przejść do innego protokołu bez zmiany narzędzia.
Projekt miał też drugi wymiar: pokazanie, że potrafimy budować kompletne, dopracowane narzędzia produktowe, nie tylko pojedyncze funkcje.
Problemem nie był brak jednego przycisku. Problemem było tarcie.
Praca była rozproszona pomiędzy kilka narzędzi: HTTP w jednym miejscu, WebSockety w innym, a TCP, UDP i dane binarne często w terminalu, skryptach albo małych tymczasowych programach.
Za dużo przełączania kontekstu
Przepisywanie adresów, kopiowanie payloadów i brak wspólnego kontekstu requestów utrudniały porównywanie kolejnych prób.
Trudny powrót do poprzednich prób
Bez wygodnej historii i kolekcji łatwo było stracić wątek albo przypadkowo porównywać dwie różne wersje requestu.
Bajty nie są zwykłym tekstem
TCP, UDP i praca na payloadach binarnych wymagały lepszego widoku niż klasyczne pole tekstowe sklejone z przyciskiem send.
Aktywne sesje muszą być widoczne
Przy protokołach połączeniowych istotne są stany requestów, bezpieczne zamykanie sesji i kontrola nad tym, co nadal działa w tle.
Desktopowy produkt, nie formularz z przyciskiem send.
Zbudowaliśmy OmniPort jako lokalną aplikację desktopową, która łączy kilka trybów pracy w jednym interfejsie i wspiera naturalny rytm pracy developera: szybka edycja, natychmiastowy podgląd, historia, kolekcje i czytelne stany operacji.
Requesty, foldery i stan zmian
Kolekcje requestów z folderami, edycją nazw, drag and drop oraz informacją o stanie requestu względem zapisanej wersji.
HTTP, gRPC, WebSocket, TCP i UDP
Użytkownik może przełączać się między protokołami bez wychodzenia z aplikacji i bez utraty kontekstu pracy.
Tryby odczytu i aktywne sesje
Aplikacja wspiera utrzymywanie połączeń, kontrolę aktywnych sesji i scenariusze, które źle pasują do prostego runtime przeglądarkowego.
Payload bajtowy jako pierwszy obywatel
Hex view i edytor payloadu bajtowego zostały zaprojektowane pod pracę z danymi binarnymi, a nie jako zwykłe pole tekstowe.
Powrót do poprzednich prób
Historia requestów i odpowiedzi ułatwia odtworzenie kontekstu oraz pokazanie innym osobom w zespole, co faktycznie zostało sprawdzone.
Karty, statusy i potwierdzenia
Interfejs obejmuje karty, kolekcje, statusy, modalne potwierdzenia i czytelne stany operacji, w tym akcje destrukcyjne.
React dla interfejsu, Go dla cięższej komunikacji sieciowej.
Architektura została dobrana tak, aby zachować wygodny interfejs webowy, a jednocześnie obsłużyć protokoły i scenariusze, których nie warto ograniczać do samego browserowego runtime.
React
Warstwa UI powstała w React, co pozwoliło szybko rozwijać złożony interfejs: karty, panele, kolekcje, edytory i stany requestów.
Neutralino
Neutralino dało lekki start dla desktopowej aplikacji, bez budowania ciężkiej infrastruktury wokół samego okna.
Go
Rozszerzenie w Go odpowiada za requesty sieciowe, gRPC oraz TCP/UDP, czyli część scenariuszy wymagających natywnej warstwy wykonawczej.
Lekki start produktu
Neutralino dobrze sprawdziło się jako szybka droga do desktopowego MVP i pozwoliło skupić się na przepływie pracy developera.
Wnioski z IPC i aktywnych połączeń
Praca nad IPC, obsługą sesji oraz zachowaniem okna pokazała, że dalszy rozwój wymaga mocniejszej integracji frontendu z backendem natywnym.
Kierunek: Wails
Migracja w stronę Wails jest naturalnym kolejnym etapem: prostsze IPC, lepsze wsparcie okien i solidniejszy fundament pod multi-window.
Local-first: Kolekcje możesz przechowywać w git albo s3.
OmniPort przechowuje kolekcje, historię i stan sesji lokalnie, bez centralnego backendu. Dostęp do danych zależy od maszyny, na której uruchomiona jest aplikacja.
Aplikacja może działać offline w zakresie pracy z zapisanymi kolekcjami, historią i protokołami aplikacji lokalnych. Sieć jest potrzebna dopiero wtedy, gdy użytkownik odpytuje zewnętrzne usługi.
Dlaczego open source?
Model open source ułatwia sprawdzenie, co aplikacja robi z danymi, gdzie je przechowuje i jak można dalej rozwijać narzędzie bez zamkniętej infrastruktury.
Mniej przełączania, lepsza kontrola i płynniejszy workflow.
Po pierwszych próbach z kilkoma developerami aplikacja została odebrana pozytywnie. Najczęściej wracały uwagi dotyczące wygody pracy: szybszy powrót do zapisanych requestów, mniej przełączania między narzędziami i lepsza kontrola nad zmianami.
Kolekcje
Porządkowanie requestów w kolekcjach ułatwiło powrót do poprzednich prób i dzielenie się kontekstem z zespołem.
TCP/UDP i hex view
Te obszary szczególnie dobrze się sprawdziły, bo wcześniej zwykle wymagały osobnych obejść albo pracy bezpośrednio w terminalu.
Stany i akcje destrukcyjne
Feedback pomógł dopracować karty, zapisywanie requestów, czytelniejsze akcje destrukcyjne oraz zachowanie aktywnych połączeń.
Rozwój produktu oparty na realnym użyciu.
Kierunki produktowe
- Dalsze wzmacnianie pracy z kolekcjami.
- Rozbudowa metryk requestów i porównywania prób.
- Lepszy import oraz eksport kolekcji.
- Więcej narzędzi diagnostycznych dla wielu aktywnych kart.
Kierunki techniczne
- Migracja w stronę Wails jako stabilniejszego fundamentu desktopowego.
- Pewniejsze IPC i wygodniejsza obsługa natywnych okien.
- Lepsza ścieżka do multi-window.
- Mniej obchodzenia ograniczeń warstwy desktopowej, więcej pracy nad produktem.
Tak zamienia się wewnętrzną potrzebę techniczną w produkt.
OmniPort powstał, bo codzienna praca z integracjami nie kończy się na HTTP. Developerzy potrzebują narzędzia, które pozwala szybko przechodzić między protokołami, trzymać porządek w requestach i wygodnie analizować odpowiedzi, także binarne.
Porozmawiajmy o Twoim produkcie