Talk zum Thema Nebenläufigkeit auf der OOP 2016 in München. Neben einer prinzipiellen Einführung und Motivation werden die Sprachen Erlang/OTP, Google Go und Pony vorgestellt. Weiter sind einige typische Designmuster sowie Fallstricke enthalten. Der Vortrag hatte die Dauer von 90 Minuten.
Cloud Provider like AWS offer different ways to interact with their systems and to control it. One way are the typical Web UI, others are command line tools. But they also provide APIs for many programming languages. Using them many tasks can be automated, if wanted in a reactive way like Kubernetes does it in reconciliation loops.
Take a look in how this can be done with the programming language Go and as an example for AWS as cloud provider. In the end there's a hint leading to a private project for a multi-cloud provider reconciler library in Go.
Talk zum Thema Nebenläufigkeit auf der OOP 2016 in München. Neben einer prinzipiellen Einführung und Motivation werden die Sprachen Erlang/OTP, Google Go und Pony vorgestellt. Weiter sind einige typische Designmuster sowie Fallstricke enthalten. Der Vortrag hatte die Dauer von 90 Minuten.
Cloud Provider like AWS offer different ways to interact with their systems and to control it. One way are the typical Web UI, others are command line tools. But they also provide APIs for many programming languages. Using them many tasks can be automated, if wanted in a reactive way like Kubernetes does it in reconciliation loops.
Take a look in how this can be done with the programming language Go and as an example for AWS as cloud provider. In the end there's a hint leading to a private project for a multi-cloud provider reconciler library in Go.
Im #Neuland gibt es noch heute stark in die Jahre gekommene Host- und Service-Monitoring-Lösungen, die zu den unliebsamen Langzeitbaustellen vieler Teams und Unternehmen gehören. Wer kennt es nicht, dass regelmäßige „False-Positive“-Alarme sich in Form von E-Mails oder SMS lästig bekannt machen, dass Webinterfaces schnell an ihre Grenzen stoßen, dass komplexe und benutzerfreundliche Graphen generiert werden sollen oder dass das Monitoring-Konstrukt nicht mit der großen Zahl an hippen neuen Docker-basierten Services/Checks zurechtkommt. Ganz zu schweigen von den lückenhaften oder fehlenden Programmierschnittstellen vieler Monitoring-Monolithen. In diesem Vortrag möchten wir euch eine auf Prometheus und Kubernetes basierende Musterlösung vorstellen, die eine Webapplikation über verschiedene Metriken hinweg überwacht und das DevOps-Betriebsteam zum richtigen Zeitpunkt auf konkrete Probleme aufmerksam macht.
Event: DevOpsCon, 06.12.2016
Speaker: Christoph Petrausch, inovex GmbH
Mehr Tech-Vorträge: https://www.inovex.de/de/content-pool/vortraege/
Vortrag der OOP 2014
Überblick über die Vorteile der Programmiersprache Go für skalierbare Anwendungen sowie ein Einblick in hierbei zu beachtende Probleme und ihre Lösung.
Cloud Observability mit Loki, Prometheus, Tempo und GrafanaQAware GmbH
Mastering Kubernetes, Juli 2022, Franz Wimmer (@zalintyre, Senior Software Engineer bei QAware).
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
Observability ist eine entscheidende Komponente jeder ernsthaften Kubernetes-basierten Plattform. Nur so können der zuverlässige Betrieb Cloud-nativer Anwendungen und das schnelle Debugging kniffligster Probleme, die nur in der Produktionsumgebung auftreten, durch die Entwickler gewährleistet werden.
Die wesentlichen Säulen guter Observability sind Logs, Metriken und Traces. Es gibt eine große Anzahl kommerzieller Tools und SaaS-Anbieterr, welche die Aggregation und Analyse der relevanten Diagnosedaten unterstützen.
In diesem Vortrag verwenden wir hingegen einen vollständig auf Open-Source-Bausteinen basierenden Stack: Promtail zum Weiterleiten von Logs an Loki, Prometheus zum Sammeln von Metriken und Tempo zum Empfangen von Traces. Wir zeigen zudem, wie mit der neuen Exemplars-Storage-Funktion der schnelle Übergang von Metriken zu Traces und Logs möglich wird.
17 years after Fieldings paper REST is at its peak. Every interface has to use REST. But there are many problems in using and designing REST APIs. This sessions describes the problems and encourages to use besides REST other means of communication.
FileMaker Skripten akzeptieren nur einen einzigen Parameter, den man innerhalb des Skriptes mit der Funktion 'Get(ScriptParameter)' auslesen kann. Seit der Einführung des Skript-Parameters in FileMaker 7 haben Entwickler nach Wegen gesucht, die Beschränkung auf einen einzigen Parameter zu umgehen. In den meisten Programmiersprachen akzeptieren Funktionen eine beliebige Anzahl von Parametern. Wenn man einen Weg findet, in den einzigen Parameter eines FileMaker Skriptes mehrere Parameter zu verpacken, kombiniert man das Konzept des "FileMaker Skriptes" mit dem Konzept der "Funktion". Aus dieser Verbindung ist in der englischsprachigen FileMaker-Community der Begriff "Function Scripting" entstanden. Dieser Vortrag gibt einen Überblick über einige Vorgehensweisen, wie man mehrere Parameter an ein Skript übergeben kann. Wir beginnen mit einfacheren Methoden, die auch für Entwickler mit wenig Erfahrung geeignet sind, und tasten uns danach an fortgeschrittene Techniken heran. Fortgeschrittene Techniken bedeuten mehr Aufwand und Komplexität, bieten aber mehr Kontrolle.
Download Beispieldateien:
http://www.filemaker-konferenz.com/2014/downloads/Hirt_Thomas/Function_Scriptung_und_Custom_Functions.zip
Im Kontext von APIs kommt derzeit keiner an REST (Representational State Transfer) vorbei. REST gilt als leichtgewichtige, skalierbare und schnell erlernbare Alternative zu SOAP, die sich die vorhandene Infrastruktur des WWW zunutze macht. In der Praxis hat aber auch REST seine Schwächen. So ist gutes API-Design häufig eine Herausforderung. Für mobile Anwendungen ist REST zu starr und geht nicht effizient genug mit Bandbreite um.
Im Vortrag werden Stärken und Schwächen von REST aufgezeigt und mit GraphQL eine Alternative speziell für den mobilen Kontext vorgestellt.
Cloud Native & Java EE: Freund oder Feind?QAware GmbH
JavaLand 2017, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware)
Abstract:
Anwendungen nativ für den Betrieb in der Cloud auszulegen, ist der Architekturstil der Stunde: Microservices, 12-Factor Apps und Serverless-Architecturen sind en vogue. Daneben gibt es Java EE, das sich über Jahre bewährt hat beim Bau von Java-Anwendungen fürs Unternehmen. Java-EE-Anwendungen im modernen Cloud-Native-Stil zu entwickeln ist kein Widerspruch, sondern ein Zugewinn: Man kann damit Enterprise-Anwendungen bauen, die reif für die Cloud-Ära sind.
Der Vortrag zeigt am laufenden Beispiel, wie man eine Cloud-Native-Java-EE-Anwendung entwickelt und wie sich Java-EE-APIs wie JAX-RS, CDI und JPA integrieren mit Cloud-Native-Infrastruktur wie DC/OS, Kubernetes, Hystrix, Traefik, Consul und Docker. Dabei wird nicht nur blanke Technologie gezeigt, sondern auch das Thema Cloud Native Java EE auf Architekturebene betrachtet.
Anwendungen nativ für den Betrieb in der Cloud auszulegen, ist der Architekturstil der Stunde: Microservices, 12-Factor Apps und Serverless-Architecturen sind en vogue. Daneben gibt es Java EE, das sich über Jahre bewährt hat beim Bau von Java-Anwendungen fürs Unternehmen. Java-EE-Anwendungen im modernen Cloud-Native-Stil zu entwickeln- ist kein Widerspruch, sondern ein Zugewinn: Man kann damit Enterprise-Anwendungen bauen, die reif für die Cloud-Ära sind.
Der Vortrag zeigt am laufenden Beispiel, wie man eine Cloud-Native-Java-EE-Anwendung entwickelt und wie sich Java-EE-APIs wie JAX-RS, CDI und JPA integrieren mit Cloud-Native-Infrastruktur wie DC/OS, Kubernetes, Hystrix, Traefik, Consul und Docker. Dabei wird nicht nur blanke Technologie gezeigt, sondern auch das Thema Cloud Native Java EE auf Architekturebene betrachtet.
Dies ist der zweite Teil der Tour de Dart. Der erste Teil hat die Sprache Dart an sich betrachtet. Dieser zweite Teil betrachtet erweiterte Aspekte wie:
Das Library System von Dart und den zugehörigen Paketmanager pub. Die asynchrone Programmierung mittels Streams, Futures und Isolates. File I/O mit Dart. Zugriff auf den DOM-Tree mittels Selektoren sowie Event Handling (Client side). Server und Client side Programmierung unter Nutzung von HttpServer, dem Dart webframework Start und Websockets. Datenkonvertierungen (HTML escaping, XSS prevention, decoding and encoding of JSON, base64 encoding and decoding, hashfunction (CryptoUtils)).
Talk about the programming language Go and the feature of generics. Those have been added to the language with the version 1.18. To have more control about allowed generics Go also got type constraints as careful extension of the interfaces. Get insight into this powerful extension and how it can help you.
The document discusses moving from imperative APIs to declarative APIs. With declarative APIs, clients describe a desired state in documents rather than controlling how services execute tasks. Controllers are responsible for continuously reconciling the current state with the desired state described in documents. The approach aims to simplify distributed environments by centralizing business logic processing. Kubernetes is provided as an example of how controllers can subscribe to document changes and process reconciliations. Declarative APIs may also be useful for integrating commercial services.
Weitere ähnliche Inhalte
Ähnlich wie DevOpsCon - Verteilte Entwicklung in Go
Im #Neuland gibt es noch heute stark in die Jahre gekommene Host- und Service-Monitoring-Lösungen, die zu den unliebsamen Langzeitbaustellen vieler Teams und Unternehmen gehören. Wer kennt es nicht, dass regelmäßige „False-Positive“-Alarme sich in Form von E-Mails oder SMS lästig bekannt machen, dass Webinterfaces schnell an ihre Grenzen stoßen, dass komplexe und benutzerfreundliche Graphen generiert werden sollen oder dass das Monitoring-Konstrukt nicht mit der großen Zahl an hippen neuen Docker-basierten Services/Checks zurechtkommt. Ganz zu schweigen von den lückenhaften oder fehlenden Programmierschnittstellen vieler Monitoring-Monolithen. In diesem Vortrag möchten wir euch eine auf Prometheus und Kubernetes basierende Musterlösung vorstellen, die eine Webapplikation über verschiedene Metriken hinweg überwacht und das DevOps-Betriebsteam zum richtigen Zeitpunkt auf konkrete Probleme aufmerksam macht.
Event: DevOpsCon, 06.12.2016
Speaker: Christoph Petrausch, inovex GmbH
Mehr Tech-Vorträge: https://www.inovex.de/de/content-pool/vortraege/
Vortrag der OOP 2014
Überblick über die Vorteile der Programmiersprache Go für skalierbare Anwendungen sowie ein Einblick in hierbei zu beachtende Probleme und ihre Lösung.
Cloud Observability mit Loki, Prometheus, Tempo und GrafanaQAware GmbH
Mastering Kubernetes, Juli 2022, Franz Wimmer (@zalintyre, Senior Software Engineer bei QAware).
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
Observability ist eine entscheidende Komponente jeder ernsthaften Kubernetes-basierten Plattform. Nur so können der zuverlässige Betrieb Cloud-nativer Anwendungen und das schnelle Debugging kniffligster Probleme, die nur in der Produktionsumgebung auftreten, durch die Entwickler gewährleistet werden.
Die wesentlichen Säulen guter Observability sind Logs, Metriken und Traces. Es gibt eine große Anzahl kommerzieller Tools und SaaS-Anbieterr, welche die Aggregation und Analyse der relevanten Diagnosedaten unterstützen.
In diesem Vortrag verwenden wir hingegen einen vollständig auf Open-Source-Bausteinen basierenden Stack: Promtail zum Weiterleiten von Logs an Loki, Prometheus zum Sammeln von Metriken und Tempo zum Empfangen von Traces. Wir zeigen zudem, wie mit der neuen Exemplars-Storage-Funktion der schnelle Übergang von Metriken zu Traces und Logs möglich wird.
17 years after Fieldings paper REST is at its peak. Every interface has to use REST. But there are many problems in using and designing REST APIs. This sessions describes the problems and encourages to use besides REST other means of communication.
FileMaker Skripten akzeptieren nur einen einzigen Parameter, den man innerhalb des Skriptes mit der Funktion 'Get(ScriptParameter)' auslesen kann. Seit der Einführung des Skript-Parameters in FileMaker 7 haben Entwickler nach Wegen gesucht, die Beschränkung auf einen einzigen Parameter zu umgehen. In den meisten Programmiersprachen akzeptieren Funktionen eine beliebige Anzahl von Parametern. Wenn man einen Weg findet, in den einzigen Parameter eines FileMaker Skriptes mehrere Parameter zu verpacken, kombiniert man das Konzept des "FileMaker Skriptes" mit dem Konzept der "Funktion". Aus dieser Verbindung ist in der englischsprachigen FileMaker-Community der Begriff "Function Scripting" entstanden. Dieser Vortrag gibt einen Überblick über einige Vorgehensweisen, wie man mehrere Parameter an ein Skript übergeben kann. Wir beginnen mit einfacheren Methoden, die auch für Entwickler mit wenig Erfahrung geeignet sind, und tasten uns danach an fortgeschrittene Techniken heran. Fortgeschrittene Techniken bedeuten mehr Aufwand und Komplexität, bieten aber mehr Kontrolle.
Download Beispieldateien:
http://www.filemaker-konferenz.com/2014/downloads/Hirt_Thomas/Function_Scriptung_und_Custom_Functions.zip
Im Kontext von APIs kommt derzeit keiner an REST (Representational State Transfer) vorbei. REST gilt als leichtgewichtige, skalierbare und schnell erlernbare Alternative zu SOAP, die sich die vorhandene Infrastruktur des WWW zunutze macht. In der Praxis hat aber auch REST seine Schwächen. So ist gutes API-Design häufig eine Herausforderung. Für mobile Anwendungen ist REST zu starr und geht nicht effizient genug mit Bandbreite um.
Im Vortrag werden Stärken und Schwächen von REST aufgezeigt und mit GraphQL eine Alternative speziell für den mobilen Kontext vorgestellt.
Cloud Native & Java EE: Freund oder Feind?QAware GmbH
JavaLand 2017, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware)
Abstract:
Anwendungen nativ für den Betrieb in der Cloud auszulegen, ist der Architekturstil der Stunde: Microservices, 12-Factor Apps und Serverless-Architecturen sind en vogue. Daneben gibt es Java EE, das sich über Jahre bewährt hat beim Bau von Java-Anwendungen fürs Unternehmen. Java-EE-Anwendungen im modernen Cloud-Native-Stil zu entwickeln ist kein Widerspruch, sondern ein Zugewinn: Man kann damit Enterprise-Anwendungen bauen, die reif für die Cloud-Ära sind.
Der Vortrag zeigt am laufenden Beispiel, wie man eine Cloud-Native-Java-EE-Anwendung entwickelt und wie sich Java-EE-APIs wie JAX-RS, CDI und JPA integrieren mit Cloud-Native-Infrastruktur wie DC/OS, Kubernetes, Hystrix, Traefik, Consul und Docker. Dabei wird nicht nur blanke Technologie gezeigt, sondern auch das Thema Cloud Native Java EE auf Architekturebene betrachtet.
Anwendungen nativ für den Betrieb in der Cloud auszulegen, ist der Architekturstil der Stunde: Microservices, 12-Factor Apps und Serverless-Architecturen sind en vogue. Daneben gibt es Java EE, das sich über Jahre bewährt hat beim Bau von Java-Anwendungen fürs Unternehmen. Java-EE-Anwendungen im modernen Cloud-Native-Stil zu entwickeln- ist kein Widerspruch, sondern ein Zugewinn: Man kann damit Enterprise-Anwendungen bauen, die reif für die Cloud-Ära sind.
Der Vortrag zeigt am laufenden Beispiel, wie man eine Cloud-Native-Java-EE-Anwendung entwickelt und wie sich Java-EE-APIs wie JAX-RS, CDI und JPA integrieren mit Cloud-Native-Infrastruktur wie DC/OS, Kubernetes, Hystrix, Traefik, Consul und Docker. Dabei wird nicht nur blanke Technologie gezeigt, sondern auch das Thema Cloud Native Java EE auf Architekturebene betrachtet.
Dies ist der zweite Teil der Tour de Dart. Der erste Teil hat die Sprache Dart an sich betrachtet. Dieser zweite Teil betrachtet erweiterte Aspekte wie:
Das Library System von Dart und den zugehörigen Paketmanager pub. Die asynchrone Programmierung mittels Streams, Futures und Isolates. File I/O mit Dart. Zugriff auf den DOM-Tree mittels Selektoren sowie Event Handling (Client side). Server und Client side Programmierung unter Nutzung von HttpServer, dem Dart webframework Start und Websockets. Datenkonvertierungen (HTML escaping, XSS prevention, decoding and encoding of JSON, base64 encoding and decoding, hashfunction (CryptoUtils)).
Talk about the programming language Go and the feature of generics. Those have been added to the language with the version 1.18. To have more control about allowed generics Go also got type constraints as careful extension of the interfaces. Get insight into this powerful extension and how it can help you.
The document discusses moving from imperative APIs to declarative APIs. With declarative APIs, clients describe a desired state in documents rather than controlling how services execute tasks. Controllers are responsible for continuously reconciling the current state with the desired state described in documents. The approach aims to simplify distributed environments by centralizing business logic processing. Kubernetes is provided as an example of how controllers can subscribe to document changes and process reconciliations. Declarative APIs may also be useful for integrating commercial services.
This document discusses concurrency in Go and provides examples of using goroutines and channels for common concurrency patterns like background jobs, streaming data processing, and building services. It explains how goroutines allow running functions concurrently, and how typed channels enable goroutines to communicate and synchronize work through message passing. The examples demonstrate spawning goroutines, piping data between processes, and implementing a service backend that handles requests concurrently using a select statement.
Functions in Go provide a powerful, flexible and elegant way to organize code. They can be used to define simple logic, handle events and state machines, and manage concurrent processing. Functions are first-class types that can be passed around like any other value. This allows defining reusable logic through closures and implementing interfaces through anonymous functions. Combined with channels, functions enable building concurrent and asynchronous systems in a way that remains maintainable. Overall, Go's lightweight functions are a primary tool for organizing code across many domains.
Blockchains - Mehr als nur digitale WährungenFrank Müller
Eine Einführung in die Technologie der Blockchains und hier Speziell Ethereum als Chain mit Accounts und Smart Contracts, mit Whisper für das Peer-to-Peer Messaging und mit Swarm für Dateispeicherung.
Der Status von Ethereum heute sowie die Schritte für das nächste große Release und diverse Anwendungsfälle werden gezeigt.
Juju - Scalable Software with Google GoFrank Müller
The document discusses the results of a study on the effects of a new drug on memory and cognitive function in older adults. The double-blind study involved 100 participants aged 65-80 who were given either the drug or a placebo daily for 6 months. Researchers found that those who received the drug performed significantly better on memory and problem-solving tests at the end of the study compared to those who received the placebo.
RESTful Web Applications with Google GoFrank Müller
This document discusses building RESTful web applications with Google Go. It describes using Go's HTTP package to handle requests, creating a custom multiplexer to route requests based on path, defining handler interfaces to support CRUD operations, using contexts to pass request information to handlers, and marshaling data to JSON. An example shows stat, content, and tag handlers interacting to serve page and tag requests, with the stat handler asynchronously updating backend data.
Vortrag der OOP 2014
Ein Einstieg in die Software Juju für das Provisioning und die Konfiguration von Clouds sowie ein Überblick über Architekturaspekte.
An introduction into Googles programming language Go, which had its first release in March 2012. The talk has been held at the regulars' table of the GTUG Bremen.
The document discusses event-driven architecture and some of its key challenges, including how to handle latency and outages in distributed systems, how to deal with changing and temporary services, and how more complex implementations involve message-driven architectures, publish/subscribe messaging, complex event processing, and event-driven business process management. The future is envisioned to involve less monolithic applications and more dynamic compositions of internal and external services tailored to individual end users.
This document discusses agile processes and their alignment with service-oriented architectures (SOAs). It provides an introduction to agile principles and processes like extreme programming and Scrum. The key points made are:
1) Agile processes are well-suited for SOAs because they allow for flexible responses to changing requirements, continuous delivery of working software, and focus on customer satisfaction - all of which are important for services that have multiple clients.
2) Agile development supports the creation of sustainable SOA solutions through practices like continuous improvement and maintaining technical excellence - important for services that operate over long periods of time.
3) While some worry that agile only works for small teams, the document asserts that
4. • Laufzeitumgebung sind Clouds und Cluster
• Komponenten sind Microservices
• Aufteilung bringt Flexibilität und Skalierbarkeit
• APIs auf Basis von REST oder gRPC bringen
Sprachunabhängigkeit
Runtime im Netz Frank Müller
6. • HTTP Bibliothek ist genug
• URL bezeichnet Typ und gegebenenfalls Ressource
• HTTP Methode bestimmt Aktion
• Create / Read / Update / Delete ist POST / GET / PUT / DELETE
• Body enthält die Daten
• Content Type ist in der Regel JSON
Einfache Struktur Frank Müller
8. • Package net/http enthält Server, Request und Response
• Es definiert den Handler und implementiert ihn als ServeMux
• Nicht hinreichend, aber leicht zu ergänzen
• Ein eigenes Package httpx hilft
‣ Pfade abbilden
‣ Methoden abbilden
Standardbibliothek genügt beinahe Frank Müller
9. // NestedHandler allows to nest handler following the
// pattern /handlerA/{entityID-A}/handlerB/{entityID-B}.
type NestedHandler struct {
resource string
handler http.Handler
nested map[string]http.Handler
}
func NewNestedHandler(resource string, handler http.Handler) *NestedHandler {
return &NestedHandler{
resource: resource,
handler: handler,
nested: make(map[string]http.Handler),
}
}
Pfade abbilden (1) Frank Müller
11. func (h *NestedHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
// Check if own or one of the nested handler is addressed.
eh, ok := h.analyzePath(r.URL.Path)
if ok {
eh.ServeHTTP(w, r)
return
}
// Handler not found.
http.NotFound(w, r)
}
Pfade abbilden (3) Frank Müller
12. // CreateHandler care for create requests, aka POST.
type CreateHandler interface {
Create(w http.ResponseWriter, r *http.Request)
}
// ReadHandler care for read requests, aka GET.
type ReadHandler interface {
Read(w http.ResponseWriter, r *http.Request)
}
.
.
.
Methoden abbilden (1) Frank Müller
13. // MethodHandler maps requests to according methods.
type MethodHandler struct {
handler http.Handler
}
// NewMethodHandler wraps a handler for automatic method mapping.
func NewMethodHandler(h http.Handler) *MethodHandler {
return &MethodHandler{
handler: h,
}
}
Methoden abbilden (2) Frank Müller
14. // ServeHTTP implements http.Handler and cares for the mapping.
func (h *MethodHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
switch r.Method {
case http.MethodPost:
if ch, ok := h.handler.(CreateHandler); ok {
ch.Create(w, r)
return
}
case http.MethodGet:
...
}
// Fallback.
h.handler.ServeHTTP(w, r)
}
Methoden abbilden (3) Frank Müller
16. • Handler jeweils für Logik von Shopping Cards und Items
• Wrapping durch MethodHandler
• Kombination durch NestedHandler
Beispiel Shopping API (1) Frank Müller
17. type CardsHandler struct { ... }
// Create to handle POST requests.
func (h *CardsHandler) Create(w http.ResponseWriter, r *http.Request) { ... }
// Read to handle GET requests.
func (h *CardsHandler) Read(w http.ResponseWriter, r *http.Request) { ... }
type ItemsHandler struct { ... }
// Create to handle POST requests.
func (h *ItemsHandler) Create(w http.ResponseWriter, r *http.Request) { ... }
// Read to handle GET requests.
func (h *ItemsHandler) Read(w http.ResponseWriter, r *http.Request) { ... }
Beispiel Shopping API (2) Frank Müller
18. // Little helper for convenience, wrapping with logging,
// authentication/authorization, and method handling.
wrap := func(h http.Handler) http.Handler {
return httpx.NewLogHandler(httpx.NewAuthHandler(httpx.NewMethodHandler(h)))
}
// Wrap the handlers for business logic.
ch := wrap(NewCardsHandler())
ih := wrap(NewItemsHandler())
// Nest the handlers for business logic of cards and their items.
ncih := httpx.NewNestedHandler("cards", ch).Nest("items", ih)
Beispiel Shopping API (3) Frank Müller
19. // Use standard multiplexer for all handlers.
mux := http.NewServeMux()
mux.Handle("/cards/", ncih)
// Configure and start server using the multiplexer.
s := &http.Server{
Addr: ":8080",
Handler: mux,
ReadTimeout: 10 * time.Second,
WriteTimeout: 10 * time.Second,
MaxHeaderBytes: 1 << 20,
}
log.Fatal(s.ListenAndServe())
Beispiel Shopping API (4) Frank Müller
20. • Analyse des Pfads an einer Position für Resource Identifier
• Analyse des Content Type
• Analyse weiterer Header
• Marshal und Unmarshal direkt in oder aus dem Body
Weitere Helfer für das Package Frank Müller
21. • Wenig Dependencies, wenig Komplexität, leichte Erweiterbarkeit
• Wrapping ist praktisch für modulare Erweiterung
‣ Authentisierung und Autorisierung
‣ Logging
• Testing der Geschäftslogik ist losgelöst von diesen Aspekten
Vorteile Frank Müller
22. • Eigenes Package erfordert Vorarbeit und eigene Wartung
• Marshalling und Unmarshalling der Transportobjekte bringt
manuelle Aufwände mit sich
Nachteile Frank Müller
24. •Remote Procedure Calls
•Bei Google entwickelt
•Nutzen in der Regel Protocol
Buffers
•Server bietet Dienste an
•Clients nutzen sie
Eigentlich nichts besonderes Frank Müller
Go Service
JS Client Java Client
gRPC
Server
gRPC
Stub
gRPC
Stub
Proto Request
Proto Request
Proto Response
Proto Responses
25. • Protocol Buffers beschreiben Datenstrukturen
‣ sprachunabhängig
‣ plattformunabhängig
‣ erweiterbar
• Serialisiert Daten für den Transport
•Stubs werden für Zielsprache und -plattform generiert
Grundlagen Frank Müller
26. • Definition in Proto-Datei
• Übertragung der Daten als Messages
• Verschiedene Felder stehen zur Verfügung
‣ Verschiedene Integers, String, Bool, Floats, Slice of Bytes
‣ Optionales, OneOf, Enumerations, Wiederholungen
‣ Default Value und Schachtelungen
Transport der Daten Frank Müller
27. // Message to add one item to an existing card.
message AddItemRequest {
required string card_id = 1;
required string article_no = 2;
optional group spec = 3 {
optional string size = 4;
optional string color = 5;
}
required uint64 number = 6;
}
// Message to reply to the adding of an article.
message AddItemReply { ... }
Nachrichten Frank Müller
28. // Service for the management of a shopping card.
service Cards {
// Create a new card.
rpc NewCard () returns (NewCardReply) {}
// Add an item.
rpc AddItem (AddItemRequest) returns (AddItemReply) {}
...
}
Services Frank Müller
29. Vorbereitung Frank Müller
## Installation der Plugins
$ go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.26
$ go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.1
## Pfad erweitern
$ export PATH="$PATH:$(go env GOPATH)/bin"
## gRPC Code generieren
$ protoc -I $SRCDIR --go_out $DSTDIR $SRCDIR/myshop.proto
30. // AddItem handels the AddItem call.
func (s *cardService) AddItem(
ctx context.Context, in *pb.AddItemRequest) (*pb.AddItemReply, error) {
// Use data of AddItemRequest in to add the item, e.g.
card, err := s.loadCard(in.CardId)
if err != nil {
return nil, err
}
...
// Return the reply.
return &pb.AddItemReply{
...
}, nil
}
Server (1) Frank Müller
31. // Start listener and GRPC server.
lis, err := net.Listen("tcp", ":10000")
if err != nil {
log.Fatalf("failed to listen: %v", err)
}
grpcServer := grpc.NewServer()
// Register card service.
myshop.RegisterCardServer(grpcServer, &cardService{})
// Start serving.
grpcServer.Serve(lis)
Server (2) Frank Müller
32. // Connect the server.
conn, err := grpc.Dial("localhost:10000")
if err != nil {
log.Fatalf("failed to connect the server: %v", err)
}
defer conn.Close()
// Start the client.
client := calculator.NewCardClient(conn)
// Perform requests using the created client.
reply, err := client.AddItem(context.Background(), &pb.AddItemRequest{ ... })
...
Client Frank Müller
33. • Statische Datenformate
• Effiziente Serialisierung
• Streaming möglich
• Connections können beibehalten werden
• Umfangreicher Stack für Security und Credentials
• Problemloser Mix verschiedener Sprachen
Vorteile Frank Müller
34. • Nicht für alle Sprachen verfügbar
• Proto-Dateien sind eigene Artefakte (bei Mehrsprachigkeit eher
Vorteil)
• Extra Tools notwendig
Nachteile Frank Müller
36. • RESTful APIs sind etabliert und flexibel
• Sie können in vielen Sprachen leicht implementiert werden
• Unabhängigkeit von Sprachen und Plattformen
• gRPC ist ein leistungsstarker Nachfolger
• Definition in Proto-Dateien erlaubt leichteren Austausch
• Generator nicht für alle Sprachen verfügbar
Zusammenfassung Frank Müller