U lékaře workshop

Úvod

  • Pár slov úvodem
  • Vítek - Infrastruktura a cloud (60 min)
  • Jindra - Proč graphql na serveru? (45 - 60 min)
  • Radim - Proč Graphql na frontendu? (30 - 45 min)
  • Reference (30+ min)
  • 🎉 Diskuze 

Pár slov úvodem

  • Vyrovnání s technickým dluhem
  • 🆒 technologie nejsou všechno 
  • O čem to je 
    • Víme proč to děláme
    • Víme kam se chceme dostat
    • Architektura - systému 
    • Kvalita kódu
    • Pokrytí testy - unit, integrační testy
  • AWS, Graphql etc. jako prostředek
    • technologie nám musejí pomoct
    • nemusíme vyrábět věci, které existují
  • Cíl: spokojený zákazník, bezpečnost, rychlost delivery,...

Grapql na frontendu

Co je těžké na frontend vývoji?

  • Stav aplikace - s REST API
    • model stavu
    • dokumentace REST API
    • definovat jak získáváme data
    • definovat chybové stavy
    • implementace - vuex, redux etc...
    • propojení s komponentou
    • nejlépe dopsat testy 
    • 👉 imperativní popis transferu získaných dat do stavu aplikace

Proč uvažovat o graphql 

  • graphql jako staticky typovaný jazyk pro API
    • jednotný přístup jak vypadá API
    • jasně definované modely
    • konzistence mezi implementací a dokumentací
  • přesun k deklarativnímu přístupu
    • díky jasnému modelu, je možné automatizovat proces transferu dat do stavu aplikace
    • tooling
      • apollo
      • vue-apollo  
      • typescript

Graphql části

  • definice api - schéma
    • skaláry
    • model
      • typy - 🤓 read
      • inputy - ✏️ write
    • queries
    • mutace
    • direktivy - auth, cache control, etc...
  • použití API
    • queries
    • fragmenty
    • mutace
    • subscriptions

Dokumentace s graphql playground

Dokumentace s graphql playground

Sdílení dokumentace prostřednictvím interfaces

Sdílení dokumentace prostřednictvím interfaces

  • @graphl-code/cli - https://graphql-code-generator.com/
  • Vytvoření typecript interfaces, které sedí s API

Konsolidace modelů

  • pomocí fragmentů

Propojení s vue componentou

  • různé způsoby zápisu
    • composition api 🤗
    • option api
    • option api
      + typescript decorators
  • důležitá nastavení
    • query
    • variables
    • fetchPolicy
    • errorPolicy

Showcase

Fetch policy a apollo cache

  • apollo cache automatizuje handlování stavu
  • dobrý sluha ale zlý pán
  • je zapotřebí vědět několik věcí 
    • id všude, kde potřebuji držet referenci
    • fetch policy - kdy se bere z cache, kdy se volá api

Fetch policy a apollo cache

  • apollo plugin
  • jak vypadá aktuální cache
  • jaké objekty jsou nacachované
  • cache se snaží optimalizovat
    volání na server
    • existuje objekt v cache?
    • pokud je to nový objekt
      přidám ho
    • pokud již v cache je
      updatnu objekt
    • proběhne chytrý merge
      toho co je v cache

Mutace

  • u mutace kromě výstupu definuji výstup❗️
  • 👉 update v apollo cache
  • 👉 update component které mají referenci na daný objekt

$Apollo unvitř komponenty

  • přístup k apollo client přímo z kódu
  • možnost refetch queries on demand
  • vytvořit novou query
  • vytvořit novou mutaci

Práce s cache  

  • jak si poradit s pouze lokálními věcmi?
    • local only fields - možnost ještě rozšířit současné schéma
    • local resolvers - bude deprecated
    • reactive variables - nahrazují local resolvers, jednodušší API
  • ruční optimalizace - optimistic responses
    • přístup, přímo k aktuální cache
    • můžu seskládat optimistickou odpověď na query
      ještě než přijde odpověď ze serveru

Error handling 

  • http status kódy
    • 200 - požadavek odbaven (stále ale může obsahovat chybu)
    • 400 - chyba v graphql - nevalidní query, mutation, result
    • 500 - vážná serverová chyba
  • typická odpověď 

Error handling 

  • resolve všech fields, které je možné resolvnout
  • ve výsledku se objeví property errors 
  • errors je pole všech chyb, které se udály při resolve dané query/mutace
  • 🎉 zobrazím data která mám k dispozici

Všechno není tak růžové

  • apollo ulehčuje práci se stavem aplikace 
  • velká míra automatizace - magic 🧙‍♂️
  • trochu jiný error handling -
    • některé errory se špatně odchytávají 
    • odpověď 200 ještě neznamená úspěch
  • API breaking changes
    • i malá změna změna může znamenat pád query
    • dobře navrhovat povinné a nepovinné pole v graphql schéma
  • divné okamžiky - nedojde k update
    • z 99.9 % chybějící ID, například v parent objektu
  • je třeba si zvyknout na práci s lokálními resolvery

 

