EN
Kontakt
Menü
EN

Timothy Fehr · Zürich

Softwarearchitektur und Backend-Entwicklung

Ich bin Softwarearchitekt und Backend-Entwickler in Zürich und übernehme selbstständige Aufträge, remote und vor Ort.

Ich kläre Architekturfragen, prüfe bestehende Systeme und setze klar umrissene Änderungen an Backends und Schnittstellen um. Je nach Auftrag erhalten Sie eine schriftliche Empfehlung oder eine getestete Änderung, die ich an Ihr Team übergebe.

Mein Schwerpunkt ist Java und Spring Boot. Dazu kommen Schnittstellen, Berechtigungen und die Automatisierung von Builds und Deployments. Bei finnova habe ich zentrale Backend-Komponenten für Interbank-Messaging entwickelt und war für die automatisierten Builds und Releases einer Autorisierungsschicht auf Basis von Keycloak verantwortlich.

timothy.fehr@fehrcoding.ch Wie ich Sie unterstützen kann

Wer darf welche Gebäudedaten sehen?

MonitoringHive

Mein eigenes Projekt · In Entwicklung

Eine Plattform für Gebäudeüberwachung, die ich entworfen und gebaut habe. Jede Partei darf nur ihre eigenen Gebäude sehen, und nachträglich muss klar sein, warum eine Anfrage erlaubt oder abgelehnt wurde.

So prüft MonitoringHive Zugriffe

Java 21, Spring Boot, PostgreSQL, Keycloakmonitoringhive.ch

Wie MonitoringHive über Zugriffe entscheidet, vereinfacht Eine Anfrage an einen geschützten Endpunkt geht an einen einzigen Policy-Evaluator, der standardmässig ablehnt und «erlaubt» oder «abgelehnt» samt Grund zurückgibt. Jede Auswertung schreibt in einer separaten Transaktion eine Zeile ins Entscheid-Log. Unabhängig davon beschränkt PostgreSQL mit Row-Level Security die mandantenbezogenen Tabellen auf den aktuellen Mandanten. Anfrage Policy-Evaluator Standard: ablehnen Entscheid + Grund Entscheid-Log eine Zeile pro Auswertung PostgreSQL Row-Level Security Mandantentabellen 1 2 3
  1. Geschützte Service-Endpunkte fragen einen einzigen Evaluator. Er lehnt standardmässig ab und nennt den Grund; ein Build-Test scheitert, wenn ein Endpunkt weder geschützt noch ausdrücklich freigegeben ist.
  2. Jede Auswertung schreibt in einer separaten Transaktion eine Zeile ins Entscheid-Log, damit der Eintrag bleibt, wenn die eigentliche Operation zurückgerollt wird.
  3. PostgreSQL Row-Level Security beschränkt die mandantenbezogenen Tabellen auf den aktuellen Mandanten, auch wenn in einer Abfrage der Mandantenfilter fehlt.

Blau: der Entscheid · gestrichelt: Beleg

Stellt sich bei Ihnen eine ähnliche Frage? Schreiben Sie mir

Alle Projekte

Aus den Notizen ·

Builds verketten oder aufteilen und verbinden?

Build-Pipelines für ein Keycloak mit mehreren eigenen Plugins.

Warum ein Retry zwei Rechnungen erzeugen kann

Ein Timeout sagt nicht, ob die Rechnung erstellt wurde.

Die Abrechnung fordert für eine Bestellung eine Rechnung an und wartet höchstens 5 Sekunden auf die Antwort. Vergleichen Sie zwei Fälle: Der Anbieter antwortet zu spät, oder die erste Anfrage erreicht ihn gar nicht.

Vergleich ausprobieren

Sequenzdiagramm: Ein Retry erzeugt eine zweite Rechnung Die Abrechnung verlangt beim Rechnungsanbieter eine Rechnung für Bestellung 1042. Der Anbieter erstellt INV-1, antwortet aber langsam. Nach 5 Sekunden wartet die Abrechnung nicht länger und sendet dieselbe Anfrage nochmals. Der Anbieter hält sie für neu, erstellt INV-2 und antwortet mit INV-2. Die späte Antwort mit INV-1 trifft nach 45 Sekunden ein. Ergebnis: zwei Rechnungen für eine Bestellung. Abrechnung Rechnungsanbieter Rechnung erstellen, Bestellung 1042 erstellt INV-1 Timeout 5 s Retry: Rechnung erstellen, 1042 erstellt INV-2 INV-2 INV-1 (nach 45 s) 2 Rechnungen für 1 Bestellung

Kontakt

timothy.fehr@fehrcoding.ch

Beschreiben Sie kurz das Problem oder die Entscheidung, bei der Sie Unterstützung brauchen. Was in die erste Nachricht gehört