Wie wir unzugängliche APIs simuliert haben

Ausgangslage und erster Kontakt

Unser Kunde ist ein Schweizer Krypto-Broker, der sichere und effiziente Dienste für den Kauf, Verkauf und Handel digitaler Vermögenswerte anbietet. Das Unternehmen hat sich als vertrauenswürdiges Tor zur Welt der Kryptowährungen etabliert und zählt weltweit über 100'000 Nutzende.

Das Unternehmen ist auf Krypto-Börsendienste spezialisiert und wickelt Transaktionen mit Kryptowährungen ab. Nun wollte es in den NFT-Markt einsteigen und vor allem Gold-NFTs zum Kauf anbieten. Für das Geschäft war das ein bedeutender Schritt in ein neues Segment. Auf uns aufmerksam wurde das Unternehmen über die Website von VELOX. Unsere langjährige Erfahrung mit Microservices-Architekturen und Commerce-Lösungen, darunter das Commerce-Framework VELOX, sah es als solide Grundlage für seine Projektanforderungen.

‍

Projektziele

Das Unternehmen beauftragte uns, ein massgeschneidertes Backend zu konzipieren und umzusetzen, über das seine Kunden Gold-NFTs kaufen können. Zu diesem Zeitpunkt gab es dafür weder ein Framework noch eine Infrastruktur. Für die Plattform war es also ein völlig neues Angebot.

‍

Technische Herausforderungen und Lösungen

Eine der grössten Herausforderungen bei den Mock-APIs auf Basis von OpenAPI-Spezifikationen war die Integration externer APIs. Das Projekt erforderte mehrere API-Anbindungen, etwa um verfügbare NFTs abzurufen. Während der Entwicklung hatten wir jedoch keinen direkten Zugriff auf diese APIs. Normalerweise stehen in der Entwicklung Staging- oder Testumgebungen zur Verfügung. In diesem Fall mussten wir die API-Interaktionen stattdessen per Mocking simulieren.

Dafür setzte Sly den Prism Mock Server ein, eine schlanke Bibliothek, die APIs auf Basis von OpenAPI-Spezifikationen simuliert. So konnten wir End-to-End-Integrationstests wirksam nachbilden und sicherstellen, dass unsere Umsetzung dem erwarteten API-Verhalten entsprach. Unser Ziel war, die realen Interaktionen mit diesen APIs möglichst genau nachzubilden.

‍

‍

Mock-APIs mit OpenAPI-Spezifikationen

Die vorgeschlagene Lösung war keine Standard-E-Commerce-Implementierung, sondern eine hochgradig individuelle Commerce-Anwendung für die besonderen Anforderungen von Gold-NFT-Transaktionen. Das Design folgte Microservices-Prinzipien, um Modularität und Skalierbarkeit zu gewährleisten. So kann die Anwendung weiterwachsen und künftige Services nahtlos unterstützen. Wir haben die Software in klar getrennte Module gegliedert, die sich später erweitern oder als eigenständige Microservices auslagern lassen.

Microservices arbeiten unabhängig voneinander und ermöglichen so eine dezentrale Entwicklung und Bereitstellung. Die Gliederung in Module legt den Grundstein für den Wechsel zu einer Microservices-Architektur. Diese bietet Vorteile wie Fehlerisolierung, unabhängige Skalierung und die Möglichkeit, für verschiedene Services unterschiedliche Technologien einzusetzen.

‍

Umsetzung und Entwicklungsprozess

Sly startete die Entwicklung der Mock-APIs auf Basis der OpenAPI-Spezifikationen und schätzte Aufwand und Komplexität der Umsetzung. Im Fintech- und Kryptoumfeld hatten wir bis dahin nur wenig Erfahrung. Dank unserer Expertise mit Microservices und Commerce-Frameworks konnten wir dennoch eine zuverlässige und effiziente Lösung liefern.

‍

Tests und Qualitätssicherung

Sly schrieb den Grossteil der Integrationstests, um sicherzustellen, dass das Backend korrekt auf das simulierte API-Verhalten reagiert. Die Tests sind in die Codebasis eingebettet und prüfen, ob das System die Anforderungen auch ohne direkten API-Zugriff erfüllt. Das gab Sicherheit, dass die Anwendung zuverlässig und bereit für den Livegang war.

‍

Die wichtigsten Punkte im Überblick

1. Neue Geschäftsrichtung: Mit dem Projekt stieg der Kunde in den NFT-Handel ein und erweiterte sein Angebot über den Kryptohandel hinaus.
2. Individuelle Umsetzung: Die Lösung wurde vollständig auf die Bedürfnisse des Kunden zugeschnitten, ganz ohne Standardvorlagen für E-Commerce.
3. API-Integration ohne Zugriff: Das Mocking externer APIs mit Prism war eine Besonderheit dieses Projekts und ermöglichte gründliche Tests trotz eingeschränkter Umgebung.
4. Skalierbare Architektur: Das modulare Design macht die Lösung anpassungsfähig für künftige Microservices.
5. ‍Effiziente Entwicklung: Das Projekt wurde in einem knappen Zeitrahmen von 200 Stunden abgeschlossen, dank sorgfältiger Planung und Umsetzung.