Знакомство с JavaScript неизбежно, когда работаешь с вебом: всегда надо иметь ввиду, кто и как на фронте будет запрашивать данные с твоих API. Кроме того, какая-нибудь часть бизнес-логики то и дело утекает на клиент и нужно принимать это во внимание при рефакторинге back-end сервисов.

TypeScript

Использовался мной по большей части для того, чтобы линтеры (в т.ч. на CI) и языковые серверы лучше понимали происходящее и давали более контекстный вывод. Малыми бонусами были Python-like импорты и классы, что гораздо удобнее, когда параллельно работаешь с Python-бэком, чем тот Lua-style, что царил в JS до повсеместного принятия ES2015.

GraphQL

Как упоминалось в разделе по Python , часть сервисов в проекте e-commerce платформы разрабатывалась с GraphQL API. Подход «schema first» позволил команде фронтэнда определять желаемый API независимо от команды бэка, что повысило скорость разработки и качество API. Тем не менее, по мере появления новых сервисов внутри кластера образовывалось всё больше и больше независимых API, которые надо было как-то объединять.

К сожалению, в мире Python пока нет решений для автоматизированной организации GraphQL-шлюзов, так что пришлось взяться за JS: Apollo Federation . Не то чтобы всё происходило совсем уж автоматически (нужно прописывать дополнительные аннотации в схемы), но цель была достигнута довольно просто.

React

На React я разрабатывал небольшой фронт для системы диагностики БПЛА. В целом, ничего особо выдающегося: dashboard из кучки компонентов с графиками и телеметрией, которые можно добавлять, убирать и передвигать. Зато несложно было расширять и всё работало из браузера.

Иллюстрация

• Полупрозрачный тессеракт: логотип webpack , если бы он был спроецирован на плоскость под таким углом, при котором все его кубы имели бы одинаковый вид.

• Атом в центре проекции тессеракта: React .

• Фон: старые логотипы JavaScript и TypeScript .