Foto af Chris Becker på Unsplash

Sådan bruges API-første platforme til at opbygge dine websteder hurtigere

Værktøjer som Jekyll, Hugo eller Hexo har populariseret statiske websteder i de senere år. Den såkaldte JAMstack giver dig mulighed for at levere meget dynamisk indhold uden overhovedet lag. Derudover gjorde udvikler-første API'er mulighed for front-end-udviklere til at opbygge endnu mere kompleks funktionalitet. Dette kan de gøre uden at forlade browsersandkassen. Lad os se, hvordan du kan udnytte moderne API-første platforme til at sende en solid prototype af en forretningsapplikation. Den fremgangsmåde, der præsenteres i denne artikel, kan blive et nyttigt aktiv i din løsningsarkiteks værktøjskasse.

Vejledningen består af 2 dele:

  • Den første viser dig, hvordan du designer designet til at få en såkaldt glad sti. Vi opbygger en semi-automatiseret prototype, du kan bruge til at få brugerfeedback på en demosession
  • Den anden forklarer, hvordan man forbedrer automatisering af forretningsprocesser, så appen kan håndtere tidlig trafik i produktionen

Hvad er en API-første platform?

Som Ed Shelley fra ChartMogul beskriver det, er der et par ret svære at gå glip af en sådan tjeneste:

  • Der er INGEN brugergrænseflade (GUI). Eller i nogle tilfælde er der en GUI, men den er sekundær for kerneproduktet.
  • Interaktion med tjenesten sker via et webbaseret API. Dette er en programmatisk måde at forbinde tjenester og overføre data på nettet på en maskinlæselig måde.
  • Værdien af ​​tjenesten er normalt i de data, der er leveret (via API).
  • Prisfastsættelse er ofte brugsbaseret, hvilket betyder, at omkostningerne er baseret på antallet af anmodninger, der fremsættes til API.

Grundlæggende er det, de tilbyder, et sæt af byggesten, som regel i SaaS-modellen. Disse kan du bruge til at konstruere en bestemt funktionalitet med mindre kode. En af de første og sandsynligvis mest bemærkelsesværdige repræsentanter for dette er Stripe.Stripe hjælper med at behandle betalinger. Dog har du måske hørt om andre store fisk for nylig, der er kommet ud af markedet, som Twilio eller Algolia.

Hvorfor bruge en API-første platform?

Lad os starte med en lille ansvarsfraskrivelse. Denne tutorial beskriver, hvordan man udvikler applikationer uden overhovedet serversiden. Vi mener dog, at det ikke er en pragmatisk tilgang til softwarearkitektur.

Snarere vil vi fremhæve nogle dele af dit back-end maskiner, som du ikke behøver at implementere fra bunden. Dette gælder især, når forretningskravene til en bestemt funktion ikke er sat i sten, og dit mål er faktisk at finde ud af dem. Med andre ord for at finde ud af, om funktionaliteten får et positivt svar fra brugerne og i sidste ende har en plads i dit produkt.

På samme tid ønsker du ikke at låse dit produkt ind hos en leverandør, der leverer en out-of-the-box-løsning. Dette skyldes, at du ved, at det før eller senere vil føre til et "løsningshelvede". Og som du har lært, er det svært at vende tilbage derfra.

For at give dig et eksempel kan du forestille dig, at din virksomhed ønsker at oprette en blog. Desuden har de allerede sagt, at de vil udvide det og tjene penge på vejen. Der er 2 implicitte krav, du skal tage i betragtning, før du kommer på en teknisk stak i et sådant scenario:

  • Du vil hurtigt sende blogfunktionaliteten - forretningen kan ikke vente i aldre på en simpel blog.
  • Du ønsker ikke at ende med at jonglere med Wordpress-plugins.

Den type værktøjer, vi vil præsentere, kan være svaret. De giver dig nogle funktionelle byggesten, og din eneste opgave er at tilpasse dem til din virksomhed.

Du bliver glad, fordi du har fuld kontrol over din kodebase. Derudover er ledelsen også glad, fordi de får værdi fra dag 1. Plus, de behøver ikke at betale up-front!

Så lad os nu vise dig, hvordan disse værktøjer kan spare ugers teknisk tid, mens du stadig holder din kodebase åben for ændringer.

Bemærk: De værktøjer, vi vil bruge, fungerer også i serversidetilstand. De tilbyder faktisk mere funktionalitet, når de er tilsluttet ved hjælp af sikre API-nøgler. Så vi synes, det er mere pragmatisk at have det integreret på serversiden. Ikke desto mindre vil vi som et eksperiment kun bruge klientsidefunktionaliteten. Derudover vil vi bruge noget Zapier-lim til at automatisere forskellige forretningsprocesser hurtigt.

nostalgia.io

Vi vil opbygge en markedsplads for de gamle webteknologikonsulenter - nostalgia.io. Hvis du ved nogen chance søger hjælp med et gammelt system baseret på Struts eller Google Web Toolkit, er dette stedet at gå. I den første del af denne tutorial lærer vi, hvordan vi udnytter flere API-første platforme til levering af følgende funktionalitet:

  • Gennemsøgning gennem ældre teknologier
  • Fuldtekstsøgning og filtrering af eksperter
  • Bookingmøder med eksperter
  • Rabat med kuponer

Teknologibunken vil bestå af:

  • Indholdsmæssig - som en database for teknologier og eksperter
  • Algolia - til fuldtekstsøgning
  • Timekit - for tilgængelighedskontrol og booking
  • Typeform - til former
  • Voucherify - til kuponstyring (ansvarsfraskrivelse: dette er vores produkt)

Bemærk: Vi dækker ikke selve godkendelse og betalingsbehandling. Du kan prøve at implementere dem selv som hjemmearbejde (tip: auth0 og Stripe kan være nyttige).

Lad os hoppe ind i koden.

Bemærk 1: For kortfattethed beskriver vi ikke en detaljeret trin-for-trin-guide. Du skal slå de manglende dele op i specifikationerne - heldigvis har API-første udbydere en tendens til at have udviklervenlige dokumenter, omfattende API-reference og snesevis af nyttige guider.

Bemærk 2: der er mange måder, du kan være vært for dit statiske websted på. Vi bruger glitch-udviklingsplatformen, så du nemt kan remixe den og lege med den selv.

Bemærk 3: vi er ligeglad med applikationens udseende og følelse for ikke at skjule integrationsdelen, plus det på en eller anden måde passer til forretningstemaet, er det ikke? :)

Datamodel - indholdsmæssig

Normalt starter applikationens design med en dataforholdsmodel. Dette bør også være den første bekymring for os. Men lad os springe databasen udbyders diskussion et øjeblik og springe direkte ind i modeller. Hvordan det?

Mød Contentful - et hovedløst CMS. Ved hjælp af en skarp forenkling kan du tænke på det som en Wordpress uden front-end.

Det muliggør:

  • udviklere til at levere indholdet tilpasset mediet, det være sig hjemmeside, mobilapp eller VR-enhed - dette gøres gennem RESTful API
  • marketingfolk til at oprette, administrere og offentliggøre indhold uden at skulle beskæftige sig med formateringen - med støtte fra indholdsmodelleringsdashboardet og rich-text editor

Vi bruger Contentful til at oprette 2 basale enheder - Teknologi og ekspert. En ekspert kender en eller mange teknologier. Lad os se, hvor nemt det er at oprette sådanne enheder, tilføje nogle rigtige objekter og vise dem på en statisk side.

Teknologibrowser

Med Contentfuls modelmanager er design af en enhed lige så let som at trække nye felter ind i dataindholdsmodelforvalteren. Der er 8 forskellige typer. Disse inkluderer standard, som en streng eller et nummer. Der er også nogle specifikke typer, som placering eller medier, der har nyttige egenskaber.

Opret en gratis konto. Følg derefter vejledningen om bord for at oprette et mellemrum.

Til sidst oprette din første model, der ligner det, du kan se på skærmbilledet nedenfor:

Nu hvor du har Teknologimodellen, skal du gå til fanen Indhold for at oprette et par tilfælde. Som du kan se, giver Contentful en intuitiv editor til dataregistrering. Det tager sig af datavalidering, lokalisering, publiceringsstatus, versionskontrol og meget mere. Det er først og fremmest en udvikler-første platform. Alligevel tilfredsstiller disse funktioner marketingfolk og indholdsadministratorer også.

Nok klik, lad os komme til kodning. Den første opgave er at vise de teknologier, vi netop har oprettet. For at gøre det bruger vi Contentful JavaScript SDK.

Det gør det nemt at hente teknologier og kommer ned på tre trin:

  • Opret et nyt glitch-webstedsprojekt, indlæs scriptet contentful.js, og initialiser det med de legitimationsoplysninger, du kan finde i API-afsnittet.

Bemærk: der er 2 typer nøgler tilgængelige i Contentful. Den ene er til indholdsstyring og den ene til indholdslevering.
Den første type kan bruges til at oprette, opdatere eller slette nye modeller eller deres forekomster programmatisk.
Den anden giver dig en måde at levere dit indhold til dit websted eller app.
Denne sondring er foretaget af sikkerhedsmæssige årsager. Du ønsker ikke at offentliggøre dine indholdsadministrationsnøgler på dit websted, gør du? Det samme gælder de andre API-første platforme, vi bruger i denne tutorial.

  • Ring til getEntries-metoden. Dette indlæser indholdet i henhold til dine forespørgselsparametre. I vores tilfælde ønsker vi kun at indlæse "Teknologi" enheder. Byg noget frontend oven på dataene. Hvad du får fra Contentful er ren JSON (eksempel). Nu kan du vise det til dine brugere, som du vil. Det er en af ​​de største fordele, når du vil eller skal tilpasse dit indhold til flere enheder.

Se på denne essens:

Kort og sød, er det ikke? Du kan se den samlede effekt her.

Tilføjelse af eksperter og søgningen

Så nu vil vi vise listen over eksperter, når nogen vælger en bestemt teknik. Det skulle svare til det, vi lige har gjort med teknologi for et sekund siden. Men lad os gøre det lidt mere avanceret. Hvad hvis vi vil gøre eksperter søgbare? Tænk på fuldtekstsøgning i deres profiler og også et prisfilter.

Bestemt, du kan bygge det oven på Contentful. Tilføj f.eks. En anden enhed, konfigurer søgemekanik og UI med getEntries, men der er en hurtigere måde. Og ved at sige hurtigere mener jeg både implementeringstid og hastigheden ved indlæsning af søgeresultater.

Vi bruger en anden API-udbyder - Algolia. Deres platform gør det nemt at opbygge og vedligeholde superhurtig fuldtekstsøgning. De tager sig af typotolerance, synonymer, geosearch og andre små problemer. Disse problemer vil du sandsynligvis støde på, når din søgefunktion går til produktion.

Hvordan virker det? Du bruger bare et RESTful API til at fodre deres motor med dataene. Derefter konfigurerer du, hvilke attributter der skal kunne søges, og hvordan resultaterne skal rangeres. Endelig ved hjælp af deres JavaScript SDK kan du levere den øjeblikkelige søgeoplevelse til ethvert websted. Lad os gøre vores eksperter søgbare nu!

Vi starter med at oprette en datamodel i Contentful og skabe et forhold til teknologi-enheden. Derefter opbygger vi et Algolia-indeks og tilføjer vores enheder (JSON-format) til det.

Tilføj en anden indholdsmodel med de felter, du kan se nedenfor:

Bemærk, at vi har oprettet et en-til-mange-forhold ved hjælp af feltfeltet Reference. Vi vil bare reflektere, at enhver ekspert måske kender mere end en teknik. Når du er klar, kan du tilføje nogle eksperter og tildele dem til deres teknologier manuelt. Brug flere teknologier til en af ​​eksperterne.

Du skulle ende med at have en lignende liste:

Og JSON-strukturen ser ud:

Lad os uploade vores eksperter til Algolia. Tilmeld dig en gratis konto, gå til sektionen Indekser og kør NEW INDEX.

Nu er vi nødt til at overføre vores enheder fra Contentful til Algolia. Vi kunne have brugt en dedikeret migrator. Dette er et fantastisk værktøj, der automatisk indlæser dit indhold. Den fjerner derefter, i dette tilfælde overflødigt, de indholdsmæssige systemoplysninger (se kernen ovenfor) fra effektive JSON'er. Det kan også løse forhold. For eksempel i stedet for ID'er, sender du de faktiske navne, når det kommer til “teknologier” -feltet. Endelig synkroniseres det med Algolia-indekset.

Men vi gør det bevidst manuelt. Vi har brug for en lille forbedring af den måde, vi bygger vores indeks på. Derfor er synkronisering af en til en med migratoren ikke en mulighed i vores tilfælde.

Når vi bruger søgeinput på et teknologiside, ønsker vi naturligvis kun at inkludere eksperterne på valgt teknologi i søgeresultaterne. Som du kan se i Ekspert JSON-eksemplet, er teknologier repræsenteret som en række objekter. Problemet er, at du ikke kan opbygge en facet, der filtrerer dataene baseret på et indlejret array af objekter med Algolia.

Hvad de foreslår, er at opdele ekspertobjektet i så mange underobjekter som antallet af teknologier. Så for Javier Hernandez, der kender 2 rammer, bør vi tilføje 2 objekter:

{
  navn: "Javier Hernandez",
  teknologier: {
    navn: "Google Web Toolkit"
    ... // andre egenskaber
  }
  ... // andre egenskaber
}
{
  navn: "Javier Hernandez"
  teknologier: {
    navn: “Apache Struts 1”
    ... // andre egenskaber
  }
  ... // andre egenskaber
}

Som en øvelse kan du oprette et script, der opdeler eksperter og føjer dem til indekset gennem Algolia API. Du har brug for Algolia-autentificeringsnøgler på serversiden. Her er et uddrag, der håndterer den delte logik. Bemærk, at scriptet også renser Contentfuls systeminfo.

Dette gør objekterne lettere vil gøre søgningen hurtigere:

Da vi har 6 eksperter, og 2 af dem kender 2 teknologier, bør vi ende med 8 objekter i indekset. Som et alternativ til API-indsætningsmetoden kan du uploade dem med betjeningspanelet. Når det er uploadet, kan du prøve at bruge søgningen i Dashboard for at se, hvor hurtigt Algolia filtrerer dataene.

Nu er vi næsten klar til at forbinde vores søgning til Algolia. Næsten - fordi vi er nødt til at skabe en facet, der giver os mulighed for at filtrere resultater efter teknologi og pris. Gå til DISPLAY og vælg technology.name og pris i “Attributter til facettering”, og gem derefter.

Endelig kan vi forbinde vores søgning til vores indeks, så den henter og viser resultaterne. Algolia leveres med et avanceret JavaScript-bibliotek, der gør det let som pie.

Se på denne kode:

Bemærk, hvordan vi konfigurerer søgningen til at bruge teknologifilteret i linje 8-10. Se, hvor let det er at justere resultatsiden til en respektive container - linje 28 (skønt det er svært at finde i dokumenterne).

Samlet set med ca. to dusin linjer, og du får dette:

Indtil videre har vi opbygget en simpel ekspertbrowser, der understøtter fuldtekstsøgning og glider. Det er besværligt at tilføje nye eksperter på dette tidspunkt, fordi du først skal manuelt oprette dem i Contentful og derefter synkronisere det med Algolia. Vi automatiserer dette i anden del.

Den gode nyhed er, at du allerede kan bruge denne prototype til at få nogle tidlige feedback til teknologibrowsing og eksperter filtrering. Det næste trin er at oprette siden med ekspertprofiler og aktivere reservation.

Demokoden til søgning kan findes i experts.html.

Bestillinger

Som du måske har gætt, implementerer vi heller ikke kalenderfunktionaliteten fra bunden. Vi bruger Timekit. De tilbyder API + -dashboardet til at administrere kalendere og bookinger for mennesker og ressourcer. Tænk på det som en Google / Outlook-kalendermotor, der er eksponeret med REST API.

Processen med at gøre eksperter bookbare med Timekit er som følger:

  • Opret en ressourceenhed og en tildelt kalenderenhed
  • Opbevar ressource- og kalender-id'er i en tilsvarende ekspertenhed i Contentful
  • Brug Timekit JS SDK til at få vist kalenderen på en eksperts profilside

Og det er det, du har lige fået bookinger i gang! Tro ikke mig? Læs videre:

  • Opret en konto, og start en gratis prøveperiode (der er ingen gratis version).
  • Opret et projekt, hvor du vil definere den grundlæggende kalendermekanik. F.eks. Begivenhedsvarighed, minimumsmeddelelse og påmindelser.
  • Definer, om reservationsanmodninger skal accepteres automatisk eller skal bekræftes manuelt.

Opret for hver ekspert en ressource, og opret en kalender inden for denne ressource. Bemærk, at en ressource muligvis har mere end en kalender.

Dette er en dejlig funktion at huske på, når vi planlægger nogle opgraderinger i Nostalgias forretningsmodel.

Nu skal vi gemme ressourceens e-mail, nyligt oprettede kalender-ID og klientsiden API-nøgle i den tilsvarende ekspertenhed i Contentful.

Du kan redigere ekspertindholdsmodellen og tilføje et JSON-felt ved navn timekit. Rediger derefter ekspertenhederne for at tilføje detaljer om timekit.

Det sidste trin er at få vist den aktuelle kalender på ekspertens profilside. Du kender allerede processen. Medtag et SDK-script og konfigurer det korrekt til at gengive widget'en.

Men denne gang skal vi indlæse 2 biblioteker:

  • Indholdsmæssig - for at indlæse kundens detaljer, inklusive Timekit-legitimationsoplysninger
  • Timekit - for at placere den kalender, der er tildelt en given ekspert

Her er koden:

Vær opmærksom på, hvordan vi kan justere reservationsoplysningerne, såsom tidsvinduer (linje 39). Timekit tilbyder endnu flere tilpasningsmuligheder, så sørg for at læse booking.js-specifikationen.

Effekten sprænger os bare væk. 20 kodelinjer, og vi har vores bookingwidget på plads. Timekit fører tilsyn med hele processen for dig. Det hjælper med at løse konflikter og sender e-mail-bekræftelser til eksperter og kunder.

Det vigtigste er, at denne tilgang er yderst fleksibel. Det hele er i kode. Hvert enkelt stykke af denne mekanisme kan justeres gennem API'en.

Lad os f.eks. Antage, at vi ønsker at gennemgå en reservationsanmodning, inden vi accepterer det. Det sker bare så, at Timekit gør det muligt med et enkelt flag. Sådanne muligheder er den virkelige magt med API-først-løsninger. Sørg for at læse tutorials og docs for at lære alle funktionerne.

Kuponer

Nostalgi er ikke en kendt virksomhed endnu. Vi er nødt til at finde en måde at tiltrække tidlige adoptører på. En af de ældste og mest succesrige metoder er rabatter. En rabat kan muligvis anvendes efter indløsning af en kupon eller på grund af mængden af ​​produkter i indkøbskurven. For at implementere begge tilfælde skal du muligvis bruge Voucherify.

Hvorfor voucherify? Der er et par basale ting, du skal få ret, når du vil håndtere kuponer ordentligt for at spare dig selv masser af teknisk tid:

  • Det unikke ved kuponkoder - At reducere svindel og få præcis sporing af dine reklamekampagner
  • Udvidelig kuponvalideringsmekanisme - Dette er en generisk tilgang, der gør det muligt at tilføje / fjerne / udløbe flere kuponkoder
  • Let overvågning af indløsning - Dette vil besvare spørgsmål om marketing og kundeserviceafdeling fra bat

Du kan tage dig af disse 3 ting selv. Du kan dog få det samme resultat med et par linjer ved hjælp af Voucherify API-slutpunkter. Dermed kan du med det samme glemme misbrug af kuponer, ved at opretholde “if” -stigen, der bekræfter, om koden er aktiv og gyldig. Du kan også afstå fra at give marketingteams resultater med kuponkampagner. Du bor heller ikke ned i logfilerne for at forstå, hvorfor en kundes indløsning mislykkedes.

Lad os oprette 1000 kuponer. Disse sender vi til vores tidlige adoptører. Endelig giver vi kunderne mulighed for faktisk at bruge dem på vores websted til at nyde nedsatte priser.

Tilmeld dig en Voucherify-konto, og gå til kampagneadministratoren for at oprette den første batch med kuponkoder. Lad os sige, at hver kupon har 25% rabat.

I manageren kan du specificere rabatdetaljerne og andre forretningsgrænser. Angiv for eksempel udløbsdatoen, det maksimale samlede beløb eller et specifikt kundesegment, der er berettiget til rabatten.

Når manageren er færdig, kan du begynde at distribuere kuponer gennem forskellige kanaler. Voucherify tilbyder e-mail, sms, push-anmeldelse, intercom eller lodning ud af boksen. Men der er mange andre måder tilgængelige takket være REST API og webhooks.

Inden du sender dem ud, skal du give kunderne en mulighed for at indløse dem. Dette kan opnås ved at bruge indløsningsendepunktet fra API'et. Alligevel kan du også bruge den forudbyggede widget fra voucherify.js.

Voucherify giver dig mulighed for enten at validere eller indløse kuponen.

Valideringen kontrollerer, om:

  • kuponen kommer fra din Voucherify-konto
  • er ikke udløbet eller deaktiveret
  • det svarer til alle forretningsregler

Indløsningen foretager valideringen først og markerer derefter kuponen som brugt. I denne del opretter vi validering kun for at vise kunderne en nedsat pris. I den anden artikel sender vi en indløsningsanmodning, når reservationen er bekræftet.

Medtag voucherify.js-uddrag og eventuelt den tilhørende CSS-fil for et bedre udseende. Indsæt derefter følgende kode:

Biblioteket gengiver en kuponwidget, der automatisk validerer koden mod Voucherify API.

Du kan teste det ud med de koder, vi har genereret med kampagneadministratoren:
* 25% rabat: nstlg-CCAMIDFf, nstlg-wZK4CoLs, nstlg-V8eV9A3p
* $ 5 rabat: uub-nstlg, afl-nstlg, yeq-nstlg
* udløbet kode: VuFF2Wyy

Bemærk, at du nemt kan tilpasse kodemønstre, præfikser og post-fixes kan være nyttigt til sporing og rapportering.

Indsæt nu enhver kuponkode i widgeten og se den tilsvarende rabat, der er anvendt:

n den anden artikel, viser vi dig, hvordan du overvåger de vellykkede og mislykkede kuponindløsninger for at se, om din promo-kampagne er på rette spor.

Voucherify tilbyder meget mere end det. Tjek dokumenter og eksempler for at finde ud af, hvordan man bygger avancerede kampagner og henvisningsprogrammer i dage i stedet for måneder.

Du kan finde reservationssidekoden her (scheduler.html).

Sæt hætten

Vi planlagde at bygge et bevis på koncept til en ny forretningsapplikation - Nostalgia.io. En prototype, vi kan bruge til at vælge de tidlige brugers hjerner. Noget, vi kan levere inden for en anstændig tidsramme, men alligevel ikke et totalt kast.

Forhåbentlig har vi overbevist dig om, at med udvikler-første værktøjer som Contentful, Algolia, Timekit eller Voucherify kan du opnå det. Endnu vigtigere er det, at du kan gøre det uden at konfigurere noget bagvedliggende lag overhovedet.

Det kræver stadig noget manuelt arbejde for at holde data synkroniseret mellem værktøjer. Alligevel udgør fleksibiliteten og hastigheden af ​​iteration af disse API-første værktøjer lige ved hånden.

Disse værktøjer er bestemt ikke alle lyse og lyse. For eksempel støttede vi på disse flere problemer, da vi gennemgik denne artikel:

  • Metoden Contentful getEntry () løser ikke links. Vi måtte i stedet bruge getEntries () for at få en enkelt ekspertenhed med URL til profilbillede
  • Det tog os mere end lidt tid at forstå, hvordan vi kan vise resultater ved hjælp af kolonnelayout (standard er rækker)
  • Timekit tillader ikke hentning af kalenderinstanskonfigurationen ved hjælp af en ekstern id. Det er derfor, vi er nødt til at opbevare kalendertokens i en ekspertenhed i Contentful
  • Voucherify-widgeten giver dig ikke mulighed for at prøve en anden gyldig kode uden at opdatere webstedet

Jeg er sikker på, at der er mange flere af dem. Men du kan arbejde på disse små problemer på langt mindre tid, end du ville bruge til at opbygge disse funktioner fra bunden. Desuden undgår du de alvorlige og tidskrævende arkitektoniske fejl, holdene på disse platforme har gjort før dig.

Projektets kildekode kan findes her. Og demoen er live her!

Hærdning og skalering

Som du kan se, er nogle processer stadig manuelle og dermed kedelige:

  • Tilføjelse af nye eksperter
  • Gør eksperter søgbare
  • Oprettelse af kalendere til eksperter

I den næste del limer vi disse tjenester vha. Zapier. Zapier er en platform, der letter forbindelsen af ​​API-første platforme. På denne måde reducerer vi det manuelle arbejde, der er nødvendigt for at køre ovennævnte forretningsstrømme. Eksperter vil f.eks. Være i stand til at tilmelde sig selv. Derudover opretter platformen alle de nødvendige enheder programmatisk.

Til sidst vil vi skubbe prototypen til produktion. Det vil stadig være en applikation i en tidlig fase, men den vil være mere robust og klar til at betjene reelle kunder. Bliv hængende!

Opdatering: du kan finde den anden del er her.