neděle 18. března 2018

Jak psát stabilní kód v JavaScriptu?

Pokud se rozhodnete, že v JavaScriptu napíšete větší část kódu, tak narazíte na to, že bez podpůrných nástrojů se z této cesty může stát peklo. Existuje velké množství vývojářů, kteří Vám řeknou, že JavaScript je bastl a nedá se v něm smysluplně napsat nic jiného, než pár drobností na rozhýbání webu. Opak je pravdou. V současné době je JavaScript nejuniverzálnějším jazykem na světě.

Je vcelku jedno, zda v JavaScriptu píšete aplikace typu backend, web, mobil, desktop, příkazy pro konzoli či třeba cloud funkce. Stále byste se měli snažit o to, abyste svůj kód zapsali tím nejlepším možným způsobem.

JavaScript se za posledních několik let výrazně změnil. Dostali jsme se do stavu, kdy existují dvě skupiny programátorů.

První skupinou jsou ti, kteří ignorují nové ECMAScript specifikace a JavaScript zapisují "starým způsobem". Do této skupiny často spadají lidé, kteří potřebují občas rozhýbat určitou část webu a JavaScript chápají jako jazyk, který přímo vykoná webový prohlížeč. O této skupině vývojářů se dá říci, že vlastně neumí v současném JavaScriptu programovat.

Druhou skupinou jsou vývojáři, kteří umí využít věci jako je Node.js, Babel, Typescript, apod. Kód v JavaScriptu zapisují v nových ECMAScript specifikacích a fakticky jsou schopni z tohoto jazyka často vytěžit maximum. Jedná se o naprosto jiný svět, než je tomu v případě první skupiny.

Abych Vám toto předal trochu více exaktněji, podívejte se na následující příklad, který ilustruje rozdíl mezi první a druhou skupinou:
// prvni skupina
function oldWay(options) {
    return {
        name: options.name,
        hello: function () {
            return 'Hello ' + options.name;
        }
    }
}

// druha skupina
const newWay = ({name}) => ({name, hello: () => `Hello ${name}`});

console.log(oldWay({name: 'Old way'}).hello());
console.log(newWay({name: 'New way'}).hello());

Tento kód je založen na využití arrow functions, string interpolation a destructuring assignment. Věřte, že je to jen část vlastností, které nové ECMAScript specifikace nabízí. Teď ruku na srdce, pokud je zde čtenář té první skupiny, poznal by, že ten druhý zápis ve výsledku dělá tu samou věc? Na JavaScript se dá koukat jako na dva jazyky. Na jazyk před ECMAScript 6 a jazyk s ECMAScript 6 a vyšší.

Ale pojďme zpět. Jak zajistit to, abychom v JavaScriptu byli schopni psát stabilní kód, který se nám nerozsype s novou posilou v týmu či tím, že někdo bude psát "starým" a někdo "novým" způsobem?

Airbnb JavaScript Style Guide

První věcí, kterou by každý JavaScript programátor měl začít je, že si přečte a osvojí si style guide, tedy zápis JavaScript kódu. K tomtu účelu se výborně hodí následující příručka Airbnb JavaScript Style Guide.
Dokud si toto neosvojíte, těžko se můžete považovat za seniornějšího JavaScript programátora.

Typescript / Flow

Pokud to s JavaScriptem myslíte skutečně vážně, určitě byste se měli snažit o to, abyste tento jazyk obohatili o statickou typovou kontrolu. Jelikož je JavaScript dynamicky typovaný jazyk, tak v případě, že se Vám projekt v JavaScriptu rozšíří, tak bez typové kontroly je jakýkoli refactoring roven ruské ruletě. Osobně preferuji Typescript a důvody proč, jsem sepsal v článku Proč právě Typescript.

Typescript strict mode

Součástí Typescriptu je i možnost nastavení striktního módu. Toto nastavení se jmenuje přímo "strict". Co se díky tomutu módu vše zapne, najdete v manuálu: https://www.typescriptlang.org/docs/handbook/compiler-options.html

ESLint / TSLint

Další nezbytnou součástí je ESLint (v Typescriptu TSLint). Linting, nebo-li "lustrování" kódu slouží k tomu, aby Vám nadával za to, že jste kód nezapsali zrovna tím nejlepším způsobem. Například Vám řekne, že jste napsali function, místo toho, abyste použili arrow function, že jste string zapsali ve špatných uvozovkách, že jste překročili limit počtu znaků na řádku, apod.
I když možná budete tento linter na začátku nenávidět, tak věřte, že je to dočasné. Časem totiž poznáte, že je to velice dobrý sluha. Dá se říci, že Vás naučí správně zapisovat JavaScript kód.

Prettier

