Beyond REST and CRUD: CQRS/ES mit GraphQL

Beyond REST and CRUD: CQRS/ES mit GraphQL
François Fernandes
Senior Solution Architect
francois.fernandes@digitalfrontiers.de
@tellme_francois
github.com/fernanfs

?
2
Was stimmt nicht mit
REST und CRUD

3
Was ist denn eigentlich REST?
• Alle relevanten Daten sind über eine URI erreichbar
http://smart.service/api/resources/<resource-id>
• Änderungen an den Daten werden mittels HTTP Requests und
passenden Verben durchgeführt
POST http://smart.service/api/resources/
GET http://smart.service/api/resources/<resource-id>
DELETE http://smart.service/api/resources/<resource-id>

3
Was ist denn eigentlich REST?
• Alle relevanten Daten sind über eine URI erreichbar
http://smart.service/api/resources/<resource-id>
• Änderungen an den Daten werden mittels HTTP Requests und
passenden Verben durchgeführt
POST http://smart.service/api/resources/
GET http://smart.service/api/resources/<resource-id>
DELETE http://smart.service/api/resources/<resource-id>
Kein REST ist:
GET http://dumb.service/api/resources/<id>/applyColorBlue

4
Betrachten wir ein Beispiel
Verwaltung für Gutscheinkarten

4
• Ausstellen neuer Karten

4
• Guthaben einlösen

4
• Guthaben erhöhen

4
• Karte stornieren

4
• Einlösung stornieren

5

6
Ausstellen neuer Karten
POST http://svc.local/api/giftcards
Accept: application/json
Content-Type: application/json
{
"amount": 42
}
Request HTTP/1.1 200 OK
{
"id": 102,
"amount": 42
}
Response

7
Guthaben einlösen
POST http://svc.local/api/giftcards/102/transactions
{
"amount": 11
}
Request HTTP/1.1 201 CREATED
{
"id": 203,
"amount": -11,
"description": "Redeem"
}
Response

8
Guthaben erhöhen
PUT http://svc.local/api/giftcards/102
{
"amount": 80
}
{
"id": 102,
"amount": 80
}
Response

8
Guthaben erhöhen
{
"amount": 80
}
{
"id": 102,
"amount": 80
}
Response
Ist das der Betrag um
den das Guthaben
erhöht werden soll?
Oder ist es der neue
Zielbetrag?

9
Karte stornieren
Was ist eigentlich eine Stornierung?
• Löschung mittels DELETE?
Der Datensatz sollte weiterhin existieren für
eine Nachverfolgung
• Eine Aktualisierung mittels PUT?
Das steht in Konkurrenz zu Erhöhung des
Guthabens

10
Karte stornieren
{
"revoked": true
}
Request HTTP/1.1 200
{
"id": 102,
"amount": 80,
"revoked": true
}
Response

11
Überlappung
@PutMapping("{id}")
fun updateGiftCard(
@PathVariable id: Long,
@RequestBody input: GiftCardUpdateInput): GiftCardDto {
return if (input.amount != null)
service.increaseAmountTo(id, input.amount).asDto()
else if (input.revoked == true)
service.revokeCard(id).asDto()
else
// intention unclear
throw UnknownGiftCardUpdateRequestException()
}

12
Einlösung stornieren
Auf welcher Ressource (URI) operieren wir?
• DELETE http://svc.local/api/giftcards/102/transactions/203
Löschung mittels DELETE
• POST http://svc.local/api/giftcards/102/transactions
Erstellen eines Storno-Datensatzes

13
DELETE http://svc.local/api/giftcards/102/transactions/203
• Der Datensatz soll nicht gelöscht werden
• Auch wird der Datensatz selbst nicht geändert, sondern ein
neuer angelegt

14
• Der Body des POST könnte ein Flag tragen, das den Datensatz
als Stornierung kennzeichnet
• Steht in Konkurrenz zu normalen Transaktionen
{
"amount": -11,
„revokedTransactionId": 203
}
Request

16
GraphQL Schnelleinstieg
• GraphQL ist ein Mechanismus für die Kommunikation
zwischen Client und Server
• Die technische Übertragung ist typischerweise HTTP
• Kern von GraphQL ist das GraphQL Schema
• Das GraphQL Schema definiert, welche Daten der Server
bereitstellen kann

