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

В итоге мы решили попробовать Swirl – поисковую платформу с открытым исходным кодом, созданную на Python и Django, позволяющую легко объединить поиск в базах данных (SQL и NoSQL), облачных сервисах, поисковых провайдерах, хранилищах данных и таких инструментах, как Miro, Jira, GitHub и т.д., а на выходе получать результаты с аналитикой от ChatGPT.

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

Она позволила нам реализовать поиск по нашим корпоративным данным прямо из коробки.

Коротко о том, что дальше расскажем подробно:

• Какие задачи мы решали с Swirl

• Как настраивали и интегрировали систему

• Какие преимущества получили в итоге

Ну что, поехали!

Почему именно Swirl?

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

Мы оценили популярные решения типа Solr и некоторые другие open source системы. Однако они обрабатывают копии всех исходных данных и индексируют их, что может быть дорогим и трудоемким для небольших компаний. 

В итоге мы обратили внимание на Swirl – поисковую платформу с открытым исходным кодом на базе Python и фреймворка Django. Её архитектура включала несколько важных для нас компонентов.

В Swirl были гибкие модули подключения к данным через API, интеграция с GPT для генерации текстовых ответов и опции мониторинга.

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

Но это были только первые впечатления от работы с системой. 

Поиск в условиях информационного хаоса

По мере роста нашей компании объемы данных стремительно увеличивались. При этом они хранились в самых разных форматах и источниках:

• Базы данных SQL для структурированных данных

• Различные базы данных NoSQL для неструктурированных данных

• Репозитории исходного кода (Git)

• Корпоративная электронная почта

• Облачные хранилища 

Из-за такой распределенности данных по многочисленным хранилищам поиск нужной информации превратился в крайне трудоемкий процесс.

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

Чтобы решить эту проблему, мы внедрили Swirl – систему поиска с открытым исходным кодом. Благодаря гибким API Swirl может интегрироваться практически с любым источником данных:

• Подключается к базам данных SQL и NoSQL

• Интегрируется с репозиториями кода 

• Связывается с облачными хранилищами по API

• Запросы пользователей распространяются Swirl одновременно на все источники. 

• Результаты ранжируются с помощью встроенной в Swirl модели косинусно-векторного сходства, основанной на spaCy, а также с помощью увеличения числа терминов и фраз.

Swirl также позволяет расширять функционал с помощью самописных коннекторов.

К примеру, вот так выглядит стандартный connector для PostgreSQL:

{

    “name”: “Company Funding Records – PostgreSQL)”,

    “default”: false,

    “connector”: “PostgreSQL”,

    “url”: “host:port:database:username:password”,

    “query_template”: “select {fields} from {table} where {field1} ilike ‘%{query_string}%’ or {field2} ilike ‘%{query_string}%’;”,

    “query_processors”: ,

    “query_mappings”: “fields=*,sort_by_date=fundedDate,table=funding,field1=city,field2=company”,

    “result_processors”: ,

    “result_mappings”: “title=”{company} series {round}”,body='{city} {fundeddate}: {company} raised usd ${raisedamt}nThe company is headquartered in {city} and employs {numemps}’,date_published=fundeddate,NO_PAYLOAD”,

    “tags”:

}

Все это позволило нам организовать единую точку поиска по всем корпоративным данным и оптимизировать этот процесс.

Интеллектуальный поиск с генерацией ответов на естественном языке

В ходе внедрения Swirl мы изучили подход Retrieval Augmented Generation (RAG) для интеллектуального поиска. Его суть – сначала система выполняет контекстный поиск релевантной информации, а затем генерирует развёрнутый ответ на естественном языке на основе найденных данных. 

Так, при поисковом запросе “отчётность за 2023 год” система сначала выполняет поиск по базам данных и выявляет релевантные отчёты. Затем передаёт найденную информацию в модуль ИИ, который генерирует краткое резюме в формате (примерный текст):

“В текущем квартале объем продаж компании вырос на 15% по сравнению с предыдущим и составил Х рублей. Подробная информация представлена в отчётах за 1-3 кварталы 2023 года: Q1 – ссылка раз, Q2 – ссылка два”.

Таким образом, на выходе получаем готовый структурированный ответ со всей ключевой информацией.

При запросе “Отчеты о продажах за 2023” Swirl определяет тематику, выделяет временной период и показывает именно подходящие отчеты. Работа системы с контекстом выходит на уровень. Это реально экономит массу времени по сравнению с ручным анализом сырых данных! 

Мы протестировали этот подход на различных типах запросов и получили следующие результаты:

• Точность и релевантность ответов оценивается специалистами на 4,7 балла из 5.

• Время получения ответа снизилось в среднем на 58% по сравнению с ручным поиском.

А теперь давайте рассмотрим подробный алгоритм поиска:

1. Пользователь формулирует запрос на естественном языке.

2. Swirl распространяет запрос на интегрированные данные через встроенный или самописный connector.