Dalším skvělým pomocníkem je Prettier. Tento nástroj slouží k tomu, že za Vás automaticky formátuje kód. K čemu je to vlastně dobré?
Osobně pracuji tak, že když píšu kód, tak automaticky stále spouštím dvě základní operace nad kódem: "Format code & Optimize imports". Dělám to tak už roky a jsem přesvědčen, že by toto měl dělat každý vývojář. Každý moderní vývojový nástroj (Atom, WebStorm, Visual Studio Code, apod) má tyto dvě operace k dispozici.
Ve chvíli, kdy pracuji na projektu, kde je více lidí, tak bez automatického formátu vzniká problém. Co dokáže naprosto otrávit je, když automaticky formátujete kód jen v editoru a najednou uděláte změny i tam, kde jste vůbec nepracovali. Git Vám poté hlásí, že poslední změnu na daném řádku jste udělali Vy a přitom to není vůbec pravda.
První variantou je, že všem vývojářům přikážete, že musí používat jedno IDE a jeden styl formátování. A věřte, to je to poslední, co chcete dělat. Ne každý chce třeba psát kód v IntelliJ IDEA. Proto zde máme Prettier. Nástroj, který za nás určí pravidla a vy se jim automaticky přizpůsobíte, ať už píšete v poznámkovém bloku či třeba v Atomu.
Druhou důležitou vlastností je to, že Prettier Vám formátuje kód tak, aby správně doplnil závorky, středníky, atd, podle jasně definovaného style guide.

Integrace TSLintu a Prettier s Gitem

Nyní se pojďme podívat na to, jak využít TSLint a Prettier při práci s Gitem. Berme v potaz, že již máte projekt v Gitu. Projekt je v Typescriptu a jedná se o React aplikaci.

Nejprve do projektu přídáme závislost na tslint a tslint-react:
npm i -D tslint tslint-react

Poté do projektu přidáme soubor tslint.json:
{
  "extends": [
    "tslint:recommended",
    "tslint-react"
  ],
  "rules": {
    "max-line-length": [
      false,
      160
    ],
    "semicolon": [
      true,
      "always",
      "ignore-bound-class-methods"
    ],
    "quotemark": [
      true,
      "single",
      "jsx-double"
    ],
    "member-ordering": [
      true,
      "variables-before-functions"
    ],
    "ordered-imports": false,
    "interface-name": false,
    "object-literal-key-quotes": [
      true,
      "as-needed"
    ],
    "object-literal-sort-keys": false,
    "no-object-literal-type-assertion": false,
    "no-empty-interface": false,
    "jsx-no-multiline-js": false,
    "jsx-boolean-value": false,
    "member-access": false
  }
}

Do package.json stačí přidat následující skript:
"scripts": {
    "tslint": "tslint -c tslint.json 'src/**/*'"
}

A poté spustit:
npm run tslint
Hlásí Vám tslint chybu? Pokud ano, tak nezbýbá, než ony chyby opravit :)

Nyní pojďme přidat prettier:
npm i -D husky prettier pretty-quick
Současně s knihovnou prettier nainstalujeme knihovnu husky, která slouží k tomu, že vytvoří git hook.

Dále v projektu vytvoříme soubor .prettierrc.json:
{
  "printWidth": 160,
  "tabWidth": 4,
  "parser": "typescript",
  "singleQuote": true,
  "bracketSpacing": false,
  "trailingComma": "all",
  "arrowParens": "always"
}

Jelikož použijeme pretty-quick pro provedení automatického formátování, je třeba definovat soubor .prettierignore, ve kterém určíme adresáře a soubory, které z automatického formátovaní chceme vynechat:
.circleci/
.next/
dist/
package.json
package-lock.json

Poté, co máme základní konfiguraci hotovou, nezbývá, než obohatit náš package.json:
"scripts": {
    "tslint": "tslint -c tslint.json 'src/**/*'",
    "precommit": "pretty-quick --staged && npm run tslint"
}
A nyní stačí zkusit provést commit do gitu :)

Toto řešení je postavené na tom, že používáte Git. Před tím, než se provede samotný commit do Gitu, tak se nejprve spustí formát kódu a poté se překontroluje pomocí TSLintu. Pokud máte něco špatně, commit se neprovede. Pokud Vám nevyhovuje precommit, můžete využít i možnost prepush, tedy před tím, než se provede push do remote git repozitáře. Nicméně výsledkem je, že se Vám do společného Git repozitáře vždy dostane pouze kód, který je spravné formátovaný a zkontrolovaný pomocí linteru.

Kromě Git hooku je určitě vhodné, abyste toto provedli ještě v CI. Tedy ve vašem nástroji na continuous integration. V našem případě se jedná o CircleCI, kde pouze spustíme samotný příkaz npm run tslint a tím zajistíme, že před nasazením na server nemáme v kódu něco špatně.

Závěr

Zajistit štábní kultruru v JavaScript projektech není složitá záležitost. Celé je to pouze o tom, že čím déle budete věci jako je TSLint či Prettier ignorovat, tím víc práce v budoucnu budete mít.
Také je dobré zmínit, že nelze nekriticky spoléhat na tyto nástroje. Stále je pouze na Vás, zda kód, který napíšete je nakonec funkční. Nejsou to nástroje, které Vás například zbaví nutnosti psát unit testy.
A co vy? Používáte některé ze zmíněných nástrojů?

pátek 2. března 2018

GraphQL na reálném projektu

Pokud při vývoji backend API začnete uvažovat o náhradě RESTu za GraphQL, tak Vám gratuluji, protože jste s největší pravděpodobností zvolili správně :)

Psát o výhodách samotného GraphQL je asi zbytečné. Stačí jen nekriticky říct, že: "Konečně máme smysluplný způsob jak získávat data z backendu na frontend."

GraphQL můžete implementovat v několika jazycích. Počínaje Javascriptem a třeba Javou konče. Nicméně, pokud to s GraphQL myslíte vážně, určitě bych se raději vydal cestou javascriptu. Důvod je čistě pragmatický a to ten, že v javascriptu budete mít nejlepší podporu a i samotní autoři tento jazyk berou jako výchozí.

Reálný projekt s GraphQL

V současné době naše firma ApiTree pracuje na projektu, který vyžaduje tvorbu veřejného API a také tvorbu uživatelského portálu, který používá právě zmíněné GraphQL API.

Pro tento projekt jsme zvolili následující technologie:

  • Typescript
  • Next.js/React
  • Apollo
  • GraphQL
  • Node.js
  • Express
  • CosmosDB/MongoDB
  • Kubernetes

Tím, že na projektu pracuje více vývojářů, tak jsou rozděleni na své sféry vlivu. I přes to, že používáme jeden jazyk, tak je velice náročné nechat vývojáře stále přepínat mezi psaním backendu pomocí Mongoose a frontendu v podobě Next.js.

Pokud bychom vývoj rozdělili na backend a frontend, tak společným prvkem se stává samotné GraphQL schéma. Toto schéma potřebují znát obě strany.

Pro naše účely jsme tedy rozdělili projekt na několik systémů:

  • Backend - Express, GraphQL Apollo server, Mongoose
  • GraphQL - GraphQL schéma, GraphQL Apollo mock server
  • Frontend - Next.js / React, GraphQL Apollo client

Strana backendu a frontendu je asi zřejmá, proto se pojďme spíše podívat, proč jsme zvolili samostatný projekt pro GraphQL API.

Projekt GraphQL schéma

Když jsme přemýšleli jak nejjednodušeji napsat GraphQL schéma, skončili jsme samozřejmě u toho, že píšeme čisté schéma v souborech s příponou *.graphql. Definice tohoto schématu obsahuje vše co potřebujeme. Definuje query, mutace, nabízí i jednoduchou dokumentaci v podobě description nad jednotlivými graphql objekty a atributy.

Toto samotné schéma nic samo neumí, pouze definuje jak API bude vypadat.

Jelikož používáme Typescript, hodilo se nám, abychom z daného GraphQL schéma vygenerovali typovou definici, kterou poté použije jak backend, tak frontend. K tomuto účelu nám dobře posloužila knihovna GraphQL Code Generator. Poté jsme celý projekt vzali a vytvořili z něj NPM balík pomocí npm publish.

Nyní máme k dispozici GraphQL schéma s Typescript definicemi jak pro frontend tak pro backend.

Vedle toho jsme tento projekt využili ještě k jedné věci a tou je tvorba mock serveru. Tvorba tohoto mock serveru byla velice jednoduchá. Vzali jsme samotný soubor graphql a poslali ho do metody addMockFunctionsToSchema z knihovny graphql-tool. Pokud vezmeme samotné schéma, tak tato metoda nám nabízí výchozí mocky v podobě předem definovaného řetězce na string, number, apod. Nicméně tato volba je přepisovatelná, stejně jako implementování metody resolve. Zjednodušeně se dá říci, že napíšeme graphql schéma, pošleme do gitu a CircleCI nám zajistí jak tvorbu NPM balíčku pro frontend a backend, tak nám dále v Kubernetes vystaví mock server, který rovnou můžeme volat.

Závěr

Psát o tom, jak pomocí Apollo frameworku volat GraphQL v React komponentách je asi zbytečné, k tomu stačí jednoduchý tutoriál.

Na straně backend serveru je to stejné. Vezmeme graphql definici a jen dopíšeme resolve metody. Ve spojení s Mongoose a samotnou typovou definicí z GraphQL schématu, máte vlastně hotové kontrolery a jen se dopisuje implementace.

Práce s GraphQL není jen velice rychlá a efektivní, ale i zábavná. Když k tomu připočteme takové věci jako je start Node.js serveru během několika milisekund, tak tvorba GraphQL API vlastně vzniká v realtime čase psaním graphql schéma souboru.

A co vy? Už jste na GraphQL přešli?

Když programátor založí a řídí firmu

Jako malý jsem chtěl být popelářem. Ani ne tak proto, že bych měl nějaký zvláštní vztah k odpadkům, ale hrozně se mi líbilo, jak...