17
GraphQL Schnelleinstieg: Das Schema
• Das GraphQL Schema basiert auf
Typen
type Type {
field: StrictType
}
type StrictType {
valueNeverNull: String!
}
type PrimitiveFields {
identifier: ID!
numeric: Int!
}
type TypeWithArrays {
strings: [String]
strictList: [StrictType!]!
}

18
Typen
• Ein Typ besteht aus Feldern und
deren Typisierung
type Type {
field: StrictType
}
type StrictType {
}
identifier: ID!
numeric: Int!
}
strings: [String]
}

19
Typen
deren Typisierung
• Felder können explizit als non-
nullable deklariert werden
type Type {
field: StrictType
}
type StrictType {
}
identifier: ID!
numeric: Int!
}
strings: [String]
}

20
Typen
deren Typisierung
• Die Typen der Felder sind entweder
deklarierte Typen oder Scalars
type Type {
field: StrictType
}
type StrictType {
}
identifier: ID!
numeric: Int!
}
strings: [String]
}

21
Typen
deren Typisierung
• Die Typen der Felder sind entweder
deklarierte Typen oder Scalars
• Listen werden ebenfalls typisiert
definiert
type Type {
field: StrictType
}
type StrictType {
}
identifier: ID!
numeric: Int!
}
strings: [String]
}

22
• Felder können Argumente erhalten
• Anhand der Argumente kann der
Zugriff auf das Feld konfiguriert
werden
type Type {
field(filter: String!): ResultType
other(filter: Filter!): ResultType
}
input Filter {
text: String
maxResults: Int
}

23
• Felder können Argumente erhalten
• Anhand der Argumente kann der
Zugriff auf das Feld konfiguriert
werden
• Komplexere Argumente können in
eigenen Input-Typen definiert
werden
type Type {
field(filter: String!): ResultType
other(filter: Filter!): ResultType
}
input Filter {
text: String
maxResults: Int
}

24
Das GraphQL Schema bietet noch weitere Möglichkeiten
• Union Types
• Enum
• Eigene Skalare
• Interfaces

25
Das Schema definiert drei
Einstiegspunkte in den Graphen:

26
• Query
type Query {
#...
}

27
• Query
• Mutation
type Query {
#...
}
type Mutation {
#...
}

28
• Query
• Mutation
• Subscription
type Query {
#...
}
type Mutation {
#...
}
type Subscription {
#...
}

29
• Query ist der Einstieg in den
Graphen
• Daten die für den Client abrufbar
sein sollen, müssen direkt oder
indirekt über Query erreichbar sein
• Die Komplexität des Graphen ist
wenig limitiert
type Query {
companies: [Company!]!
company(id: ID!): Company
}
type Company {
id: ID!
name: String!
locations: [Location!]!
}
type Location {
name: String!
address: Address
}
type Address {
addressLines: [String!]!
city: String!
postalCode: String!
Country: String!
}

30
Queries

31
Queries
• Abfragen in dem Graphen werden mittels Queries definiert
• Die Query-Sprache ist stark an dem GraphQL Schema
angelehnt

32
GraphQL Schnelleinstieg: Queries
Eine Query definiert, welche Daten aus dem Grafen
ausgelesen werden sollen
type Query {
}
type Company {
id: ID!
name: String!
}
type Location {
name: String!
address: Address
}
type Address {
city: String!
postalCode: String!
Country: String!
}

32
type Query {
}
type Company {
id: ID!
name: String!
}
type Location {
name: String!
address: Address
}
type Address {
city: String!
postalCode: String!
Country: String!
}
query {
companies {
name
locations {
name
}
}
}

32
type Query {
}
type Company {
id: ID!
name: String!
}
type Location {
name: String!
address: Address
}
type Address {
city: String!
postalCode: String!
Country: String!
}
query {
companies {
name
locations {
name
}
}
}
{
"data": {
"companies": [
{
"name": "Apple",
"locations": [
{
"name": "Campus"
}
]
}
]
}
}