3. Источники возвращают набор первичных результатов.

4. Результаты объединяются и ранжируются по релевантности.

5. Наиболее подходящие отправляются в LLM вместе с контекстом запроса.

6. LLM анализирует результаты и генерирует ответ пользователю.

Какие перспективы?

Внедрив Swirl, мы увидели большие перспективы использования возможностей ИИ для оптимизации работы с данными. Swirl является подходящим быстрым для небольших компаний вроде нашей.

Уже сейчас мы применяем Swirl для интеллектуального поиска по нашим внутренним базам. Это избавило нас от ручного перебора кучи данных при поиске нужной информации. Также ведется интеграция наших систем управления со Swirl, что позволит нам оптимизировать продажи и улучшить воронку. 

В целом, решения наподобие Swirl позволяют компаниям эффективнее использовать накопленную информацию для развития бизнеса.

Безусловно, поисковые системы с элементами ИИ – это будущее работы с данными, и мы рады быть частью этого увлекательного пути!

Желаем удачи в работе и приглашаем в комментарии! Очень интересно услышать ваше мнение и рассказы о похожем опыте!

Если после нашего рассказа, вас заинтересовал Swirl, то вот все необходимые для начала работы ссылки:

GitHub: Swirl on GitHub 

Инструкция по установке: Getting started with Swirl

Документация: Swirl Wiki

Привет, Хабр. Меня зовут Артем Арефьев, я руковожу Frontend-разработкой в направлении продукта для учеников в Учи.ру. Фронтендом занимаюсь уже 11 лет, шесть из которых работаю у нынешнего работодателя. Еще принимаю участие в проектах Open Source (например, внес вклад в проект Lerna), несколько лет был наставником в «Хекслет». Хочу рассказать о том, как у нас в Учи.ру возникла необходимость в создании библиотеки компонентов, почему первое решение не сработало, какие выводы мы сделали и чем закончился наш проект библиотеки.

Для чего нам понадобилась библиотека

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

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

1. Различия в дизайне: разные цвета и размеры элементов, шрифты, UX. Наши основные пользователи — школьники, которые в этом разнообразии путались. Одинаковые по сути, но отличные по дизайну элементы дети воспринимали как разные, что осложняло пользовательский опыт.

2. Из-за разделения фронтенда каждый дубль элемента — модальное окно, кнопку, инпут — приходилось поддерживать отдельно, на это тратились ресурсы.

Чтобы не путать пользователей и экономить время, мы решили внедрить общую библиотеку компонентов. Работа предстояла большая ввиду нескольких факторов:

• Компоненты должны были работать с разными инструментами, поскольку в компании есть проекты на TypeScript, на React в связке с Redux или MobX, на Vue, несколько приложений на Next.js, лендинги в Tilda.

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

Нам подходили веб-компоненты, но они работали только в современных браузерах. Поэтому мы искали свое решение на основе этой технологии. Вариантов было много, но мы остановились на Stencil.js, поскольку у него уже была реализована поддержка с React и Vue. 

С чего мы начали работу

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

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

Мы запустили всю эту историю 13 июля 2020 года. Через месяц у нас появилась самая первая версия библиотеки, но в ней еще не было компонентов. Сами компоненты делались в течение следующих пяти месяцев, мы их тестировали, правили баги. Процесс создания компонентов для библиотеки представлен на рисунке ниже.

Такой долгий срок для нас стал сюрпризом, но тут роль сыграли:

• Высокая сложность разработки. Чтобы создать компонент, недостаточно было реализовать логику и написать стили. Для обеспечения полноценной поддержки в проектах на React и Vue мы разрабатывали для каждого разные обертки (причем из-за изменений в Vue3 сделали еще одну обертку). В некоторых компонентах двустороннее связывание в Vue работало только в тестах, а при внедрении в проект — нет. И узнавали это мы, соответственно, только когда внедряли.

• Расположение нескольких версий одного компонента на странице. Эту проблему мы пытались решить, добавив префикс. При маунте компонента префикс должен был заменяться на версию. Это решало проблему коллизий, но, к сожалению, не решало проблему со скоростью загрузки страниц. Все потому, что для каждой патч-версии получался отдельный файл.

• Трудности при создании компонентов. Чтобы их сделать, недостаточно было знать Stencil.js. Была куча внутренних особенностей, которые хотя и были задокументированы, но все же вызывали вопросы. В итоге продуктовым командам трудно было работать с компонентами, и они постоянно «дергали» проектную команду, которая занималась библиотекой. А ведь библиотека не была основным проектом разработчиков, времени на нее было не так много.

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

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

Вторая попытка

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

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

Мы решили, что в этот раз не будем отдавать создание библиотеки «на откуп» лишь одной команде, а станем работать над ней все вместе. Обсудили с коллегами пользу, которую потенциально библиотека может принести: например, когда она появится, всем будет удобнее делать фичи. И договорились использовать стратегию InnerSource — это когда подать идею и внести свой вклад в проект может каждый из коллег. 

В создании библиотеки участвовали дизайнеры всех продуктовых команд (под руководством лида дизайна в направлении) и фронтенд-разработчики, которых курировал я.

Также, наученные предыдущим опытом, мы приняли важные правила:

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

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

3. Компоненты используются без изменений. Если очень нужно, то вопрос обсуждается. Если договориться не удается, у команд всегда есть возможность сделать свою библиотеку, основанную на текущей.

4. Все вопросы мы стараемся решать через канал оперативной коммуникации.

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

Конечно, остались и определенные вызовы. Например, из-за того, что за библиотеку отвечают все и сразу, сложно понять, кому браться за доработку компонентов. Поскольку библиотека — не основная задача, то времени обычно нет ни у кого. В нашем направлении нехватка времени особенно сильна, потому что, повторюсь, в него входят только продуктовые команды. У некоторых нагрузка может быть так высока, что не всегда получается поработать даже с техдолгом.

Как правило, наши разработчики считают, что дорабатывать должен тот, кто изначально делал компонент. Но я ратую за коллективную ответственность и обращаю внимание: если у кого-то появилась инициатива, он может сам внести изменения. Или отправить на review — все инициативы мы собираем, обсуждаем, отправляем в бэклог, приоритезируем. И в дальнейшем ими занимается тот, у кого появилось время.

Итоги

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

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

• формируйте сообщество вокруг инструмента;

• создавайте культуру сотрудничества;

• мотивируйте и поощряйте людей, которые вносят вклад в развитие инструмента. 

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

Эта статья — перевод оригинальной статьи “New in Chrome 118”.

Также я веду телеграм канал “Frontend по-флотски”, где рассказываю про интересные вещи из мира разработки интерфейсов.

CSS @scope

Правило @scope at-rule позволяет разработчикам распространять правила стилей на заданный корень описания и стилизовать элементы в соответствии с близостью к этому корню.

С помощью @scope можно отменять стили, основанные на близости, что отличается от обычных стилей CSS, которые применяются только на основе порядка и специфики источника. В следующем примере имеется две темы.

без @scope, применяемым стилем является последний объявленный

.pink-theme a { color: hotpink; }
.lightpink-theme a { color: lightpink; }

С помощью @scope можно иметь вложенные элементы, при этом применяется стиль ближайшего предка.

@scope (.pink-theme) {
a {
color: hotpink;
}
}

@scope (.lightpink-theme){
a {
color: lightpink;
}
}

@scope также избавляет от необходимости писать длинные и запутанные имена классов, облегчает управление большими проектами и позволяет избежать конфликтов имен.

Без @scope

.first-container__main-title {
color: grey;
}

.second-container__main-title {
color: mediumturquoise;
}

С @scope

@scope(.first-container){
.main-title {
color: grey;
}
}
@scope(.second-container){
.main-title {
color: mediumturquoise;
}
}

С помощью @scope можно также стилизовать компонент, не стилизуя некоторые вложенные в него элементы. Таким образом, можно создать “дыры”, к которым не будет применяться стиль, заданный в области видимости.

Как в следующем примере, мы можем применить стиль к тексту и исключить элементы управления, или наоборот.

@scope (.component) to (.click-here, .link-here) {
div {
color: purple;
text-align: center;
font-family: sans-serif;
}
}

Более подробную информацию можно найти в документации по @scope.

scripting и мультимедийные функции prefers-reduced-transparency

Мы используем медиазапросы для создания пользовательского опыта, который адаптируется к предпочтениям пользователя и условиям устройства. В этой версии Chrome добавлены два новых значения, которые могут быть использованы для адаптации пользовательского опыта: scripting и prefers-reduced-transparency.

Мы можем считать само собой разумеющимся наличие скриптов при работе в вебе, однако они не всегда включены. Теперь с помощью функции scripting медиазапросов можно определить наличие скриптов и применить определенные стили для каждого случая. Доступные значения: enabled, initial-only или none

@media (scripting: none) {
.script-none {
color: red;
}
}

Еще одно значение, которое можно проверить с помощью медиазапросов, – prefers-reduced-transparency, позволяющее разработчикам адаптировать веб-контент к выбранным пользователем предпочтениям по уменьшению прозрачности в ОС, например к настройке Reduce transparency в macOS. Возможные варианты: reduce или no-preference.

.translucent {
opacity: 0.4;
}

@media (prefers-reduced-transparency) {
.translucent {
opacity: 0.8;
}
}

А проверить, как это выглядит, можно с помощью DevTools:

Для получения дополнительной информации ознакомьтесь с документацией по scripting и prefers-reduced-transparency.

Улучшения панели source в DevTools

В панели Sources в DevTools реализованы следующие улучшения: функция workspace улучшила согласованность, в частности, панель Sources > Filesystem переименована в Workspace вместе с другими текстами пользовательского интерфейса, Sources > Workspace также позволяет синхронизировать изменения, сделанные в DevTools, непосредственно с исходными файлами.

