Всем привет! Меня зовут Владимир Касаткин, и я работаю бэкенд-разработчиком в компании ivi.ru, в команде "UX". Цель этой статьи — показать, как мы уменьшили объём клиентской разработки, но при этом увеличили количество проводимых A/B-тестов.

Раньше вся продуктовая разработка была разбита на большие направления ("платформы"): бэкенд, Smart TV, iOS, Android, веб. При этом фичи пилились достаточно долго (по полгода), а побочным эффектом были заметные различия внешнего вида и функционала одной и той же фичи на разных платформах.

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

Привет, Хабр! Работая над библиотекой-обёрткой REST API, я столкнулся с проблемой. Для тестирования обработки ошибочных кодов ответа сервера (400, 500, 403 и т.д.) необходимо искусственно создавать условия на сервере для получения соответствующих кодов. При правильно настроенном сервере, например, непросто получить ошибку 500. А тестировать функции-обработчики ошибок как-то надо. Я написал небольшое API, которое генерирует ошибочные ответы сервера — httpme.tk

• Разработка конструктора отчетов c Cube.js;
• 5 действенных техник оптимизации vue-приложений;
• Решение проблем REST API при помощи GraphQL.

Перевод статьи подготовлен в преддверии старта курса «Symfony Framework».

В первой части статьи мы рассмотрим самый простой способ реализации REST API в проекте Symfony без использования FosRestBundle. Во второй части, которую я опубликую следом, мы рассмотрим JWT аутентификацию. Прежде чем мы начнем, сперва мы должны понять, что на самом деле означает REST.

Начало работы

npm init

Используемые модули

Введение

Проблема

Всем привет. При разработке API для очередного веб-портала я взял свой привычный стек:

• Django
• django-rest-framework

Но в этот раз стояла довольно непривычная задача — сделать одну User модель, которая может иметь несколько разных профилей (Исполнитель, Заказчик). И наличие каждого из профилей дает разные полномочия на работу с одними и теми же ресурсами.

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

Итак, опишем возникшие перед нами проблемы:

1. Один пользователь – несколько профилей.
2. Как организовать права каждого из профилей.
3. Доступ к одним тем же ресурсам от разных профилей.

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