32
type Query {
}
type Company {
id: ID!
name: String!
}
type Location {
name: String!
address: Address
}
type Address {
city: String!
postalCode: String!
Country: String!
}
query {
companies {
name
locations {
name
}
}
}
{
"data": {
"companies": [
{
"name": "Apple",
"locations": [
{
"name": "Campus"
}
]
}
]
}
}
Ein GraphQL Server antwortet nur mit den
Daten, die explizit angefordert wurden

33
Mutations

34
Mutations
• Mutationen werden verwendet um explizit schreibende
Zugriffe zu definieren
• Mutations verwenden ebenfalls die Query-Sprache

35
GraphQL Schnelleinstieg: Mutations
Eine Mutation funktioniert analog zu einer Query.
type Mutation {
createCompany(
name: String!
): Company
addLocation(
companyId: ID!,
location: LocationInput!
): Location
}
input LocationInput {
name: String!
address: AddressInput
}
input AddressInput {
city: String!
postalCode: String!
Country: String!
}

35
type Mutation {
createCompany(
name: String!
): Company
addLocation(
companyId: ID!,
): Location
}
name: String!
}
city: String!
postalCode: String!
Country: String!
}
mutation {
createCompany(
name: „Microsoft"
) {
id
name
}
}

35
type Mutation {
createCompany(
name: String!
): Company
addLocation(
companyId: ID!,
): Location
}
name: String!
}
city: String!
postalCode: String!
Country: String!
}
mutation {
createCompany(
name: „Microsoft"
) {
id
name
}
}
{
"data": {
"createCompany": [
{
"id": "4711",
"name": "Microsoft"
}
]
}
}

36

37
type Mutation {
issueCard(amount: Int!): IssueCardResult
# ...
}
type IssueCardResult {
id: ID!
amount: Int!
}
Schema

37
type Mutation {
# ...
}
id: ID!
amount: Int!
}
Schema
mutation {
issueCard(amount: 256) {
id
}
}
Mutation

37
type Mutation {
# ...
}
id: ID!
amount: Int!
}
Schema
mutation {
issueCard(amount: 256) {
id
}
}
Mutation
Response
{
"data": {
"issueCard": {
"id": "4711"
}
}
}

38
type Mutation {
redeemCard(cardId: ID!, amount: Int!): RedeemCardResult
# ...
}
type RedeemCardResult {
remainingAmount: Int!
}
Schema

38
type Mutation {
# ...
}
}
Schema
mutation {
redeemCard(
cardId: "4711",
amount: 20
) {
remainingAmount
}
}
Mutation

38
type Mutation {
# ...
}
}
Schema
mutation {
redeemCard(
cardId: "4711",
amount: 20
) {
remainingAmount
}
}
Mutation
{
"data": {
"redeemCard": {
"remainingAmount":
236
}
}
}
Response

39
type Mutation {
increaseCredit(cardId: ID!, amount: Int!):
IncreaseCreditResult
# ...
}
}
Schema

39
type Mutation {
# ...
}
}
Schema
mutation {
increaseCredit(
cardId: "4711",
amount: 100
) {
remainingAmount
}
}
Mutation

39
type Mutation {
# ...
}
}
Schema
mutation {
increaseCredit(
cardId: "4711",
amount: 100
) {
remainingAmount
}
}
Mutation
{
"data": {
"increaseCredit": {
"remainingAmount":
336
}
}
}
Response

40
type Mutation {
issueCard(amount: Int!):
IssueCardResult
redeemCard(cardId: ID!, amount: Int!):
RedeemCardResult
revokeCard(cardId: ID!):
CardRevocationResult
revokeTransaction(cardId: ID!, transactionId: ID!):
TransactionRevocationResult
}
Schema

40
type Mutation {
issueCard(amount: Int!):
IssueCardResult
redeemCard(cardId: ID!, amount: Int!):
RedeemCardResult
revokeCard(cardId: ID!):
CardRevocationResult
revokeTransaction(cardId: ID!, transactionId: ID!):
TransactionRevocationResult
}
Schema
Alle Interaktionen haben eine fachliche
Bezeichnung

44
CQRS/ES
Command & Query Responsibility Separation

45
Klassische Architekturen
• Es gibt ein zentrales Daten-Modell
• Der Zugriff auf alle relevanten Daten der
Applikation erfolgt über das Daten-Modell
• Das Daten-Modell wird sowohl für
schreibende als auch lesende Zugriffe
verwendet
• Damit verbunden muss dieses Datenmodell
auch alle Use Cases abbilden können
Data Model
Data
Store
W
r
i
t
e
R
e
a
d

46
Write
Data Model
Data
Store
Write
(Comma
nd)

46
• Mit CQRS, sind schreibende (commands)
und lesende (queries) Zugriffe getrennt
• Commands definieren, welche Änderung
durchgeführt werden sollen
• Die zugehörige Command Handler
implementiert die fachliche Logik
Write
Data Model
Data
Store
Write
(Comma
nd)

46
• Mit CQRS, sind schreibende (commands)
und lesende (queries) Zugriffe getrennt
• Commands definieren, welche Änderung
durchgeführt werden sollen
• Die zugehörige Command Handler
implementiert die fachliche Logik
• War ein Command erfolgreich, wird aus
dem neuen Zustand ein Read Model
abgeleitet (Projection)
Write
Data Model
Data
Store
Write
(Comma
nd)
Read
Data Model
Data
Store
Read
(Query
Projection

47
Read Model Projections
• Es gibt keine zwingende 1:1
Beziehung zwischen Write und Read
Model
• Es können beliebig viele Read
Models existieren
• Ein Read Model kann für einen
spezifischen Einsatzzweck optimiert
werden
Read
Data Model Y
Data
Store
Read
(Query
Read
Data Model X
Data
Store
Read
(Query
Projection

49
Sequenz der Events
• Beim Event Sourcing wird der Zustand der Daten in
Form einer Sequenz von Events abgebildet
• Diese Events werden nicht geändert
• Änderungen erfolgen durch das Hinzufügen neuer
Events

49
Sequenz der Events
Events
{
"FirstName": "Maria",
"LastName": "Strong"
}
CreateContactEvent

49
Sequenz der Events
Events
{
}
CreateContactEvent
{
"LastName": "Fisher"
}
NameChangedEvent

49
Sequenz der Events
Events
{
}
CreateContactEvent
{
"LastName": "Fisher"
}
NameChangedEvent
{
"email": "m.f@aol.com"
}
EMailAddressChangedEvent

50
CQRS/ES
Event Sourcing
kombiniert mit

51
Command Handling mit Events
Write Model
Command
Handling
Logic
Event
Store

51
Write Model
Command
Handling
Logic
Event
Store
1
1. Schreiboperation wird
gestartet (Command)

51
Write Model
Command
Handling
Logic
Event
Store
1
2
gestartet (Command)
2. Der Zustand des Write Model
wird aus der Sequenz der
Events wiederhergestellt
(sourced)

51
Write Model
Command
Handling
Logic
Event
Store
1
2
3
gestartet (Command)
(sourced)
3. Die Command Handling
Logic vergleicht das
Command mit dem Write
Model und führt

51
Write Model
Command
Handling
Logic
Event
Store
1
2
3
4
gestartet (Command)
(sourced)
3. Die Command Handling
Logic vergleicht das
Command mit dem Write
Model und führt
4. Änderungen werden als
Events abgebildet und in
einem Event Store
gespeichert

52
Mehr Möglichkeiten mit Projections
Write Model
Command
Handling
Logic
Event
Store

52
Write Model
Command
Handling
Logic
Event
Store
1
1. Events werden, wie
bereits beschrieben, im
Event Store gespeichert

52
Write Model
Command
Handling
Logic
Event
Store
2
1
2. Bei der erfolgreichen
Persistierung, wird der
Event auch über einen
Event Bus verteilt
Event Bus

52
Write Model
Command
Handling
Logic
Event
Store
2
3
1
2. Bei der erfolgreichen
Persistierung, wird der
Event auch über einen
Event Bus verteilt
3. Basierend auf diesen
Events, können viele
verschiedene
Projektionen erstellt oder
auch andere Integration
geschaffen werden
Event Bus
Read Model X Read Model Y Read Model Z
eMail
Notification
Analytics

54
GitHub: dxfrontiers/beyond-rest-and-crud-talk

55
Mutations
&
Mutation
Mapping
Queries
&
Query
Mapping

55
Write Model
(Aggregate)
Mutations
&
Mutation
Mapping
Queries
&
Query
Mapping

55
Write Model
(Aggregate)
Command
Handling
Logic
Mutations
&
Mutation
Mapping
Queries
&
Query
Mapping

55
Write Model
(Aggregate)
Command
Handling
Logic
Event
Store
Mutations
&
Mutation
Mapping
Queries
&
Query
Mapping

55
Write Model
(Aggregate)
Command
Handling
Logic
Event
Store
Event Bus
Mutations
&
Mutation
Mapping
Queries
&
Query
Mapping

55
Write Model
(Aggregate)
Command
Handling
Logic
Event
Store
Event Bus
Mutations
&
Mutation
Mapping
View Model
Updater
Queries
&
Query
Mapping

55
Write Model
(Aggregate)
Command
Handling
Logic
Event
Store
Event Bus
Mutations
&
Mutation
Mapping
View Model
Updater
(Spring Data)
Repository
Queries
&
Query
Mapping

55
Write Model
(Aggregate)
Command
Handling
Logic
Event
Store
Event Bus
Mutations
&
Mutation
Mapping
View Model
Updater
DB
(Spring Data)
Repository
Queries
&
Query
Mapping

56
IssueCardCommand
RedeemCardCommand
IncreaseCreditCommand
RevokeCardCommand
RevokeTransactionCommand

56
IssueCardCommand
RedeemCardCommand
RevokeCardCommand
CardIssuedEvent
CardRevokedEvent
RedeemedEvent
CreditIncreasedEvent
TransactionRevokedEvent

GiftCardTransaction
56
IssueCardCommand
RedeemCardCommand
RevokeCardCommand
CardIssuedEvent
CardRevokedEvent
RedeemedEvent
CreditIncreasedEvent
TransactionRevokedEvent

58
@Controller
class MutationController(
private val gateway: CommandGateway
) {
@MutationMapping
fun issueCard(@Argument amount: Int): IssueCardResult {
val id = UUID.randomUUID().toString()
gateway.sendAndWait<Unit>(
IssueCardCommand(
id = id,
amount = amount
)
)
return IssueCardResult(id, amount)
}
}
type Mutation {
# ...
}

59
@Controller
) {
@MutationMapping
IssueCardCommand(
id = id,
amount = amount
)
)
}
}
type Mutation {
# ...
} • Die Spring Boot Integration
für GraphQL basiert auf
dem Controller-Konzept