Кроме того, теперь можно изменять порядок расположения панелей в левой части панели Sources путем перетаскивания, а панель Sources теперь может красиво выводить inline JavaScript в следующих типах сценариев: module, importmap, speculationrules и подсвечивать синтаксис скриптов типа importmap и speculationrules, которые содержат JSON.

Подробнее об обновлениях Chrome 118 DevTools читайте в разделе “Что нового в DevTools”.

И ещё!

Конечно, есть и ещё.

Сегодня в среде разработчиков часто продвигают GraphQL в качестве замены REST, хотя обе технологии можно использовать одновременно. В этой статье Анастасия Иванова, Product Owner личного кабинета платформы МТС Exolve (входит в экосистему МТС), рассмотрит интерфейсы подробнее, чтобы понять, как выбрать подходящее решение под каждый конкретный проект. Подробности — под катом.

REST API: стандарт и его особенности

Веб-службы применяют интерфейс программирования REST (Representational State Transfer — «передача состояния представления») API для предоставления клиенту запрошенных им данных.

REST API — архитектурный стиль. Он использует HTTP-запросы для доступа к различной информации. Интерфейс работает с пятью основными запросами:

Ответы возвращает в форматах XML, YAML и JSON. С помощью REST API клиент может вносить изменения на сервер.

Запросы REST API состоят из нескольких блоков кода:

• Endpoint. Элемент содержит URL — способность идентифицировать ресурс в онлайн-режиме

• HTTP-method. Метод описывает тип запроса, который будет отправлен на сервер

• Header. Нужен для серверов, чтобы они могли тестировать, проводить аутентификацию и кэшировать данные

• Body. Тело кода содержит полезные данные для передачи на сервер

Недостатки

Основным минусом REST API считают создание множества эндпоинтов. Работать с ним — это как уточнять что-либо в разных компаниях. Нужно звонить всем по очереди.

Например, вы хотите посмотреть варианты пиццы и указываете точку /pizza. API принесёт информацию о цене, акциях и составе продукта. Но вы просили информацию о видах пиццы. Придётся постоянно прописывать конкретные адреса, а это энергозатратно для разработчиков и проблематично для пользователей.

То есть возникают проблемы с выборкой: она либо избыточна, либо недостаточна. REST не может предоставлять точные данные по запросу клиентов, потому что использует один endpoint для одного адреса.

Архитектурный стиль GraphQL позволяет сделать запросы за один раз. Клиент передаёт названия трёх мест, запрашивает нужные данные и ждёт. GraphQL выполнит все запросы и принесёт данные из разных адресов.

GraphQL: стандарт и его особенности

GraphQL — язык запросов для управления данными графов. Он использует разные виды протоколов для передачи информации. GraphQL в основном возвращает ответы в JSON.

Главное отличие GraphQL от REST API в том, что все данные клиент может выбрать всего одним запросом, даже если они будут располагаться в разных источниках. А в REST API придётся сделать выборку и извлекать их уже оттуда.

Разработчики считают GraphQL умным агрегатором, который играет роль оркестратора. Он переадресовывает фрагменты запроса на разные эндпоинты. GraphQL умеет отправлять данные поверх HTTP-протокола, Websocket и SSH. Это удобно, когда вы разрабатываете многофункциональное приложение.

GraphQL имеет три главных блока:

• Queries — запросы

• Schema — схема. Описание типов объектов и полей, принадлежащих каждому объекту

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

Для работы с графовым языком запросов есть утилита GraphiQL. Разработчик интегрирует её с Endpoint GraphQL. Он отправляет запрос серверу на предоставление своей схемы — вы получаете интерфейс для проведения тестов и изучения запросов.

Если с формированием запросов всё понятно, давайте посмотрим основные блоки кода для схем:

• Character — вид среды GraphQL

• Fields (например, name и address) — поля, заполняемые в виде объекта Character. Их находят в ответе на запрос. Каждое поле возвращает то значение, которое обрабатывает

Разберём поля подробно, потому что они составляют значительную часть возвращаемой информации. Итак, они могут быть скалярного вида, объектом, типом ввода, перечисления, объединения и интерфейсом.

Например, скалярные виды — это:

• String — определённые символы в коде UTF-8

• Int — 32-битное целое число

• Float — цифра с плавающим разделительным знаком

• Boolean — логическая информация: true или false

• ID — уникальный идентификатор. Нужен для повторной выборки объекта

GraphQL умеет анализировать синтаксис и проверять формы собственной схемой. Этот API может показаться сложным на стадии создания приложения, но подобное разделение на отдельные элементы — интересная возможность для анализа синтаксиса — позволяет получать чёткие ответы на запросы без дополнительных выборок, в отличие от REST API.

На что обратить внимание при выборе REST API или GraphQL 

В доступных сегодня REST API вы чаще можете встретить API как список endpoints:

GET /animals/:id
GET /humans/:id
GET /animals/:id/comments
POST /animals/:id/comments

В GraphQL же не нужны URL-адреса для идентификации доступных данных в API. Вы используете GraphQL-схему:

type Query {
  animal(id: ID!): Animal
  human(id: ID!): Human
}

type Mutation {
  addComment(input: AddCommentInput): Comment
}

type Animal { … }
type Human { … }
type Comment { … }
input AddCommentInput { … }

Если чуть вникнуть, то различия такие:

• GraphQL позволяет переходить внутри одиночного запроса от точки входа к данным, следуя связям из схемы. В REST получить связанные ресурсы возможно через запросы к нескольким endpoints

• В GraphQL нет отличий между полями типа Query и иными полями. То есть в запросе любое поле может работать с аргументами. В REST нет какого-то первого класса при вложенном URL

• В REST запись данных вертится вокруг HTTP-методов, достаточно менять GET на POST. В GraphQL нужно менять ключевое слово в запросе

REST API зашифровывает данные и даёт множество вариантов самостоятельной аутентификации API без помощи разработчиков. GraphQL позволяет контролировать доступ к полям и операциям в запросах. Но для защиты информации придётся создавать дополнительные методы.

Из-за жёсткой структуры REST API нужно постоянно прописывать путь к данным, которые хочет получить клиент, делая выборку. При работе с GraphQL достаточно прописать запрос один раз, чтобы получить точный ответ на него. Это более гибкий инструмент для выборки.

Эндпоинты запроса GET REST API могут попасть в кэш браузера на стороне клиента, на сервере — через CDN. GraphQL не хранит кэш. Однако, если использовать инструменты Apollo или URQL, можно хранить кэш на стороне клиента.

Спецификация GraphQL не подразумевает загрузку файлов, поэтому реализация остаётся на ваше усмотрение. Есть такие варианты:

• Base64: делает запрос больше и дороже для кодирования и декодирования

• отдельный сервер или API

• библиотека типа graphql-upload, которая реализует спецификацию многочастного запроса GraphQL

В REST API каждый код состояния — это определённый вид ответа. Клиент, обрабатывающий ответы, должен знать названия кода и значение.

У GraphQL всё проще. Неважно, что будет в ответе, «успех» или «неудача», система пропишет один код состояния — 200 ОК. Клиент использует специальные инструменты для более точной расшифровки. Все ошибки будут обработаны как часть тела в рамках объекта Errors.

Пример заказа бургера по SMS

Представьте себе процесс заказа бургеров. Кто-то уже видел этот мем про GraphQL.

Вы заходите в ресторан и заказываете чизбургер. Независимо от количества заказов (вызовов RESTful API), вы каждый раз получаете ингредиент чизбургера. Он всегда будет одинаковой формы и размера (это ответ REST).

https://api.com/cheeseburger/

С GraphQL вы можете построить его по-своему: указать, каким именно чизбургер вы хотите видеть. Сначала булочка сверху, затем котлета, солёные огурцы, лук и сыр (если вы не веган).

query getCheeseburger ($vegan: Boolean) {
  cheeseburger {
            bun
            patty
            pickle
            onion
            cheese @skip(if: $vegan)
  }
}

Ваш ответ — это именно то, что вы хотели — ни больше, ни меньше. Затем взять и заказать бургер, отправив SMS в ресторан.

Ресторан получает SMS через омниканальную платформу МТС Exolve, заранее настроив приём подобных заказов по разным каналам.

При использовании REST вы, скорее всего, получите в ответ полные «наборы данных». Если запросите информацию для меню, ваши запросы будут такими:

• запрос menu бургеров по названиям, описаниям, ингредиентам в одном запросе

• запрос prices к этому меню, в другом запросе

• запрос images для меню

• и так далее

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

Что использовать в работе

Итак, REST API применяют, если:

• работают с небольшими программами, где нужно обрабатывать простые данные

• пользователи работают с ними одинаково

• нет требований к сложным запросам

GraphQL выбирают, когда:

• у серверного оборудования маленькая пропускная способность. Необходимо снизить количество ввода-вывода данных

• в одном адресе нужно объединить множество источников

• запросы пользователей различны, необходимо прорабатывать разные ответы

Заключение

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

Помните:

• при написании публичного API, в рамках которого вы планируете обеспечить пользователю широту действий, используйте GraphQL

• при разработке frontend-приложения применяйте REST API. Если хотите избавить пользователя в публичном API от N+1 проблем, используйте REST

Привет! Я – Роман Батин, ведущий фронтенд разработчик. Уже несколько лет занимаюсь управлением командами разработки интерфейсов и обучением стажеров. За время своей работы я заметил, что у большинства начинающих (да и не только) программистов, встречаются одни и те же ошибки. Корни же этих ошибок лежат даже не столько в незнании языка или технологий, сколько в отсутствии определенных навыков разработки в целом.

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

Смотреть на интерфейс глазами пользователя

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

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

Однако не все детали учитываются в макетах. Например, дизайнер разрабатывает карточку, клик по которой ведет на другую страницу приложения. Очевидно, что данный элемент подразумевает интерактивность. И эту интерактивность нужно передать, а самый простой способ это сделать – навесить css свойство cursor: pointer.  Многие начинающие программисты забывают о таких важных деталях.

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

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

Как быть?

Прокачивайте насмотренность

Начать можно с простого: в очередной раз, когда вы будете пользоваться своим любимым сервисом, начните обращать внимание на его техническое устройство, а также какой опыт он вам дает как пользователю. Не забывайте использовать инструменты разработчика (DevTools), чтобы лишний раз посмотреть реализацию различных элементов управления. Постарайтесь определить, что именно в поведении интерфейса вам нравится, а что – нет. Такая рефлексия не будет занимать у вас много времени, но позволит увидеть хорошие и полезные практики и впоследствии их применить.

Будьте пользователем для своего интерфейса

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

Самоконтроль и ответственность в разработке

Процессы разработки, выстроенные в большинстве IT компаний, направлены на минимизацию ошибок, которые попадают в конечный продукт. Unit и End-2-End тестирование, Code Review, QA позволяют выявлять баги на различных этапах. Но можно ли, написав код, пойти пить чай и переложить ответственность проверки конечного результата только на других? На мой взгляд, определенно нет. Каждый разработчик должен брать ответственность за тот код, который он пишет.

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

На практике очень часто можно встретить такую ситуацию: начинающий программист, как ему кажется, выполнил задачу. Отправив коммит, он радостно отчитывается о том, что все было сделано. При проверке оказывается, что код просто-напросто не работает. Не выполняются необходимые функции. Верстка же – хорошо, если компонент будет хотя бы отдаленно напоминать макеты. Последнее можно встретить даже у более опытных разработчиков. Проблемы с pixel perfect версткой возникают зачастую даже не из-за сложности ее реализации, а в силу отсутствия проверки результатов с макетом.

Как быть?

Перечитывайте описание задачи

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

Больше внимания на проверку

Не бойтесь потратить время на то, чтобы после выполнения задачи пройтись по той части интерфейса (желательно, и не только), которую вы разработали. Попробуйте воспроизвести пользовательские кейсы, создать различные условия для работы интерфейса.

Приведу далеко не полный список действий, которые вы можете совершить для проверки корректности своей работы.

1. Используйте навигацию по приложению. Многие проблемы могут дать о себе знать при переключении экранов, особенно если вы используете один из SPA фреймворков.

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

3. Проверьте адаптивность, используя DevTools. Не всегда она требуется (для мобильных устройств и планшетов), но даже для десктопа необходимо, чтобы контент отображался без ошибок.

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

5. Используйте замедление сети из вкладки Network в DevTools, чтобы отследить поведение приложения при низкой скорости интернета.

6. Не забывайте смотреть логи, чтобы не пропускать ошибки и вовремя их исправлять.

7. И уж точно не забудьте запустить тесты и линты, если они у вас настроены (а если нет – то стоит задуматься, почему).

Экспериментируйте!

Написание тестов

Тесты – один из важных подходов проверки работоспособности приложения. Да, тестами, unit или end-2-end, не всегда возможно полностью покрыть все кейсы, особенно если мы говорим про разработку интерфейсов. Не во всех командах вообще сформирована культура их написания.

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

Выводы

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

Если ужать все вышеизложенное:

1. Внимательно и вдумчиво относитесь к выполнению задачи, не спешите ее завершить – потратьте время на самопроверку.

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

3. Проверьте работоспособность приложения в различных условиях: запустите в разных браузерах, измените размер окна браузера, изучите внимательно DevTools.

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

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

Производительность или качество?

Мир IT-разработки сложен и многогранен. Особенно когда речь идет о сроках и производительности. В гонке за выполнением проектов и разработкой новых фич, легко потерять из виду главное: качество продукта. Но что такое “качественный код”?

1. Конвейер разработки: Сегодня большинство компаний внедряют методологии быстрой разработки, которые направлены на ускорение процессов. Это, безусловно, эффективно с экономической точки зрения. Но при этом возрастает риск ошибок, потому что мы постоянно находимся под давлением. Недостаточно времени на анализ, планирование и, главное, тестирование. Результат? Код, который может работать, но не всегда корректно или эффективно.

2. Саморефлексия разработчика: Хороший код — это не только тот, который выполняет свою функцию. Это код, который легко читать, масштабировать, который эффективен и безопасен. Но как часто мы, разработчики, задаем себе вопросы о качестве своего продукта? Сколько раз мы возвращаемся к своему коду, чтобы оптимизировать его, даже если он уже “работает”?

3. Ответственность перед пользователем: Наши пользователи доверяют нам. Они полагаются на наш продукт, на наш код. Они ожидают, что все будет работать без сбоев и ошибок. Каждый раз, когда мы жертвуем качеством ради скорости, мы рискуем потерять это доверие.

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

Значимость тестирования

Тестирование – это не просто шаг в процессе разработки; это крайне важное звено, которое обеспечивает качество и надежность кода. Рассмотрим несколько ключевых аспектов этой стадии.

1. Не все тесты созданы равными: Многие разработчики воспринимают тесты как нечто формальное. “Покрытие кода тестами на 90%? Отлично! – А можем сделать 100?”. Но покрытие кода не всегда коррелирует с качеством. Важнее фокусироваться на реальных сценариях использования и критически важных функциях, чем на цифре в отчете.

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

3. Проактивное тестирование: Хорошо, когда разработчик не просто реагирует на ошибки, но и предугадывает потенциальные проблемы, создавая тестовые сценарии даже перед тем, как начать написание кода. Но будем честны, сколько из нас так делают?

Каждый код, который мы пишем, может влиять на жизни людей – независимо от того, создаем ли мы медицинский софт или простое мобильное приложение. Это не просто строка кода; это ответственность. Тестирование не является дополнительной опцией или шагом, который можно пропустить; это неотъемлемая часть создания качественного продукта.

Реальные последствия недостаточного качества кода

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

Пример из медицинской сферы:

Представим систему для медицинских учреждений, предназначенную для отслеживания назначенных пациентам препаратов. Все кажется простым: врач назначает препарат, система фиксирует его, а пациенту предоставляются рекомендации по дозировке и режиму приема. Но что если из-за ошибки в коде дозировка лекарства, которая была указана в формате “10.0 мг”, изменилась на “100 мг” после обновления программы из-за пропавшей десятичной точки? Такая ошибка может привести к тому, что пациент примет в десять раз больше лекарства, чем ему было назначено, что грозит серьезными осложнениями или даже смертью.

И многие могут подумать: “Это же очевидная ошибка. Пациент наверняка проконсультируется с врачом или свяжется с медицинским центром перед тем, как принять такую дозу”. И хотя в большинстве случаев это может быть так, всегда найдется человек, который просто подумает, что врач изменил рекомендованную дозу или даже не обратит на это внимания и примет лекарство, руководствуясь ошибочной инструкцией. Таким образом, даже одна маленькая ошибка в коде может иметь глубокие и трагические последствия для конкретного индивида.

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

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

Заключение

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

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

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

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

Всем привет! Краткий обзор новостей из мира PHP и Laravel за сентябрь 2023 г.

PHP Дайджест

Вышли PHP 8.1.24 и PHP 8.2.11

Выпуски с исправлениями ошибок вышли по расписанию.

Вышел третий релиз кандидат PHP 8.3.0

Очередной релиз-кандидат вышел по расписанию, до официального выхода PHP 8.3.0, который намечен на 23 ноября, осталось 3 выпуска.

Большинство новостей ядра PHP подробно освещаются в серии PHP Core Roundup от PHP Foundation, мы лишь быстро по ним пробежимся.

📊RFC: Increasing the default BCrypt cost

Tim Düsterhus предлагает увеличить значение параметра const в BCrypt по умолчанию, обозначающего алгоритмическую стоимость, которая должна использоваться, с 10 до 11 (двухкратное увеличение времени) или до 12 (четырехкратное увеличение времени).

📣RFC: DOM HTML5 parsing and serialization

Niels Dossche предлагает добавить в модуль DOM два новых класса: HTMLDocument и XMLDocument. 

Класс HTMLDocument добавит поддержку разбора и сериализации HTML5-документов в соответствии со спецификацией. Класс XMLDocument будет служить современной альтернативой классу DOMDocument, который сохраняется для совместимости. Эти новые классы также обеспечат более устойчивый к злоупотреблениям API для загрузки документов.

Существующие классы DOM в глобальном пространстве имен получат псевдоним в новом пространстве имен DOM, так что новая реализация будет использоваться по умолчанию.

📣RFC: A new JIT implementation based on IR Framework

Дмитрий Стогов предлагает новую реализацию Just-in-Time компилятора, основанную на собственном фреймворке Дмитрия Intermediate Representation.

Основной плюс нового подхода в том, что исходный код PHP освободится от низкоуровневых деталей JIT-компиляции. Теперь интерпретатор будет формировать так называемое промежуточное представление, которое вышеупомянутый фреймворк превратит в ассемблерный код с учётом процессорной специфики. Также новый JIT позволит в будущем применить дополнительные оптимизации (видимо, уже на стороне фреймворка) для получения более эффективного машинного кода. Минус же состоит в более долгой JIT-компиляции.

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

❌RFC: Support optional suffix parameter in tempnam

RFC о котором мы говорили в прошлом выпуске был отклонен.

Основная проблема – суффикс не будет работать в Windows. Чтобы избежать больших проблем из-за незначительного изменения, многие проголосовали против.

Вышел CakePHP 5

