При реализации Cosmo Router, open-source замена Apollo Router, мы столкнулись с проблемой поддержания нашего кода для решения проблемы N+1. Реализация маршрутизатора для федеративных служб GraphQL в значительной степени зависит от возможности группировать вложенные запросы GraphQL для сокращения числа запросов к подграфам.

Чтобы решить эту проблему, мы разработали новый алгоритм, который решает проблему N+1 более эффективно и проще для поддержания, чем наше предыдущее решение, которое было основано на шаблоне DataLoader, обычно используемом в сообществе GraphQL. Вместо разрешения сначала по глубине, мы загружаем данные сначала по ширине, что позволяет нам сократить параллелизм с O(N^2) до O(1) и улучшить производительность до 5 раз, сокращая сложность кода.

Если вы заинтересованы в проверке кода, вы можете найти его на GitHub.

Я также провел лекцию на эту тему на GraphQL Conf 2023, которую вы можете посмотреть здесь.

Пошаговое руководство по созданию масштабируемого, чат-приложения реального времени с использованием серверных технологий... с небольшой помощью от NextAuth.js для входа через GitHub. Кому нужны WebSockets, когда у вас есть Live Queries? Не нам!

Если вы создаете приложения, которые работают с данными в реальном времени, вы, вероятно, используете WebSockets. Они позволяют веб-браузеру и веб-серверу общаться в реальном времени, поддерживая постоянное соединение между ними - данные отправляются клиентам, как только они становятся доступными, а не когда клиент постоянно опрашивает сервер на предмет новых данных.

Но что, если ваше приложение является серверным - работает на инфраструктуре, управляемой облачным провайдером, таким как AWS или GCP?

Для обеспечения высокой эластичности и отказоустойчивости эти среды разработаны так, чтобы быть без состояния и временными по своей природе, что означает, что нет гарантии, что ваш код будет работать на одном и том же физическом сервере от одного запроса к другому - и, следовательно, нет постоянного соединения между клиентом и сервером.

Итак, какое решение для создания приложений в реальном времени на серверных архитектурах? Давайте выясним! Давайте создадим этот чат в реальном времени в стиле Slack/Discord, используя Next.js в качестве нашего JS-фреймворка, Fauna (с использованием GraphQL) в качестве нашей базы данных, и WunderGraph в качестве Backend-for-Frontend (BFF), который обеспечивает связь между ними. Наше приложение также будет использовать вход через GitHub, и мы будем использовать знаменитый NextAuth (теперь Auth.js!) для наших нужд в области аутентификации.

Это 2024 год, и GraphQL на подъеме, чтобы стать важным игроком в экосистеме API. Это идеальное время, чтобы поговорить о том, как сделать ваши GraphQL API безопасными и готовыми к производству.

Итак, вот мой тезис: GraphQL по своей природе небезопасен. Я докажу это в течение всей статьи и предложу решения. Одно из решений потребует некоторого радикального изменения в том, как мы думаем о GraphQL, но это принесет много преимуществ, которые выходят далеко за рамки просто безопасности.

Версионирование API является важной частью жизненного цикла API. Некоторые стили API, например, GraphQL, полностью игнорируют версионирование и называют это функцией. Другие, например, RESTful API, предоставляют разработчикам множество различных способов реализации версионирования.

Я считаю, что версионирование для API важно, но также слишком сложно. Это важно, потому что обратная совместимость критически важна в мире взаимосвязанных компаний, использующих API в качестве моста. В то же время это сложная проблема для команд разработчиков.

Все больше и больше компаний начинают понимать свои API как продукты. Компании будущего не будут работать в изоляции. Вместо этого они будут использовать API от сторонних поставщиков, предоставляя при этом свои API другим.

Опираясь на API других компаний, эти компании получат преимущество, так как смогут больше сосредоточиться на своем собственном бизнесе. В то же время, предоставляя свои собственные API в качестве продукта другим компаниям, они получат преимущество перед теми компаниями, которые не позволяют другим легко интегрироваться с ними. Все это приведет к выигрышной ситуации для участников. Я ожидаю, что этот тренд может только привести к экспоненциальному росту. Чем больше проблем легко решаемы с помощью интеграции с API, тем проще становится для других создавать новые бизнес-модели на его основе, что, в свою очередь, добавит больше API в экосистему.

Возможно, вы думаете, что о подписках говорить особо нечего. Они определены в спецификации GraphQL, и должно быть очень ясно, как они работают и для чего они нужны.

Но на самом деле спецификация мало что говорит о транспортном слое. Фактически, она вообще не указывает транспортный слой. С одной стороны, это преимущество, потому что вы можете использовать GraphQL в самых разных средах. С другой стороны, у нас сейчас есть по крайней мере пять разных реализаций подписок GraphQL.

Это означает, что вы не можете просто использовать любой клиент GraphQL, подключиться к серверу GraphQL и ожидать, что все будет работать. Вам нужно знать, какой протокол поддерживает сервер и какой клиент вам нужно использовать. Это идеальная ситуация? Вероятно, нет, но мы собираемся это изменить!

Мы - создатели WunderGraph (открытый исходный код), первого облачного серверного GraphQL API Gateway. Одной из проблем, с которой мы столкнулись, была поддержка всех различных протоколов подписки GraphQL. Поскольку спецификация GraphQL строго агностична к протоколу, за годы было разработано несколько различных протоколов.

Если клиент хочет использовать подписку GraphQL, ему нужно знать, какой протокол использовать, и реализовать клиентскую сторону этого протокола.

С нашим Open Source API Gateway, мы делаем шаг вперед и объединяем все под одной крышей. Если вы смотрите на использование подписок GraphQL в вашем проекте, этот пост - отличный способ быстро ознакомиться с различными протоколами и их особенностями.

Если вы давно следите за моей работой, то знаете, что одним из моих любимых пристрастий являются сравнения GraphQL, REST, tRPC и других технологий, в которых не упоминаются Relay и Fragments. В этом посте я объясню, почему я считаю Relay переломным моментом, как мы сделали ее в 100 раз проще в использовании и внедрении, и почему вам стоит обратить на нее внимание.

За время моей недолгой работы инженером-программистом (2,5 года) мне всегда невероятно везло с людьми, которые меня окружали. Я сталкивался с гениальными инженерами, которые, проявляя терпение и оказывая поддержку, делали все возможное, чтобы помочь мне учиться, совершенствоваться и самому становиться лучшим инженером.

В первый день работы в моей первой компании я не понимал, что такое POST-запрос. В начале прошлого года я не знал, что такое GraphQL. До вчерашнего дня я никогда не использовал defer в GoLang.

Теперь, если я оглянусь назад, я легко могу увидеть, насколько далеко я продвинулся. Но когда вы окружены командой чрезвычайно умных и знающих людей, еще проще увидеть, как далеко вам еще предстоит идти. И так же легко это расстояние может превратиться в тревогу и депрессию.

«Сделай работающим, сделай правильным, сделай быстрым». Это мантра, которую вы, вероятно, слышали раньше. Это хорошая мантра, которая помогает вам сосредоточиться на том, чтобы не переусложнять решение. Я пришел к выводу, что обычно достаточно сделать это правильно, обычно это достаточно быстро, если сделать это правильно.

Когда мы начали реализацию подписок GraphQL в Cosmo Router, мы сосредоточились на том, чтобы сделать это работающим. Это было несколько месяцев назад. Это было достаточно хорошо для первой итерации и позволило нам получить отзывы от наших пользователей и лучше понять проблемное пространство.

В процессе того, как мы делали это правильно, мы сократили количество горутин на 99% и потребление памяти на 90% без жертвования производительностью. В этой статье я объясню, как мы достигли этого. Использование Epoll/Kqueue сыграло большую роль в этом, но также переосмысление архитектуры, чтобы она была более событийно‑ориентированной.

В 99designs мы находимся на пути деконструкции нашего PHP-монолита в микросервисную архитектуру, при этом большинство новых сервисов пишется на Go. В этот период наша фронтенд-команда также применила безопасность типов, перейдя с Javascript на TypeScript и React.

После того как мы внедрили безопасность типов в бэкенд и фронтенд, стало очевидно, что наши конечные точки REST, созданные на заказ, не могут преодолеть разрыв между типами. Нам нужен был способ объединить эти системы типов и распутать наши конечные точки API.

Нам нужна была система безопасности типов для API. GraphQL выглядел многообещающе. Однако, изучив его, мы поняли, что не существует серверного подхода, который бы отвечал всем нашим требованиям. Поэтому мы разработали свой собственный, который мы назвали gqlgen.

Спрос на функции поиска растет, и многие разработчики пытаются внедрить их в свои приложения. Однако создание таких приложений с нуля - сложная и трудоемкая задача. К счастью, существует множество библиотек с открытым исходным кодом, позволяющих освободить разработчиков от этого бремени.

В этом руководстве читатель найдет список лучших поисковых пакетов для JavaScript. В статье будет проведен обзор и сравнение поисковых пакетов с учетом скорости, простоты использования, типа предлагаемого поиска, базы данных и других характеристик. Кроме того, читатели поймут, что такое функциональность поиска и зачем она нужна.

По мере того как И.И. все больше проникает в общественное сознание, мы начинаем видеть антиутопические истории о будущем работы, предсказывающие своего рода окончательную победу макиавеллиевских сил капитализма.

Самый яркий пример - автор научной фантастики Тед Чианг, который недавно задался вопросом, есть ли "способ для И.И. сделать что-то еще, кроме как точить лезвие ножа капитализма?". По данным Insider, сотрудники JPMorgan, возможно, уже страдают от такой динамики благодаря мощным инструментам мониторинга сотрудников компании.

Эти истории рисуют мрачную картину, вызывая множество опасений, которые я разделяю, и, действительно, мои собственные опасения по поводу И.И. выходят далеко за рамки потенциального влияния на работу. Но я верю, что мы преодолеем их, и хочу на мгновение представить мир, где люди процветают на своих рабочих местах благодаря, а не вопреки И.И.

Предлагается пошаговое руководство по дообучению Whisper для любого многоязычного набора данных ASR с использованием Hugging Face ? Transformers. Эта заметка содержит подробные объяснения модели Whisper, набора данных Common Voice и теории дообучения, а также код для выполнения шагов по подготовке данных и дообучению. Для более упрощенной версии с меньшим количеством объяснений, но со всем кодом, см. соответствующий Google Colab.

Когда я ищу информацию о принципе KISS в Интернете, я натыкаюсь на множество сайтов, определяющих его в паре строк: важна простота, давайте быть простыми, конец. Они часто не объясняют, что такое простота, почему простота важна и как ее достичь.

Простота - это одна из ведущих идей, которую мы должны помнить всегда, проектируя систему. Проблема: ее действительно трудно достичь.

Вы угадали: мы погрузимся в простоту (и сложность) в этой статье. Я не буду писать обо всех различных способах, которыми сложность может проникнуть в ваш код, но, вместо этого, я постараюсь дать вам краткий обзор различных масок, которые сложность может носить, с множеством примеров. Мы перейдем от самого бизнес-домена, через мелочи (реализацию), чтобы закончить сложностью архитектуры программного обеспечения.

Мы все были там: Вы работали над множеством изменений одновременно, некоторые из которых не имели ничего общего. Для удобства вы решили объединить все эти изменения в один коммит и на этом закончить. Но хотя это может показаться заманчивым, на самом деле это может привести к большим проблемам в дальнейшем. Большие коммиты могут:

В продолжение к заметке Инструкция: как быстро настроить GitLab CI/CD на Flutter-проекте.

Больше спасибо автору, всё получилось относительно легко. Я усложнил задачу: поднял GitLab локально на Хакинтоше, прикрутил executor = "docker" вместо "shell". И началось веселье.

Эта заметка о том, зачем нам нужен пакет coroutine для Go и как он будет выглядеть. Но прежде всего, что такое корутины?

Сегодня каждый программист знаком с вызовами функций (подпрограмм): F вызывает G, которая останавливает F и запускает G. G выполняет свою работу, потенциально вызывая и ожидая другие функции, и в конце концов возвращается. Когда G возвращается, G уже нет, а F продолжает работать. В этой схеме одновременно выполняется только одна функция, а ее вызывающие ожидают, поднимаясь вверх по стеку вызовов.

В отличие от подпрограмм, корутины выполняются конкурентно на разных стеках, но все равно верно, что одновременно выполняется только одна функция, а ее вызывающая сторона ждет. F запускает G, но G не выполняется немедленно. Вместо этого F должен явно возобновить (resume) выполнение G, который затем начинает выполняться. В любой момент G может развернуться и вернуться (yield) назад к F. Это приостановит G и продолжит F операцию возобновления. В конце концов F снова вызывает resume, который приостанавливает F и продолжает G после выхода. И так далее, туда-сюда, пока G не вернется, что приведет к очистке G и продолжению F с последней операции возобновления, с некоторым сигналом для F, что G закончена и F больше не должна пытаться возобновить G. В этом паттерне одновременно выполняется только одна корутина, а ее вызывающая сторона ждет на другом стеке. Они выполняются по очереди в четко определенном, скоординированном порядке.

Это несколько абстрактно. Давайте посмотрим на реальные программы.

Создание, удержание и масштабирование отличных технических команд происходит благодаря сильной культуре, ориентированной на разработчиков. Обеспечение того, чтобы люди чувствовали себя в безопасности, чтобы их уважали и давали им возможность выполнять свою работу наилучшим образом, необходимо для создания любой команды, и разработчики не являются исключением!

Однако культура - вещь непростая. Ее нельзя измерить, и хотя она не может быть навязана сверху, здоровая культура требует правильной среды для роста и масштабирования. В этом первом разделе книги The Ultimate Guide to Building Technical Teams мы рассмотрим, что могут сделать организации, чтобы заложить фундамент командной культуры, ориентированной на разработчиков, частью которой они с удовольствием станут.

Этот манифест опубликован пару лет назад, но интересно посмотреть с оглядкой назад.

Прежде чем говорить о функции init в Golang, необходимо понять, что такое пакет в Golang. Программа go организована в пакеты. Пакет собирает несколько исходных файлов в одном каталоге. Он похож на ящик, в котором находятся некоторые инструменты или небольшая машина. Он является отправной точкой для инициализации всего пакета. По-видимому, это соответствует назначению функции init.

Изящное завершение работы (Graceful Shutdown) важно для любого длительного процесса, особенно для того, который обрабатывает состояние. Например, что если вы хотите завершить работу базы данных, поддерживающей ваше приложение, а процесс db не сбрасывает текущее состояние на диск, или что если вы хотите завершить работу веб-сервера с тысячами соединений, но не дожидаетесь окончания запросов. Изящное завершение работы не только положительно сказывается на пользовательском опыте, но и облегчает внутренние операции, что приводит к более счастливым инженерам и менее напряженным SRE.

В этой заметке вы найдете ряд анти-паттернов и узнаете, как сделать выход из процесса изящнее с помощью нескольких различных подходов. Также я приведу несколько примеров для распространенных библиотек и некоторые продвинутые паттерны. Давайте погрузимся в тему.

Сила событийного моделирования заключается в его простоте. В этой шпаргалке кратко описаны четыре строительных блока, которые могут быть использованы в четырех различных схемах.

Когда вы проводите сессию по событийному моделированию, хорошо, чтобы люди быстро освоились. Используйте эту таблицу для собственного понимания или возьмите ее с собой на семинар, чтобы облегчить начало работы для тех, кто только начинает знакомиться с событийным моделированием.