FreshMarker User Directives (2)

Im ersten Teil zum Thema User Directives wurde erläutert, wie diese in die FreshMarker Engine eingefügt sind und wie eigene Java Directives erstellt werden können. In diesem Teil werden die User Directives um FreshMarker Macros erweitert.

FreshMarker User Directives (1)

Zur Vereinfachung der FreshMarker Templates sollen wiederkehrende Teile als Funktionen und Macros formulierbar sein. Statt immer wieder ähnliche Teile im Template einzufügen, sollen diese durch parametrisierbare Aufrufe ersetzt werden. Wie in FreeMarker soll dies in FreshMarker über User Directives realisiert werden.

Legacy AutoClosable

Nichts ist ärgerlicher bei der Verbesserung von Legacy Software als die Abhängigkeit von Klassen, die sich modernen Sprach Konstrukten verweigern. Eine besondere Gruppe dabei sind all die Klassen, die sich zieren vom Interface AutoClosable zu erben. Diese Klassen sind durch veraltete Abhängigkeiten in das eigene Projekt geflossen und diese Abhängigkeiten sind aus mannigfaltigen Gründen dem Zugriff des Entwicklers entzogen.

Die FreshMarker Grammatik

Im ersten Beitrag wurde aus der Vogelperspektive beschrieben, wie die FreshMarker Template-Engine zu bedienen ist. Ausgelassen wurde dabei, wie aus der Textdarstellung eines Templates eine Instanz der Klasse Template generiert wird. Um ein Template syntaktisch korrekt und sauber zu verarbeiten, bietet es sich an, einen passenden Parser zu verwenden. Mit dem Parser-Generator JavaCC 21 von Jonathan Revusky steht das passende Werkzeug zum Erzeugen eines eigenen Parsers zur Verfügung. JavaCC 21 liefert erfreulicherweise auch eine eigene FreeMarker Grammatik, mit der die eigene Entwicklung zügig beginnen kann.

JDBC Streams

In mancher Java Anwendung befinden sich Legacy Code Einschlüsse um JDBC Anfragen, die nicht mehr zeitgemäß erscheinen. Häufig wünscht sich der Entwickler, den recht plumpen Code durch eine elegante Stream Variante zu ersetzen. In dem Beitrag JPA Tabellen mit reservierten Nummernkreisen wurden IDs aus einer Tabelle ausgelesen, um den größten gefundenen Wert als Basis für zukünftige IDs zu nutzen. Der ursprüngliche Code arbeitet mit einer while-Schleife, die über ein ResultSet iteriert.

Microservice Patterns (Gateway, Anti-Corruption Layer, Strangler, Aggregation, Backend-For-Frontend)

„Beziehungen bleiben bestehen aber Bedürfnisse ändern sich“. So oder so ähnlich heißt es in einer schlüpfrigen Fernsehwerbung zu später Stunde. Bei Microservices finden sich aber tatsächlich immer wieder Situationen, bei denen zwei Microservices besser harmonieren, wenn ein dritter involviert ist.

Microservice Patterns (Domain Events)

Wie auch der vorherigen Beitrag handelt dieser über Microservices als Architekturkonzept und die dort verwendeten Design Pattern. Bei dem Microservice Pattern Domain Events handelt es sich um die Nutzung von fachlichen Ereignisse aus dem Bereich Domain-Driven Design. Die Microservices kommunizieren also nicht nur über direkten Nachrichtenaustausch mit ihnen bekannten Services, sondern sie signalisieren auch Änderungen an entkoppelte, ihnen unbekannte Services.

Mikroservice Patterns (Database Per Service)

Mikroservices stellen ein eigenes Architekturkonzept dar, mit denen Anwendungen dezentral und entkoppelt entwickelt und betrieben werden können. Eine große Anzahl von Design Pattern macht es den Entwicklern dabei einfach, gute Architekturen zu erstellen. Die Mikroservices Architektur wirkt sich jedoch nicht nur auf die Software aus, sondern bietet auch viel Potenzial um die Arbeit der Teams zu verbessern. Wie dies im speziellen aussehen kann soll an dem sehr grundlegenden Pattern Database Per Service dargestellt werden.

Der Mikrokosmos und Makrokosmos der Microservices

Ein großes Missverständnis bei der Verwendung von Microservices, ist die Annahme, es wären einfach nur sehr kleine Services. Diese Herangehensweise führt zwar schnell zu beträchtlichen Erfolgen, sie fördert aber mittel- und langfristig Fehler in ihrer Betrachtung, Verwendung und Entwicklung.

Service Limitierung mit Bucket4J

REST Services können nur eine gewisse Anzahl von Anfragen innerhalb eines Zeit Fensters verarbeiten. Werden zu viele Anfragen gestellt, dann gerät der Service unter Last und reagiert sehr langsam oder gar nicht mehr. Zusätzliche Anfragen, die ein vorgegebenes Limit übersteigen, sollten daher vom Service abgelehnt werden.