Architektur einer Golang API

Marcel Prehn
Jun 2, 2019 · 3 min read

Long time no hear.. heute melde ich mich mit einem Thema zurück, dass mir immer mal wieder Kopfschmerzen bereitet. Kurzzeitgedächtnis sei dank.

Kurzzeit-was?

Aber genau dafür dient mir ja dieser Blog: als Dev Journal. Also, heute geht es um Go. Genauer gesagt, um das kleine 1x1 der Architektur einer API, bzw. eines kleinen Services, der eine API darstellen soll.

Der Use Case

Das ist relativ simpel: ein Proxy, der mit der Todoist-API telefoniert und mir meine Projekte, Tasks, Dues etc. zurück liefert. Die Daten verarbeite ich dann im Service und stelle sie aggregiert meinem Frontend (to be) zur verfügung. Klingt ein bisschen hanebüchen, ist aber unumgänglich. Warum? Na weil ich meine Todos im Kanban-Style verwalten möchte.


Das Grundgerüst

Ich arbeite mit Go in Version 1.12.3 unter MacOS mit VisualStudio Code. Die Struktur des Projektes besteht aus meiner main.go und einem app-Package. Innerhalb des app-Packages gibt es ein handler- sowie ein model-Package. So ist es relativ übersichtlich und dennoch nach Concern getrennt.

Go Projekt Bootstrap

Mir persönlich fällt es immer schwer, nach monatelangem Java-Enterprise-Coding mit Spring entsprechend umzudenken und nicht bei Projektbeginn schon Controller-, Entity- und Service-Packages anzulegen. Durch den rudimentären Aufbau mit app-, model- und handler-Package schleicht sich allerdings nicht ganz so viel Boilerplate ins Projekt. #IMHO


Die Implementierung

Wie geht es weiter, wenn die Struktur steht? Ich persönlich bastle als erstes die Modelle, sprich in diesem Fall mein Project- und Task-Struct.

Stehen die Modelle, geht es weiter mit dem Handler. Hier findet der eigentliche API Call gegen die Todoist-Schnittstelle statt. In meinem Fall stelle ich die Anfrage, parse die Antwort und gebe mit der Funktion RenderJSON wieder JSON zurück. Als Router benutze ich übrigens den httprouter von Julien Schmidt.

Hervorzuheben sind die Funktionen ReturnJSON sowie GetAPIKey. Beide Methoden liegen in common.go im selben Package wie der Handler. Daher entfällt der Aufruf über den Qualifier.

So! Model: check! Handler: check! Utility-Methoden: check! Jetzt wird es Zeit, alles zusammen zustecken. Dazu definiere ich ein App-Struct und binde den Router ein. In der Initialisierung des Routers dann die Verbindung zwischen Request und dem entsprechenden Handler-Aufruf. Hier: ein GET um alle Projekte abzuholen. Danach nur noch die Run-Methode um den HTTP-Server zu starten und das wars! Easy as that!

Die main.go sieht nun relativ karg und unspektakulär aus. Lediglich die Instanziierung der app-Komponente, die Initialisierung dieser und der obligatorische run()-Aufruf um den Service zu starten. Fertig!


Die Moral der Geschichte

Viele Wege führen nach Rom. Für mich persönlich ist dieser hier aufgezeigte allerdings der charmanteste. Wenig Boilerplate, wenig Struktur. #leancoding Dennoch muss ich nach ein paar Go-losen Wochen auch wieder nachdenken und -lesen, wie es eigentlich ging.

Wie sich das ganze anfühlt, wenn das Projekt immer weiter wächst, wird sich noch herausstellen. Aber für den kleinen Microservice für nebenan und den Heimgebrauch macht es bisher einen guten Eindruck. Gerne lasse ich mich eines Besseren belehren. Bis dahin! 🖖🏻

marcel.works

Technological Nonsense

Marcel Prehn

Written by

Java Enterprise Development by Day, Technological Nonsense by Night. #Java #GoLang #IoT #AWS

marcel.works

Technological Nonsense

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade