Tapaustutkimus
Coyotes and Candles: Kaksimiehisen yrityksen monipuolisen luovan alustan rakentaminen
Laajuus
501
Committia
~65,700
TypeScript-riviä
93
Sivureittiä
74
API-reittiä
65
SQL-skeematiedostoa
5
Korvattua maksullista työkalua
Ongelma
Vaimoni Alli ja minä pyöritämme Coyotes and Candles -yritystä, joka on kahden hengen yritys, joka tarjoaa tarot-ennustuksia, D&D-kertaluontoisia pelisessioita, yksityisiä ryhmäkampanjoita sekä verkkoyhteisön. Ennen tämän järjestelmän rakentamista jokainen liiketoiminnan osa oli hoidettu eri työkalulla:
- -Calendly aikataulujen sovittamiseen (ei maksua, ei videoyhteyttä, ei jatkotoimia)
- -Zoom-videopalvelu (ulkoiset linkit, ei sisäänrakennettua kontekstia)
- -Patreon ja Ko-fi tilauksia varten (hajanaiset kohderyhmät)
- -Discord yhteisöä varten (erillään kaikesta muusta)
Asiakkaiden piti vaihdella viiden eri työkalun välillä varatakseen ajan, liittyäkseen videopuheluun ja löytääkseen yhteisön. Tarvitsimme yhden alustan, joka hoitaisi kaiken ajanvarauksesta istunnon jälkeiseen seurantaan.
Mitä rakennettiin
Yksi integroitu alusta, jossa on kuusi erillistä varausprosessia, kaksi maksupalveluntarjoajaa, upotettu reaaliaikainen videotoiminto, kattava virtuaalinen pöytäkattaus, yhteisöjärjestelmä ja hallintapaneeli - korvaa kaikki viisi työkalua.
Varaukset ja maksut
- ·6 varausprosessia: tarot-ennustukset, kertaluonteiset palvelut, yksityisryhmät, kampanjat, joissa laskutus tapahtuu jälkikäteen, lahjakortit, tilaukset
- ·Stripe kertamaksuja ja toistuvia tilauksia varten
- ·PayPal-tilausrajapinta (API) ja kattava webhookien elinkaaren hallinta
- ·Yli 20 valmiita sähköpostimallia: vahvistukset, muistutukset, virheilmoitukset ja palautukset
- ·Reaaliaikainen saatavuuskalenteri, jossa otetaan huomioon aikavyöhykkeet
- ·Automaattinen hyvitys, jos peruutetaan vähintään 48 tuntia ennen istuntoa
- ·Aikataulun muuttaminen itsepalveluna ja kampanjapaikkojen varaus maksua lykkäämällä
- ·Lahjakortit ja tarjouskoodit
Istunnon toteutus (VTT)
- ·Agora-sovellukseen integroidut live-videohuoneet - lataamista ei tarvita
- ·Täysin virtuaalinen pelipöytä: pelinappulat, sodan sumu, vapaakäsin piirtäminen, noppapeli
- ·D&D 5e -hahmolomakkeet, joissa on täysi integrointi SRD-kokoelmaan
- ·Shadowrun 4e -hahmolomakkeet, joissa on Chummer XML -tuonti
- ·GM:n hallinnoima musiikki YouTuben kautta
- ·CoyoteCloud: reaaliaikainen DiceCloud-tiedonsiirto ja kaksisuuntainen synkronointi, jolloin DiceCloudissa tehdyt hahmomuutokset näkyvät VTT:ssä välittömästi
Yhteisö
- ·Discord-tyylinen kanavajärjestelmä, kampanjakohtaiset kanavat
- ·Suorat viestit, reaktiot, kirjoitusilmaisimet
- ·Verkkopush-ilmoitukset
- ·Moderointityökalut ja tarkastuslokit
- ·Valinnainen Discord-webhookin peilaus
Hallintapaneeli
- ·Varaukset ja kampanjoiden hallinta
- ·Pelaajien hallinta mukautettujen hinnoittelun ja läsnäolon seurannan avulla
- ·Istunnon muistiinpanot ja yhteenvedot
- ·Liikevaihdon analytiikka ja tuloslaskelma
- ·Google Search Console -integraatio
- ·Virheiden seuranta ja päällekkäisyyksien poisto
Kuvakaappaukset
Tekninen arkkitehtuuri
Mitä opin
Tämä on oma yrityksemme, joten palautekierros on lyhyt: jos varausprosessi keskeytyy, Alli saa siitä tiedon asiakkaalta jo samana iltana. Suurin osa seuraavista muutoksista löytyy muutoslokista, koska ne johtuivat alun perin ilmenneistä ongelmista.
Tarkistus, joka ei erota uusimista kaksoiskappaleesta, estää uusimisen
Pitkät videopuhelut katkesivat lähes täsmälleen neljän tunnin kuluttua. Agoran pääsytunnukset vanhenevat tuolloin, ja asiakasohjelma uusii ne lähettämällä pyynnön uudelleen tunnusreitille, mutta kyseisellä reitillä oli ”jo tässä istunnossa” -tarkistus, jonka soittajan oma reaaliaikainen sykkeenilmoitus laukaisi. Uusinta palautti 409-virheen ja epäonnistui huomaamatta, joten Agora katkaisi yhteyden kesken istunnon. Korjaus ratkaistiin antamalla asiakassovelluksen merkitä pyyntö uusinnaksi, jolloin päällekkäisyystarkistus ohitettiin, vaikka aito toinen liittymispyyntö edelleen hylätään. Yleinen periaate on syytä muistaa: mikä tahansa suojaus, joka tunnistaa soittajat heidän läsnäolonsa perusteella, tulee lopulta kohtaamaan laillisen soittajan kahdesti.
UPDATE, joka ei osu yhteenkään riviin, ei ole virhe
Uudet kokoushuoneet unohtivat hiljaisesti kaikki asetukset: hahmolomakejärjestelmän, ruudukon oletusarvot ja tilan. Julkaistusta tietokantataulusta puuttui sarake, johon lisäyskirjoitus kohdistui, joten konfiguraatiorivin luominen epäonnistui, ja jokainen myöhempi päivitys löysi nolla riviä ja ilmoitti onnistuneen, koska mitään päivittämättä jättäminen on täysin kelvollinen tulos SQL:ssä. Vanhemmat huoneet toimivat kunnolla, koska ne olivat peräisin ajalta ennen kyseisen sarakkeen lisäämistä. Mikään pinoissa ei olisi nostanut tätä esiin itsestään. Kirjoituspolun on tarkistettava, että se on todella muuttanut jotain, muuten vika pysyy näkymättömänä, kunnes joku mainitsee, että asetukset eivät koskaan tallennu.
Estetty pyyntö näyttää bugilta, ei estolta
Twitchin chat-overlay näkyi täydellisesti, otsikko mukaan lukien, eikä siinä näkynyt yhtään viivaa. CSP:n connect-src-asetuksessa mainittiin Supabase, Agora ja Stripe, mutta ei Twitchin IRC-WebSocketia, joten selain hylkäsi yhteyden ennen sen avaamista. Sama ongelma toistui vielä kahdesti: next/image kieltäytyi hiljaisesti näyttämästä järjestelmänvalvojan syöttämiä bannerin URL-osoitteita, joiden isäntäpalvelimia ei ollut sallittujen listalla, ja eräs kumppaniprojekti tiukensi rivitason suojauksiaan, mikä olisi estänyt tuonnin, joka oli aiemmin toiminut vain siksi, että kyseiset taulukot olivat kaikkien luettavissa. Sallittujen luettelot epäonnistuvat huomaamattomasti ja hiljaisesti, ja oireena näkyy aina oman ominaisuutesi toimimattomuus.
Tarkista-sitten-kirjoita on kilpatilanne; anna tietokannan ratkaista se
Lahjakorttikoodit luotiin tarkistamalla, oliko koodia jo olemassa, ja lisäämällä se sen jälkeen. Tämä menetelmä perustui tarkistushetkeen ja käyttöhetkeen, mikä johti lopulta päällekkäisyyksiin. Se korvattiin lisäyksellä, joka yrittää uudelleen, jos ainutlaatuisuusrajoitus rikkoutuu, jolloin sovelluksen sijaan tietokanta toimii päätöksentekijänä. Sama päättely pätee myös Stripen webhook-uudelleenkokeiluun: päällekkäiset laskutustapahtumat ohitetaan nyt idempotenssiavaimen avulla sen sijaan, että luotettaisiin siihen, etteivät ne koskaan saapuisi kahdesti. Kaikissa tapauksissa, joissa tarjonta on rajallista tai vaikutus on ”korkeintaan kerran”, tarvitaan rajoitetta, ei tarkistusta.
Erota toisistaan ”onko tätä olemassa” ja ”saatko nähdä sen”
Supabase-avaimen vaihdon jälkeen jäsenille, jotka eivät olleet kirjautuneet sisään sen jälkeen, ilmoitettiin puhelun liittymisen yhteydessä, että ”tätä istuntoa ei ole käytettävissä”. Heidän tallennettu tunnisteensa oli allekirjoitettu vanhalla avaimella, joten rivitason suojauksen lukutoiminto palautti nolla riviä, reitti päätteli, ettei huonetta ollut olemassa, ja käyttöliittymä esitti tämän 404-virheen puuttuvana istuntona. Huone oli kuitenkin kunnossa; viesti oli virheellinen. Olemassaolon tarkistukset suoritetaan nyt palvelun asiakassovelluksen kautta, kun taas todennus tarkistetaan erikseen, joten vanhentunut tunnus tuottaa selkeän 401-virheen ja kirjautumispyynnön. Näiden kahden asian sekoittaminen ei ainoastaan heikennä valtuutusta, vaan myös aiheuttaa virheellisiä virheilmoituksia.