Trek die gordyn van doola se Company Formation API terug

In hierdie pos wil ons 'n kykie bied in die ontwerp en denkproses agter die eerste deel van ons alomteenwoordige API-konsep, waarop ons oor die komende weke en maande sal uitbrei!

Waarom ons 'n API gebou het

As 'n sterk gebruiker-gefokusde maatskappy wat vennootskappe met entrepreneurs aan die begin van hul reis vorm, is ons baie van ons sukses te danke aan die sukses van ons kliënte. Ons is in die suiwerste sin, 'n klantgedrewe maatskappy.

'n Sterk API-fokus in 'n kliënt-sukses-gefokusde domein is 'n verbintenis vir ons. By doola wil ons dieselfde gereedskap as wat ons tot ons beskikking het, in die hande van ons kliënte en vennote gee.

Bou 'n maklik-om-te gebruik API

Ons maak 'n paar gewaagde tegniese keuses by doola om ons kliënte en vennote op hul eie terme te ontmoet, en verkies tegnologie wat hul taal praat eerder as om te verwag dat daardie mense wat met ons API's werk om by ons woordeskat en domein aan te pas. Ons streef na web- en industriestandaarde sodat kundiges in maatskappystigting, belasting en nakoming, bankwese en ander vertikale 'n bekende en doeltreffende API sal vind wanneer hulle met ons nutsmiddels werk.

GraphQL is een van ons belangrikste instaatstellers in hierdie domein, oorspronklik vanaf Facebook omstreeks 2015, GraphQL is oorspronklik ontwerp om mobiele kliënte te help om vinnige navrae te maak teen sulke kenmerke soos die Facebook-tydlyn deur slegs die data te bevraagteken wat dit enige tyd benodig.

GraphQL het intussen baie in gewildheid (en verdeeldheid) gegroei, aangesien dit bekend geword het vir uitstekende dokumentasievermoë, gebruiksgevalle-buigsaamheid en 'n "afgeleë prosedure-oproep"-gebruikstyl.

Tipies (web) API's word in die REST-agtige (REpresentational State Transfer) styl geskryf, REST is 'n patroon wat ontwikkel is deur internetpionier Roy Fielding in die vroeë 2000's in sy Ph.D. tesis en in wese "verleng" die web laag met aansoek semantiek.

REST, HATEOAS, en RDF almal behoort aan 'n kategorie tegnologie wat amper het hul goue era gehad, maar het nooit heeltemal voldoen aan die belofte van universeel interoperabele stelsels wat uitsluitlik op ooreengekome data-uitruiling en RPC-standaarde gebaseer is nie.

In 'n REST-styl API sal 'n formasie API gemodelleer word as 'n "PUT /maatskappye" met 'n data loonvrag wat waarskynlik 'n paar "vorm-data" bevat of, in die huidige tegnologiese klimaat, meer waarskynlik 'n JSON-dokument. Vir 'n eenvoudige geval soos vorming is dit goed, maar die metafoor kan gou afbreek, kanselleer 'n vorming van 'n maatskappy, byvoorbeeld in HTTP+REST sin, kan gemodelleer word as die gebruik van die "SKEE" werkwoord teen dieselfde eindpunt, of 'n "PATCH /companies/:id met 'n loonvrag soos {isCanceled: true},” skielik praat ons nie dieselfde taal as ons eweknieë in sakebelange nie.

Die "POST /graphql" en "mutasie" dele is onvermydelike "geraas" in die API, maar danksy die krag van GraphQL kan die "params" wat gestuur word, tipe-gekontroleer en bekragtig word deur die kliënt, en die interaktiewe blaaibare dokumentasie kan gebruik word met outovoltooiing om te werk met ons API in 'n IDE (geïntegreerde ontwikkelingsomgewing) makliker. Nadat die versoek gestuur is, weet die kliënt onmiddellik, in die voorbeeld hierbo, of dit 'n sukses was of nie, en indien dit 'n sukses was, kan hulle die maatskappy-kenmerke onmiddellik kies. “Maatskappye” in die API het duidelik baie meer eienskappe, en danksy die verwysingsdokumente, kan individue, kliënte, ons vennote en onsself beide lae- en hoëtrou-koppelvlakke bou bo-op outomatisering, gebruikerskoppelvlakke of enige gebruiksgeval.

GraphQL is die tegnologie wat ons in staat stel om ons tegnologie aan te pas by die oplossings in die regte wêreld op 'n bekende manier, in GraphQL is hierdie soort gebruiksgevalle natuurlik:

Sonder 'n gedwonge pseudo-hiërargiese aard van die REST-agtige API, en die gedwonge kartering van gebruikersvoorneme in een van die vyf REST-werkwoorde (“KRY","PUT","PATCH","POS","DELETE“), bied ons baie meer vryheid om die gebruiksgevalle vanuit die perspektief van verskeie akteurs en entiteite in die ingewikkelde wêreld van vorming en die bedryf van 'n besigheid vas te lê.

Die toekoms is doola API

Ons doen baie interessante dinge in ons API, en GraphQL stel ons in staat om voort te gaan om te innoveer. Ons sal meer en meer oor ons API skryf, byvoorbeeld oor ons gedesentraliseerde stawing- en magtigingsdiensontwerp, ons datamodelontwerp, en inderdaad ook ons ​​verhouding met AWS AppSync, en hoe dit 'n instaatsteller is vir multifunksionele ingenieurspanne om snelheid in 'n veelkleurige tegniese omgewing te handhaaf.

Die Company Formation API en die ondersteunende boilerplate is net die eerste plekke wat ons kies om te gaan!