Devaajasemmat jatkuvat: GraphQL-konferenssi lokakuussa Helsingissä

Perttu Tolvanen

Viime vuosina web-alan konferenssit ovat olleet pääosin tekijöiden itsensä organisoimia, ja tämä suuntaus tuntuu vain jatkuvan. React Finlandin keväällä järjestänyt ryhmä järjestää nyt lokakuussa (18.-19.10.2018) GraphQL:aan keskittyvän konferenssin. Erityisesti Javascriptin ympärillä on ollut aktiivista yhteisötoimintaa jo pidempään, ja GraphQL kuuluu asioihin, jota etenkin Javascript-maailmassa on otettu käyttöön viime aikoina.

Rajapintojen toteutustekniikoissahan REST on ollut viime vuodet vahvassa asemassa, ja varmasti REST:in suosio jatkuu edelleen, mutta GraphQL:aa voinee pitää vähintään erittäin lupaavana REST:in seuraajana kompleksisempien rajapintojen toteutukseen. GraphQL on alunperin Facebookin kehittämä omien mobiilisovellustensa tarpeisiin. Vuonna 2015 Facebook julkaisi sen avoimena koodina. Tämän jälkeen GraphQL:aa ovat lähteneet hyödyntämään etenkin tahot, jotka haluavat tarjota REST:iä monipuolisemman rajapintakerroksen. Vuosi sitten tapahtunut muutos selkeämpään MIT-lisenssiin, on myös edistänyt GraphQL:n suosiota.

Etenkin web-sovellusten kasvu ja monimuotoistuminen on luonut tarpeen rakentaa monipuolisempia rajapintakerroksia. Varmasti eniten huomiota viime aikoina saanut ratkaisu tähän on GraphQL. Lokakuun konferenssi keskittyy siksi pelkästään GraphQL:aan ja sen käytännön soveltamiseen. Konferenssia voisi kuvata “kehittäjiltä kehittäjille” -tyyppiseksi tapahtumaksi, koska kovin yleisluonteisia tai liiketoimintaan keskittyviä puheenvuoroja tapahtumassa ei ole. Täten ainakin jonkinlaiset perusteet GraphQL:stä lienee hyödyllistä olla hallussa konferenssin esitietoina.

Yksi kiinnostavimmista konferenssin puhujista on esimerkiksi Airbnb:llä työskentelevä Adam Miskiewicz, joka kertoo kuinka Airbnb siirtyi GraphQL:n hyödyntäjäksi.

Vierityspalkki haastatteli konferenssia järjestävään tiimiin kuuluvaa Juho Vepsäläistä, joka tunnetaan mm. “Code Ambassador of Finland 2017” -palkinnon Blue Arrow Awardsissa pokanneena kehittäjänä. Kysymykset käsittelevät Javascript-kehitystä, webin ajankohtaisia asioita ja tulevaa konferenssia.

Kysymys: JavaScript on tullut voimalla web-alalle viime vuosien aikana. Vielä on kuitenkin paljon tekijöitä, jotka eivät ole JavaScriptiä ottaneet syvällisesti haltuun. Miten sinä motivoisit heitä?

Juho Vepsäläinen: Webin lähtökohtana oli toimia alustana sivuille (ja sivustoille), joita voida linkittää toisiinsa. Tästä termi web. Ajan kuluessa web on muuttunut ohjelmistoalustaksi.

Webin päälle voidaan toteuttaa monimutkaista logiikkaa ja WebAssemblyn myötä moni vanhempi sovellus löytää tiensä sinne. Voisikin ehkä sanoa että web-selain on ottamassa käyttöjärjestelmän aseman monissa kohdin ja perinteiset työpöytäsovellukset jäävät taka-alalle.

Webin historia huomioiden se ei ole alustana helpoimpia. Toisaalta webin päälle kehittämällä päästään eroon käyttöjärjestelmien välisistä eroista. Eräs uusimmista trendeistä onkin kehittää PWA-mobiilisovelluksia joiden avulla vältytään sovelluskauppojen käytöltä tietyissä tapauksissa.

Näkisin että kehitys jatkuu edelleen ja web muuttuu yhä paremmaksi sovellusalustaksi. Osa ns. JavaScript-väsymyksestä (JS fatigue) on seurausta tästä ilmiöstä. Varsinkin viime vuosina kehitys on ollut nopeaa.

Kysymys: Järjestitte samalla porukalla aiemmin React-konferenssin ja nyt tartutte GraphQL:aan. Kummatkin ovat alunperin Facebookin kehittämiä ja vapauttamia koodikehyksiä, miksi juuri Facebookilta tulevat koodikehykset ovat niin kiinnostavia?

Juho Vepsäläinen: Kyseisten työkalujen takana on huomattava käyttäjämassa. Tässä tapauksessa voidaan puhua ns. ekosysteemiedusta. Ison yrityksen aktiivisesti sponsoroima teknologia voidaan nähdä turvallisempana vaihtoehtona kuin vapaaehtoisten ylläpitämä. Tämä turvallisuus heijastuu ekosysteemiin joka kehittää omia ratkaisujaan ytimen ympärille ja täten tekee alustasta houkuttelevamman.

Suuren yrityksen tuki ei ole tae jatkuvuudesta. Angular 1 voidaan nähdä esimerkkinä tästä. Angular 2 rikkoi takaisinpäinyhteensopivuuden ja tarjosi erilaisen lähestymistavan. Alustojen mukana tulee siis tietty määrä riskiä.

Vue ja webpack tarjoavat esimerkkejä siitä miten kehitystä voidaan tehdä sponsorista huolimatta. Ekosysteemiin mahtuu monia eri kehitysmalleja. Oleellisempaa on tarkastella mitä alustan tai työkalun ympärillä tapahtuu ja harkita eri vaihtoehtoja. Jo työvoiman saatavuus voi olla osasyy tietyn vaihtoehdon houkuttelevuudelle.

Käyttötarpeesta riippuen voi olla järkevää harkita muita vaihtoehtoja valtavirran ulkopuolelta. Tiedän tapauksen jossa yritys korvasi Angularin omalla kevyellä custom-vaihtoehdollaan. Tällöin ylläpitovastuu lankeaa yritykselle itselleen mikä voi olla hyväkin asia koska tällöin mahdolliset muutokset sisältävät vähemmän kitkaa.

Kysymys: GraphQL on melko uusi asia, onko mahdollista että ensi vuonna GraphQL ei olekaan enää se kiinnostavin uusi juttu?

Juho Vepsäläinen: Uskon että GraphQL tulee saavuttamaan vielä suuremman suosion. Tätä puoltaa se seikka että web-sovellusten suosio tulee kasvamaan edelleen ja samalla syntyy painetta kehittää backend-puolta edelleen. GraphQL tarjoaa keinon aggregoida monia eri sovellusrajapintoja yhden rajapinnan taakse. Samalla saadaan siirrettyä osa perinteisestä logiikasta standardin tasolle ja täten säästetään kehityskustannusta.

Voi olla että GraphQL vaatii vielä vuosia ennen kuin siitä tulee useimpien web-kehittäjien hallitsema teknologia. En kuitenkaan usko että se tulee häviämään koska vahva käyttötapaus on olemassa.

Sovellusten lisäksi GraphQL on oiva työkalu sisältörajapintojen kehittämiseen. Ns. headless CMS-trendi ja GraphQL tukevat toisiaan. GraphQL:n avulla sisältö ja sen esitystavat voidaan erottaa toisistaan. Tällä tavoin toteutamme esim. konferenssien sivustot ja mobiilisovelluksen.

Kysymys: Millaisiin rajapintoihin GraphQL sopii mielestäsi paremmin kuin esimerkiksi REST? Milloin pitäisi harkita RESTin vaihtamista GraphQL:aan?

Juho Vepsäläinen: Kuten jo tuli mainittua, näkisin että GraphQL:lle on ainakin kaksi hyvää käyttökohdetta: sovellukset ja sisältö-API:t.

Sovellusten tapauksessa näkymä tai komponentti voi kysyä backendiltä juuri sitä sisältöä mitä se tarvitsee GraphQL-kyselyä käyttäen. Frontend-toteutus voi hakea jo saatavilla olevan tiedon välimuistista ja optimoida varsinaiset kyselyt kehittäjän puolesta.

GraphQL:n aggregoiva luonne helpottaa sisältö-API:en kehittämistä. Frontend-kehittäjän ei tarvitse tietää mistä tieto tulee. GraphQL-API voi rikastuttaa tietoa. Esimerkiksi tietokannan sijaintitieto voidaan geokoodata ja yhdistää API:ssa todelliseen paikkaan. GraphQL-API tarjoaa ideaalin paikan tehdä erilaisia yhdistämisoperaatioita jotka aiemmin saattoivat valua frontend-puolelle.

Kysymys: Mitä GraphQL-konferenssi tarjoaa osallistujille? Onko konferenssin kohderyhmä seniorikoodarit vai kannattaako myös juniorimpien tulla mukaan? 

Juho Vepsäläinen: Otimme React Finlandin opit huomioon tässä tapauksessa. Kaksi neljästä workshopista on suunnattu aloittelijoille. Toinen näistä on ns. diversity-versio ja toinen on tarjolla kaikille. Diversity-workshopin ideana on houkutella konferenssiin väkeä joka ei muuten sinne tulisi ja rikastuttaa tapahtumaa täten.

Tarjoamme myös kaksi workshopia jo GraphQL:ää käyttäville. Marc-André Giroux:n workshop pureutuu skeema-suunnitteluun (kuinka toteuttaa, kuinka siirtyä REST:stä). Nik Graf:n workshop auttaa osallistujia kehittämään olemassaolevia toteutuksiaan edelleen.

Workshop-päivää seuraava konferenssi tarjoaa monta näkymää teknologiaan. Kuulemme esimerkiksi kuinka Airbnb siirsi miljoonan koodirivin koodikantansa käyttämään GraphQL:ää, opimme miten se toimii eri ympäristöissä ja miten saada enemmän irti teknologiasta. Kattaus on varsin kansainvälinen ja aiheet vaihtelevat helpommista vaikeampiin.

Kysymys: Järjestätte konferenssia melko pienellä tiimillä, eikä takana ole isoa kaupallista tahoa, miten tällainen konferenssi eroaa isojen kaupallisten tapahtumajärjestäjien konferensseista?

Juho Vepsäläinen: Eroina voisin mainita ainakin seuraavat:

  • Olemme kaikki kehittäjiä. Tästä johtuen tulokulma konferenssin järjestämiseen on jo varsin erilainen koska haluamme itsekin oppia. Puhujat olemme hankkineet henkilökohtaisten kontaktien kautta.
  • Toimimme toistaiseksi varsin pienellä budjetilla eikä tavoitteena ole tehdä suurta voittoa. Todennäköisesti tulevaisuudessa haluamme kuitenkin viedä tapahtumaan eteenpäin siten että järjestejille jää muutakin kuin hyvä mieli.
  • Koska meillä ei ole pakkoa myydä tiettyä tuotetta tai alustaa, olemme ehkä vapaampia toimimaan kuin muuten. Sponsoroinnin myötä tarjoamme keinon jolla yritykset saavat hieman laajempaa näkyvyyttä kuin muuten. Hyvään rekryyn johtava sponsorointi maksaa helposti itsensä takaisin.

>> Lisätietoa ja liput tapahtumaan GraphQL-konferenssin sivustolta.

Lippujen hinnat alkavat 399 eurosta (pelkkä konferenssi). Workshoppiin osallistuminen lisää hintaa 200-300e.

PS. Vierityspalkin lukijoille on tarjolla kaksi ilmaislippua (pelkkä konferenssi). Liput jaetaan kahdelle nopeimmalle kommentoijalle, jotka kertovat mitä hyvää ja mitä huonoa on kehittäjien itsensä organisoimissa konferensseissa? Miksi kaupalliset seminaarijärjestäjät eivät osaa järjestää koodareita kiinnostavia tapahtumia? (lippu toimitetaan jätettyyn sähköpostiosoitteeseen, ja on henkilökohtainen)

PS. Tilaa Vierityspalkin kerran kuukaudessa ilmestyvä uutiskirje, joka koostaa artikkelit, linkkivinkit, työpaikat ja julkaisut (uutiskirjeellä on jo yli 700 tilaajaa).

Aiheet: tapahtumat

Tagit: , ,

Perttu Tolvanen

Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja omistaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton toimija, joka auttaa asiakkaita suunnittelemaan digitaalisia palveluita, valitsemaan sopivimmat teknologiat ja kilpailuttamaan osaavimmat kumppanit. Pertun yhteystiedot.

Kommentit

  1. Mike says:

    Kehittäjien itsensä organisoimissa konferensseissa hyvää on se, että konferenssin asiasisältö on varmasti koodareille erittäin mielenkiintoista. Huonoa taas voi ehkä olla se, että konferenssi ei välttämättä ota niin hyvin huomioon heitä, joilla ei ole riittävästi teknistä ymmärrystä.

    Kaupalliset seminaarijärjestäjät eivät osaa järjestää koodareita kiinnostavia tapahtumia, koska niiden asiasisällöt eivät johdata koodareita tarpeeksi syvälle itse asiaan.

  2. Marko says:

    Kehittäjiltä kehittäjille -tyylisissä konferensseissa voi odottaa, että aiheita ei jäädä käsittelemään pintapuolisesti, vaan syvennytään teknisiin asioihin ja saadaan kohderyhmää kiinnostava kokonaisuus. Tällaisissa konferensseissa myös yleisö on samanhenkistä, joten kahvitauolla keskustelut ovat aiheista. Huonona puolena voi olla resurssien puute järjestelyiden ja lokaation osalta. React Finlandissa näin ei kyllä ollut.

    Kaupallisten seminaarijärjestäjien tapahtumissa osa ajasta menee helposti aiheisiin liittyvien tuotteiden ja palveluiden markkinointiin, jotka eivät välttämättä ole kehittäjien intresseissä tai päätäntävallassa.

  3. Perttu Tolvanen says:

    Ja Markolle meni se toinen lippu.

    Hyviä pointteja kehittäjäsemmoista, koska aika usein tän tyyppiset semmat on olleet vähän kotikutoisesti järjestettyjä, mutta sekin on selvästi muuttunut, kun pyydetään lipuista reilusti rahaa ja on sponsoreita ja kaikkea, niin suunta on selvästi ammattimaisempaan tällä hetkellä.

    Vähän vaikea myös kuvitella, että nuo kaupalliset järjestäjät kovin helposti onnistuvat devaajasemmojen tekemisessä. Jenkeissä tämä alue on tainnut olla jo pidempään erilaisten aika erikoistuneiden semmajärjestäjien toimintaa, ja sitä kautta myös jokseenkin paikallista toimintaa. Tosin jenkeissä on toki kaikkea mahdollista tällä alueella, mutta myös tämä genre sieltä löytyy, että tehdään hyvin spesiaaleja semmoja kapealle kohderyhmälle.

Jätä kommentti