Команда CakePHP выпустила пятую версию фреймворка, которая была в разработке последние два года. Теперь для работы требуется PHP 8.1 и выше, улучшены подсказки по всему фреймворку. CakePHP теперь использует объединения типов для формализации типов многих параметров во всей платформе, обновлён PHPUnit до 10 версии, новая поддержка сопоставления перечисления типов в ORM, обеспечивающая более выразительные слои модели с улучшенной проверкой типов, добавлена поддержка HTTP-фабрик PSR17 и многое другое.

State of Laravel 2023

Исследование по Laravel, о котором мы говорили в прошлом выпуске завершилось. Более 4000 разработчиков приняло участие в этом году. Уменьшилась доля людей, которые считают, что Laravel фреймворк движется в правильном направлении с 49% до 41%. Напишите в комментариях, как считаете вы?

Пакет enum-concern от Emre Yarligan

PHP-пакет для удобной работы с перечислениями с помощью Laravel Collections.

Пакет включает зависимость от Collections, поэтому его можно использовать не только в Laravel проектах.

Пакет act от Casey Lee

Пакет позволяет запускать GitHub Actions локально!

Это может быть полезно для отладки скриптов, не делая множество коммитов на GitHub и ожидая их выполнения.

Когда вы запускаете act, он считывает GitHub Actions из папки workflows и определяет набор действий, которые необходимо выполнить. Используя Docker API для извлечения или создания необходимых образов, как определено в файлах workflow, и, наконец, определяет путь выполнения на основе определенных зависимостей.

Получив путь выполнения, он использует Docker API для запуска контейнеров для каждого действия на основе ранее подготовленных образов. Переменные среды и файловая система настроены в соответствии с тем, что предоставляет GitHub.

PhpStorm Public Roadmap: What’s Coming in 2023.3

Что ожидать в PhpStorm 2023.3?

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

Для Symfony разработчиков будет полезным мастер создания нового проекта, преобразование аннотаций Doctrine в атрибуты, а также поддержка Doctrine Query Language внутри QueryBuilder.

Voices

Плагин для продуктов JetBrains Voices позволяет комментировать код голосовыми сообщениями.

Напишите в комментариях как вы относитесь к такой идее?

Flappyphpant

И напоследок давайте посмотрим простую игру, похожую на Flappy Bird, написанную на PHP, построенная на PHP-GLFW и фреймворке VISU.

Далее посмотрим что произошло в этом месяце в Laravel. 

Laravel дайджестMoonShine v.2.0 alpha

Вышла MoonShine v.2.0 alpha – open-source админ панель для Laravel. Что нового – читайте в этой статье.

Обновления Laravel10.22. Testing methods for Precognition

PR от Peter Fox, который добавляет нам сахара в процесс тестирования precognition запросов. У нас появился удобный метод usingPrecognition, чтобы сразу отправить нужные заголовки. Также появился метод который проверит в ответе нужные заголовки. 

10.22. Добавление поддержки Enum в правила валидации In и NotIn

Следующий PR добавил поддержку Enum в правила валидации In и NotIn. Теперь мы с вами можем использовать также и кейсы из Enum. 

10.23. Команда make:view

PR, который судя по описанию очень долго ждали – это artisan команда которая создает view. Скажите а ждали ли вы эту команду? Лично я не особо. Но в целом у нас есть команда которая теперь создает view, располагает ее в директории и появилась также опция –test, которая заодно создаст и дополнительно тесты – правильно у нас это view рендерится. 

Ну и раз у нас PR от Nuno Maduro, также и опция –pest, которая сгенерирует Pest тесты.

10.23. Поддержка PHPredis 6.0

Небольшом PR, который добавляет поддержку PHP redis версии 6.0. 

10.23. Before/After database truncation methods

PR, который добавляет новые ивенты в тесты на отслеживание событий до того как у нас происходит очистка базы данных и соответственно после.

10.23. Команда Make:Model с опцией Test

Немного прокачали команду Make:Model с опцией Test. До этого, когда мы ее с вами выполняли у нас создавался тестовый файл featureModels, но не было при этом тестового файла для контроллера, хотя в опции мы могли указать что также нам нужен контроллер. Теперь тестовый файл для контроллера создается.

10.24. Метод Str::position()

Затрагивает класс по работе со строками и новый сахарный метод Position над нативным mb_strpos. Но я думаю здесь и так все понятно – ищем позицию указанной строки в строке.

10.25. Метод String Take() 

Снова класс по работе со строками и снова сахар, но в целом в рамках этого класса другого мы не ожидаем. Чтобы из указанной строки получить только количество символов которые мы передаем в метод Take. В общем сахар над сахаром Str::substring, где соответственно сам substring это сахар над нативным substr.

10.25. Throttle Exception

PR от Tim McDonald, который добавляет новый метод в errorHandler класс в Laravel. Для нашего удобства чтобы отделить Exception от ratelimit и уже далее с ними взаимодействовать, делать репорт и все что угодно.

Видео версия дайджеста: