Tuzzo Music

Започна, преди да умея да пиша код. Току-що бях научил думата API. С ранните AI инструменти от онова време отворих мрежовия раздел на браузъра в музикалната услуга, прочетох заявките на нейния собствен плейър и сам разгадах как работи API на услугата. По-късно сървърната част мина през трима доставчици: API, поддържан от общност, worker услуги, поддържани от общността, и накрая платен абонамент. И двата общностни доставчика бяха чупливи по един и същ начин, а опашката на плейъра се разсинхронизираше по четири независими причини.

Сложих доставчика зад сменяем слой, преминах на платения абонамент и проведох кампания за подсилване на защитата: два кръга от агенти-откриватели и противникови проверяващи агенти, после паралелни направления „първо план, после изграждане“ в отделни git worktrees, с направление за тестове, което фиксира намереното в кръговете.

1. 01

   API, разгадан от мрежовия раздел

   Мрежовият раздел на браузъра показва всяка заявка, която прави собственият плейър на услугата. Сам разгадах от тези заявки как работи API на услугата, с ранните AI инструменти от онова време, докато още не можех да пиша код. Този API остава неофициален, затова плейърът е личен и няма препратка към него.

2. 02

   Сменяем слой за доставчика и звук, който заобикаля сървъра

   Идентификаторите са с префикс на доставчика, така че по-старите записи продължават да се намират след миграция. Сървърът държи един общ токен, подписва заявката за URL на файла и връща на браузъра подписан CDN URL за оригинален FLAC. Значката за качество чете обратно кода на доставения формат, така че показва какво е пристигнало. Грешка със студения старт, открита по пътя: стъпка на инициализация изтегляше около 9 MB и надхвърляше времевия лимит на безсървърната среда. Беше поправена веднага.

3. 03

   Затворен списък на API заявките и проверка за вход в CI

   API на доставчика стои зад затворен, изброен списък (switch), без препращане на подадения от клиента slug. Скрипт в CI спира изграждането с грешка, когато някой маршрут под app/api нито извиква помощна функция за удостоверяване, нито е в списъка с разрешените изключения.

4. 04

   Първо откриване, после проверка

   Два кръга с 12 и около 13 агента съчетаха откриватели с противникови проверяващи. 58 находки устояха на проверката в първия кръг и 133 във втория, общо 191. Резултатът беше копиран на сигурно място, защото стоеше във временна папка на сесията.

5. 05

   Направления, които отказват да налучкват

   Направленията работеха в отделни worktrees (ядро на плейъра, UX на обвивката, доставчик на данни, откриване на музика, интерфейс на плейъра). Направлението за откриване отказа да гради върху крайни точки, които не можеше да потвърди, и вместо това заведе заявка за изпробване. Четири независими причини за разсинхронизиране на опашката бяха отстранени в направлението за ядрото на плейъра, с един общ случай в reducer като споделен механизъм.

6. 06

   Проверка на качеството в истински браузър

   Четири направления за проверка на качеството работеха срещу продукционната среда с отделни, създадени за целта акаунти. По мое настояване водещият агент провери и в истинския ми Chrome през разширението на браузъра, с еднократен акаунт, изтрит след това, вместо да се доверява на автоматичен браузър без прозорец (headless).

Плейърът е пуснат и работи зад вход с парола. API на доставчика е неофициален, което README изрично казва, затова държа плейъра личен и без препратки към него. План за настолен клиент с bit-perfect възпроизвеждане съществува само като документ.