Node.js

Servus und Ade Nest Framework

Markus Kolb

• 1 min read
Servus und Ade Nest Framework

Ok. Ich gebe zu, das war ein kurzer Ausflug zu einem neuen Framework.
Nach meiner ersten Einschätzung, habe ich die letzten fast 2 Tage versucht ein Projekt umzusetzen.

Der grobe Projekt-Beginn war einen HTTP-POST Endpunkt zum Empfangen von Dateien mit besonderem Content-Type bereitzustellen.

Ich habe dazu Nest zusammen mit fastify verwendet.

Ich hatte aber recht schnell nervenraubende Schwierigkeiten mit meiner Umsetzung bekommen. Klar es gibt immer Schwierigkeiten in einer neuen Umgebung Lösungen für altbekanntes zu finden. Aber wie aufwendig das Finden einer Lösung ist, zeigt die Qualität des Frameworks.

Konkretes Problem war, dass sich die Registrierung der Content-Types anscheinend überschrieb und am Ende nur der FormBody-Parser, der von Nest initialisiert wird, zusammen mit dem Standard application/json zur Verfügung stand.
Die Schwierigkeit liegt dann darin festzustellen, ob nun nest oder fastify an der Misere Schuld ist.
Der Schwarze Peter geht in diesem Fall an fastify. Der die register()-Methode verhält sich einfach unerwartert und es gibt, nun ja, sagen wir eine unschöne Lösung mit einer Helper-Funktion aus fastify-plugin, die einen bestimmten Key im an register zu übergebenden JS-Object setzt.
Das ist keine gute API. Wenn dem Entwickler eine Methode zur Verfügung gestellt wird, dann sollte man nicht davon ausgehen, dass der Entwickler als Parameter verpflichtend die Rückgabe einer Helper-Funktion mitgibt.
Vorallem sollte es nicht stillschweigend akzeptiert werden und am Ende doch nicht das machen, was man geschrieben hat.
Wenn man register(Äpfel) und danach register(Birnen) schreibt, dann sollten nicht die Äpfel von Mäusen gegessen sein und nur noch Birnen übrig bleiben.

Nun fasse ich noch kurz die Punkte zusammen die mich erneut zur Framework Suche veranlassen...

fastify

Nest

  • Nest-CLI Tool nicht in ./node_modules/.bin/nest lauffähig (Sie haben es nicht gebacken bekommen, die Pfade zu nest-core/common Modulen allgemeingültig aufzulösen).
  • Viel zu viele any-Typen: z.B.
    @Response() res;
res.status(HttpStatus.INTERNAL_SERVER_ERROR);
    res ist any. res.status ist any. Wie wär's mit Proxy oder Facade für request und response?!
  • Überheblicher, unfreundlicher Hauptentwickler