60
@Controller
) {
@MutationMapping
IssueCardCommand(
id = id,
amount = amount
)
)
}
}
type Mutation {
# ...

61
@Controller
) {
@MutationMapping
IssueCardCommand(
id = id,
amount = amount
)
)
}
}
type Mutation {
# ...
• GraphQL-Spezifische
Mapping-Annotationen
definieren die Handler

62
@Controller
) {
@MutationMapping
IssueCardCommand(
id = id,
amount = amount
)
)
}
}
type Mutation {
# ...
• Zentrales Element sind die
Commands

63
@Controller
) {
@MutationMapping
IssueCardCommand(
id = id,
amount = amount
)
)
}
}
type Mutation {
# ...
Commands
• Commands werden über
den CommandGateway
verschickt

64
@Controller
) {
@MutationMapping
IssueCardCommand(
id = id,
amount = amount
)
)
}
}
type Mutation {
# ...
Commands
• Commands werden über
den CommandGateway
verschickt

65
@MutationMapping
fun redeemCard(
@Argument cardId: String,
@Argument amount: Int): RedeemCardResult {
val transaction =
gateway.sendAndWait<GiftCardTransaction>(
RedeemCardCommand(
id = cardId,
amount = amount
)
)
return RedeemCardResult(transaction.remainingAmount)
}
type Mutation {
# ...
}

67
var amount by Delegates.notNull<Int>()
var revoked = false
@CommandHandler
fun handle(cmd: RedeemCardCommand): GiftCardTransaction {
if (revoked)
throw IllegalStateException("card has been revoked")
if (cmd.amount <= 0)
throw IllegalArgumentException(
"invalid amount ${cmd.amount}")
if (cmd.amount > amount)
„insufficient card credit")
val transactionId = newTransactionId()
val e = RedeemedEvent(
id = id,
transactionId = transactionId,
amount = -cmd.amount,
remainingAmount = amount - cmd.amount
)
applyEvent(e)
return e
}

68
var revoked = false
@CommandHandler
if (revoked)
id = id,
)
applyEvent(e)
return e
}
• Der Command Handler führ
eine Validierung des
Commands durch

69
var revoked = false
@CommandHandler
if (revoked)
id = id,
)
applyEvent(e)
return e
}
Commands durch
• Nach erfolgter Validierung
wird ein Event mit dem
neuen Zustand erzeugt

70
var revoked = false
@CommandHandler
if (revoked)
id = id,
)
applyEvent(e)
return e
}
Commands durch
• Nach erfolgter Validierung
wird ein Event mit dem
neuen Zustand erzeugt

72
type Query {
giftCard(id: ID!): GiftCard
}
type GiftCard {
id: ID!
amount: Int!
revoked: Boolean!
transactions: [GiftCardTransaction!]!
}
type GiftCardTransaction {
transactionId: ID!
amount: Int!
description: String!
}

73
@Entity
data class GiftCardTransactionEntity(
@Id
@GeneratedValue
var id: Long? = null,
var giftCardId: String,
var transactionId: Int,
var amount: Int,
@Column(length = 100)
var description: String
)
@Entity
data class GiftCardEntity(
@Id
var id: String,
var revoked: Boolean = false,
var amount: Int = 0
)
type Query {
giftCard(id: ID!): GiftCard
}
type GiftCard {
id: ID!
amount: Int!
revoked: Boolean!
transactions: [GiftCardTransaction!]!
}
type GiftCardTransaction {
transactionId: ID!
amount: Int!
description: String!
}

74
class GiftCardTransactionRepositoryUpdater(private val repo: GiftCardTransactionRepository) {
@EventHandler
fun on(e: CardIssuedEvent) {
// we create a "virtual" transaction that represents the issuing
repo.save(
GiftCardTransactionEntity(
giftCardId = e.id,
transactionId = 0,
amount = e.amount,
remainingAmount = e.amount,
description = "Gift Card issued"
)
)
}
@EventHandler
fun on(e: GiftCardTransaction) {
repo.save(
GiftCardTransactionEntity(
giftCardId = e.id,
transactionId = e.transactionId,
amount = e.amount,
description = when(e) {
is RedeemedEvent -> "Redeemed"
is CreditIncreasedEvent -> "Credit increased"
is TransactionRevokedEvent -> "Transaction ${e.revokedTransactionId} revoked"
else -> ""
}
)
)
}
}

75
@Controller
class QueryController(
private val giftCardRepository: GiftCardRepository,
private val giftCardTransactionRepository: GiftCardTransactionRepository
) {
@QueryMapping
fun giftCard(@Argument id: String) = giftCardRepository
.findById(id).orElseThrow {
GraphqlErrorException.Builder()
.errorClassification(ErrorType.NOT_FOUND)
.message("Gift card with id $id not found")
.build()
}
@SchemaMapping(typeName = "GiftCard", field = "transactions")
fun transactions(parent: GiftCardEntity) =
giftCardTransactionRepository
.findByGiftCardIdOrderByTransactionId(parent.id)
}

76
Thank you for listening!
Any Questions?
https://blog.digitalfrontiers.de
https://www.digitalfrontiers.de
@tellme_francois
github.com/fernanfs
François Fernandès
Senior Solution Architect
Photo by Matt Walsh on Unsplash

Beyond REST and CRUD: CQRS/ES mit GraphQL

Recommandé

Recommandé

Contenu connexe

Similaire à Beyond REST and CRUD: CQRS/ES mit GraphQL

Similaire à Beyond REST and CRUD: CQRS/ES mit GraphQL (14)

Beyond REST and CRUD: CQRS/ES mit GraphQL