Что такое GraphQL в мобильках.
GraphQL — это язык запросов для API, разработанный Meta. Он предоставляет полное описание API и дает возможность запрашивать именно то, что им нужно.
Особенность такой системы:
- Серверы GraphQL находятся между клиентом и серверными службами.
- Возможно соединить несколько запросов REST в один запрос.
- Сервер GraphQL организует ресурсы в виде графа.
- Поддерживаются запросы, мутации (изменений данных) и подписки ( уведомления об изменениях схемы).

Если нужно попроще, то REST - это когда запросы едут в персональном авто, а в GraphQL едем в автобусе.

Пример работы запроса есть в картинке.

#интервью #читлист

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

Очень удобно, есть примеры ответов, в том числе и на ситуационные кейсы.

Сохраняйте в копилку!

​​📑 REST API vs GraphQL: в чём между ними разница

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

Читать статью

Когда разработчик не может воспроизвести баг

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

Что делать, если после тестирования на проде нашлись баги? 🪲🐞

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

1️⃣ Стоит разделить чувство вины и ответственность. Не нужно себя винить и сомневаться в своей компетентности. Это не продуктивно и точно никак не поможет вам в работе. Ошибки допускают все. Как минимум, кроме вас их допустили разработчики, и они вылились в дефекты, которые не были обнаружены в ходе тестирования.

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

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

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

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

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