Všechno není tak růžové 

  • případ se špatně navrženým API
  • dvě existující metody API
    • GET /product 👇
      • { id: 123, ...productProperties, mainVariant: {id: 123, ...variantProperties}}
    • GET /variant 👇 + query parameters
      • { id: 123, ...productProperties, mainVariant: {id: 222, ...variantProperties}}
  • graphql zprostředkovává odpovědi API

Všechno není tak růžové 

  • případ se špatně navrženým API
  • dvě existující metody API
    • GET /product 👇
      • { id: 123, ...productProperties, mainVariant: {id: 123, ...variantProperties}}
    • GET /variant 👇 + query parameters
      • { id: 123, ...productProperties, mainVariant: {id: 222, ...variantProperties}}
  • graphql zprostředkovává odpovědi API
{
  getCategory {
    ...on ProductCategory {
      bestSellers {
        id # 1️⃣
        mainVariant {
          id # 2️⃣ 
          title
          gift
          # 3️⃣ tady chybi fieldy co jsou ve vypisu produktu
        }
        
      }
      productCollection { 
        items {
          ... on Product {
            id # 1️⃣ prvni produkt ve vypisu je stejny jako u prvniho bestselleru
            # ❗️ tady je vice picknutych fieldu            
            mainVariant {
              id # ❗️ 2️⃣ id je ale jine! nez u main varianty u bestselleru
              title
              brief
              currency
              price
              priceRrp
              ...
            }
          }
        }
      }
    }
  }
}

Všechno není tak růžové 

  • apollo error:
    • {stale: true}
  • chyba při serializaci
    cache
  • špatně se odhaluje
    kde vznikla chyba

Diskuze

Reference - projekt mall

Projekt mall

  • Délka projektu
    • leden 2020 - ??
  • Solution architekt
    • Team Qest - Radim Štěpaník
  • Realizace 
    • large scale scrum - 3 týmy
    • business as usual + refaktoring
    • na vývoji nové platformy se v průměru podílelo:
      3x FE, 1-2x BE

Projekt mall - Graphql API

  • Server - Graphql API
    • release process 
    • test coverage
    • business logic
    • REST API connectors
    • graphql
    • nodejs, typescript
  • Sdílení kódu, mezi mobilní 
  • Typescript upgrade
  • Odstraňování technického dluhu

Projekt mall

  • SSR mall web 
    • nuxt, typescript, vue.js
    • propojení se starým řešením
    • zachování stávající funkcionality
    • napojení na stávající systémy
      • ab testing 
      • feature flags
      • konfigurace
    • release management
      • trunk based 
    • integrační testy
      • cypress
      • E2E testy wdio

Projekt mall

  • webové komponenty
    • sdílení komponent mezi jednotlivými týmy a projekty
    • soubor jasně definovaných komponent
    • web jako skládačka
    • oddělení UI a business logiky

Projekt mall

  • Požadavky
    • migrace bez výpadku
    • musíme být schopni odbavovat business požadavky
    • rychlejší, stejně stabilní řešení
    • fallback na staré řešení
    • separace kódu z monolitu (1 mil+ řádků kódu)

Mezi monolitem a naší službou

Jak na migraci k diskuzi?

O čem jsme si povídali?

  • Co nám může pomoct v tvorbě infrastruktury
    • aws
    • cluster pro docker containery
    • aws s3 a  cloudfront pro statické soubory
  • Jak pracovat s graphql 
    • proč se s graphql hezky pracuje na backendu
    • proč se s graphql hezky pracuje na backendu
  • Kde nám tyto principy mohou pomoct
    • jak vytvořit spolehlivé API mezi backend a frontend

Migrace, tech. dluh

  • Co je hlavní motivace 
    • Musí z toho profitovat finální zákazník
      • prostřednictvím například rychlejšího delivery
    • Bezpečnost dat
    • Neznulovat business delivery
    • Stabilita systému

S čím dokážeme pomoct

  • Aws
    • initial setup
    • IaaS
    • architektura
  • Orchestrace a návrh API
  • Návrh Graphql API
  • Předání zkušeností 
    • distribuované systémy
    • organizace kódu
    • realtime komunikace (hezký kandidát na separování) 🎉 showcase 🎉
  • Vývoj 

Programujeme v typescript

  • javascript + statické typování
  • Skvělý tooling pro graphql
  • Sdílení modelu aplikace mezi frontend a backend
  • easy to learn 
    • minimálně pro lidi, kteří jsou zvyklí dělat "weby"
    • zkušenost na nás samotných
    • zkušenost z firem se kterými spolupracujeme
  • Typescript (node.js) vs jiné jazyky
    • lightweight řešení
    • podpora knihoven - mongo (mongoose), sequelize (sql orm), apollo (server)
  • skvělá podpora cloudových providerů

Typescript showcase

  • jednoduchý resolver
    • demonstrace subresolverů
  • jednoduchý testík 

Frontend showcase

  • Graphql playground
  • Stažení interfaces 

Proč nemít jednu databázi

  • rolling updates vs. migrace
    • změna v databázi musí být zpětně kompatibilní nebo je třeba všechnu codebase předem připravit, aby podporovala obě verze
  • konkurentní deploymenty
    • místo častých, nezávislých delivery je deployment velká, koordinovaná událost
  • DB model jako další sdílená knowledge
    • krom API kontraktů je třeba hlídat kód, znát kde jsou reads/writes

Proč nemít jednu databázi

  • z praxe, kdy to ne ideálně dopadlo:
    • model jako sdílená knihovna mezi službami
    • v rámci knihovny i db migrace
    • 👉 nutnost pri zmene modelu na jedne službě updatovat ostatní services
    • 👉 kontrola dependencies na každé service při spuštení - 🧨
  • výhody
    • rychlý start
    • konzistentnost
      modelů
  • nevýhody
    • antipattern
    • s každou
      změnou je nutný změna všude
  • částečné řešení 👉 monorepo

     

Proč nedělat 10 service

  • dependency graph
    • bez vhodné abstrakce chaos
    • bez striktního vrstvení riziko nepředvídatelně vysokých latencí
  • orchestrace a side-effects
    • retry / defer mechanismy
    • rollbacks
    • transaction logs
  • cascading failures
  • downstream corruption propagation

Cesty k úspěchu

  • Ze zdola nahoru 👉 rozšiřujeme to co máme
  • Ze shora dolů 👉 snažíme se co nejdříve přejít do fáze, kdy jsme připraveni vytvářet nové služby
  • vhodné prerekvizity
    • autorizace uživatelů přes stateless JWT
    • rozdělit na SPA, API
    • vystavit core funkcionality přes API pro interní účely
    • abstrakce v legacy kódu aspoň na úrovni služeb

Cesty - 1. pracujeme s tím co máme

  • zamyslet se nad stackem, který použít v budoucnu
  • začít postupně směřovat k lepšímu kódu
  • upgrade systému na současné verze knihoven a enviromentu
  • pokrytí aplikace testy
  • vytvoření stabilního API/Graphql API
  • příprava na škálování aplikace 
  • zaměření se na frontend technologie 
    • přechod na vue 3
    • použití graphql, jiné technologie

Cesty - 1. pracujeme s tím co máme

  • vytvoření stabilního monitoringu a alertingu
    • je zapotřebí vidět do střev ne jen mít high level picture
  • postupné odřezání částí aplikace, které nejsou core
  • dobrá dokumentace a popsání systému 
  • ❗️pozor na obecnou tendenci vývojářů zahodit cokoliv starého a mít možnost vytvářet na zelené louce
  • Začít s oddělením méně důležitých částí aplikace

Cesty - 2. split the monolith

  • Snažíme se dostat do cílového stavu co nejrychleji
  • Oddělit nejdříve zásadní části systému
    • Autorizaci 👉 uživatele 
    • Vytvoření Graphql API
    • Propojit stávající řešením s graphql
    • Graphql jako lightweight proxy
    • Postupně začít rozpadat logiku do jednotlivých služeb
      • nový modernější přístup k tvorbě služeb
        • nodejs, c#, kotlin etc.

Cesty - 2. split the monolith

Aktuální stav

Cesty - 2. split the monolith

Krok č. 1 - Autentizace, user service a GQL Api

Cesty - 2. split the monolith

Krok č. 2 - Odstranění vazeb na staré služby

1. pracujeme s tím co máme

2. split the monolit

  • technologie zůstává php
  • backend - zaměřeno refaktoring stávajícího kódu + dodělání API
  • frontend - (možná) více prostoru na rozvoj a přepis frontend služeb
  • v budoucnu mít možnost vytvářet jednoduše nové služby, async zpracování
    • ​👉 přechod do cloudu ❓
  • zaměřeno na rozvoj architektury
  • co nejrychleji mířit k zahození "starého"
  • použití rychleji nových technologií na backendu
  • neobejde se bez úprav na starém řešení
  • možnost vybrat si "nový" jazyk  - ❗️pozor na multi programovací prostředí (zkušenost)
  • otázka jak moc "rozstřelit" monolit
    • záleží třeba na tom kolik týmů bude v budoucnu

1. pracujeme s tím co máme

2. split the monolit

Transform monolit

Architecture

Infrastructure

Creation of new service

Infrastructure

Creation of new service

Architecture

Prepare monolit for changes

Creation of new service

Prepare monolit for changes

Cesta 1.  Cesta 2.
Plusy ➕ jednodušší dodávání
business features
➕ méně rizikový přechod
➕ nasměřování vývojových kapacit dle potřeby
➕ evoluce ne revoluce
➕ současný stav není tak velká aplikace
➕ rychlejší cesta k novému řešení
➕ v budoucnu rychlejší dodávání
➕ modularizace systému
Mínusy ➖ delší cesta k cílové fázi se kterou jsme spokojeni
➖ pracujeme s legacy kódem, který je třeba narovnat
 
➖ distribuovaný systém 👉více problémů
➖ je třeba dbát na správnou architekturu
➖ riziko při migraci

Diskuze 🧏‍♂️

U lékaře workshop

By Radim Štěpaník

U lékaře workshop

  • 40
Loading comments...

More from Radim Štěpaník