🆘 Привет! Нужна помощь с REST API 🆘

Давайте сделаем требования еще к паре методов для проекта #GetGym.

👉 О проекте GetGym для сети фитнес-клубов
👉 Figma
👉 БД

Без вас не справлюсь, подключайтесь! 🙏🙏🙏 Доп. обсуждения в комментарии, разбор ответов завтра.

Вопросы сейчас появятся
👇👇👇

💻 Какой метод и URL следует использовать для записи на тренировку у конкретного тренера в приложении #GetGym? 💻

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

Что сразу взяла на вооружение:

1️⃣ По дизайну Figma, мы наблюдаем последовательность:
Список тренеров -> Информация о тренере -> Расписание -> Запись на выбранный слот

2️⃣ POST и PUT можно использовать для создания данных.
Запись на тренировку - скорее создание нового appointment (встречи) / workout (тренировки). Также, как следствие записи, возможно изменение кол-ва свободных мест на занятие в расписании.

Разбираю ответы.

🧐 1) POST /trainer/{trainerId}/schedule/{scheduleId}/workout
Ок, т.к. POST. Отличная логическая цепочка, соответствующая UI.
Но оооочень длинная! Уровень 5 (кол-во /) в URL вызывает тревогу 🥲

❗️Можно укоротить до:
✔️ POST /schedule/{scheduleId}/workout
✅ POST /workout (тогда в тело body надо будет обязательно передать scheduleId, чтобы было понятно к какому тренеру и на какое время записываемся)


👎 2) PUT /trainer/{trainerId}/workout/{workoutId}
Ну вроде ок, т.к. PUT. Но все же POST для создания больше предназначен.
Упустили на какое время в расписании мы записываемся - scheduleId.
Даже если добавим в тело, то зачем тогда в начале /trainer/{trainerId}/?
Это будет понятно из scheduleId по БД. Не берем этот вариант.


👎 3) POST /schedule/{scheduleId}/trainer/{trainerId}/workout
Ок, т.к. POST. А вот иерархия кривая. мы сначала смотрим тренеров, а потом их расписание, но не наоборот.


👎 4) PATCH /trainer/{trainerId}/schedule/{scheduleId}/workout
Вообще не ок - PATCH. Изменять пока нечего.


Итого:
👌 POST /trainer/{trainerId}/schedule/{scheduleId}/workout - ОК
🤝 POST /workout с scheduleId в body - идеально

О вопросах вкусовщины. В вариантах упустила окончания s. Когда делала постановку задачи на список тренеров, использовала его. Кто заметил - молодцы! 😁

#RestApiGA

💻 Какой метод и URL следует использовать для изменения записи на тренировку в приложении #GetGym? 💻

Вводные по требованиям, которые помогают выбрать верное решение:

1️⃣ Записаться на тренировку может только авторизованный пользователь - клиент спортзала с абонементом.
А значит вся информация о нем доступна через Token или API-ключ в заголовках запроса (в общем, через авторизацию).

2️⃣ Что-то меняем? PATCH и PUT помогут нам.

3️⃣ А что можно поменять в записи на тренировку?
Отменить её.
Либо сменить время - слот scheduleId. Пользователя в ней сменить нельзя.
Для записи к другому тренеру - отменяем текущую тренировку и идем со списка тренеров заново.

Разбираю ответы.


🧐 1) PATCH /trainer/{trainerId}/workout/{workoutId}
PATCH - ИДЕАЛЬНО.
Но часть /trainer/{trainerId}/ смотрится сомнительно. Зачем нам это, если через workoutId по связям в БД сможем выйти на тренера, который проводит тренеровку?
И у пользователя скорее врего при просмотре UI будет список тренировок, на которые он записан. И там могут быть разные тренеры. Так что часть с тренером выглядит здесь лишней.


🧐 2) PUT /user/{userId}/workout/{workoutId}
PUT - ОК. Но часть user/{userId} явно лишняя. Это и так понятно из авторизации.


✅ 3) PATCH /workout/{workoutId}
PATCH - ИДЕАЛЬНО. Лишних частей нет.


❌ 4) POST /user/{userId}/schedule/{scheduleId}/workout/{workoutId}
POST - это про создание, мимо.


Итого:
✅ PATCH /workout/{workoutId} с авторизацией пользователя
✅ PATCH /workout/{workoutId}/cancel - можно выделить отдельный эндпоинт для отмены тренировки.

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

#RestApiGA

👀 Где искать стажировку на Системного аналитика и как она проходит: реальный опыт 👀

Завершаете обучение на системного аналитика и вам предстоит искать первую работу? Или хотите стать наставником для начинающих IT-специалистов? Вы нашли эпизод, который даст руководство к действию!


00:20 - Знакомство с гостями подкаста - главный системный аналитик Кристина Виноградова и её успешно обученный стажер Елена Киселева. Предыстория Елены о старте карьеры Системным аналитиком.
03:58 - Почему для вас может быть интересно наставничество для стажеров (менторство) и почему, а кому не стоит этим заниматься.
9:28 - Как компании определяют потребность в стажерах и джунах (Junior-специалистах). И о том, как джунам-аналитикам может помочь знание математики.
11:42 - О ключевых навыках и качествах, которые опытные специалисты ждут от начинающих системных аналитиков.
13:53 - Как составляют вакансию на джуна Системного аналитика.
17:13 - Опыт поиска первой работы, когда ты только начинаешь карьеру системного аналитика. Как и где Лена искала стажировки, много ли было обратной связи от компаний на запросы.
23:41 - Как готовиться к собеседованию, если у вас нет опыта работы.
30:31 - Как понравиться вашему будущему руководителю и наставнику - советы для джунов. Почему Кристина выбрала Кристину как стажера к себе, чем Лена запомнилась по сравнению с другими кандидатами.
40:03 - Как строится программа обучения стажера Системного аналитика.
44:56 - С чего начинается работа на стажировке - к чему готовиться на первой работе по специальности Системного аналитика.
52:04 - Самые запоминающиеся моменты стажировки Лены. Как воспринимать негативную обратную связь.
54:35 - Подводим итоги. Рекомендации опытным системным аналитикам, кто хочет стать ментором или взять стажера от Кристины. Рекомендации для начинающих карьеру Системных аналитиков от Лены.


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify


Ждём вопросы в комментариях, чтобы рассказать больше в следующем эпизоде 😉

Друзья, не забывайте о балансе работы и отдыха 🙌

Всем продуктивной рабочей недели 😉

🚕 Проект с микросерверной архитектурой: приложение для заказа такси #RideFlow 🚕

Многие проекты стартуют на простой архитектуре, когда сервер реализован как одно большое приложение - монолит. Работать с ними по-своему интересно, но в какой-то момент возникает ощущение, что развитие карьеры закончилось. Это не так. Есть большие высоконагруженные продукты, например, этот👇

Предлагаю спроектировать систему для заказа такси.

Требования к процессу:
1. Регистрация и аутентификация пользователя
2. Планирование маршрута
3. Выбор такси, подтверждение и оплата заказа
4. Поиск водителей с учетом их текущего местоположения
5. Подтверждение заказа водителем и поездка
6. После поездки:
6.1. Заказ переводится в статус выполненного
6.2. Рассчитывается сумма для выплаты водителю
6.3. С пользователя собирается обратная связь - оценка поездки
7. Выплаты водителям на банковские счета раз в сутки

В компании есть диспетчерская, которая работает 24/7: отвечает на сообщения пользователей и водителей через онлайн-чаты, принимает звонки, следит за автомобилями.

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

Развернуть всю систему на одном сервере и сделать одну общую базу данных - отличное и простое решение! Это решение - монолит 🙂 Работать будет, но…

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

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

Интересная задача? Определенно!

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

Стартуем проект, будем прокачивать наши навыки системных аналитиков в архитектуре! 🚀

#АрхитектураGA

🧐 Монолит - это нормально 🙌

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

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

Когда мы только-только запускаем новый стартап, то такой подход к проектированию архитектуры идеален: просто в программировании, не нужна опытная команда, всё в одном месте, не надо думать о синхронизации данных и многих других деталях.

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

1. Масштабируемость
1.1. Нужно большое количество мощностей. Высокие затраты на инфраструктуру, так как при добавлении новой функциональности нужны более мощные сервера, а при увеличение количества пользователей нужно больше одновременно запущенных копий всего приложения-монолита.
1.2. Высокое время ответа на отдельные запросы к системе, которые требуют обработки большого объема данных из БД (построение отчетов по продажам).

2.Сложность поддержки и развертывания
2.1. Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это становится недопустимо. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.
2.2 Тестирование перед релизом в продакшн превращается в каторгу для тестировщиков. Покрытия автотестами нет. Почти всё тестирование ведется вручную.

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

4. Единая точка отказа
Например, из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Монолит - это одна большая точка отказа в системе.

5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов. Изменения в приложении могут оказаться затруднительными из-за жестких связей между его компонентами.

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

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

Тогда мы и встречаем распространенную задачу переезда с монолита на микросервисы, о которой много говорят в успешных продуктовых компаниях 🙂

#АрхитектураGA

🏠 Как работает система? Покажите архитектуру 🏠

Когда я только начинала работать стажером системным аналитиком, то моими главными задачами были сбор требований от заказчиков в технические задания (ТЗ) и создание задач в Jira, внутри которых были по 1-2 предложения с требованиями. И этого хватало😁

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

Так один из проектов начал расти: в нем оказалось больше 10 приложений, несколько API на сервере и множество интеграций.
Стало сложно, но интересно!

Кто любит читать требования и документацию?
Никто.
Только аналитики 💖

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

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

👉 4 независимых по коду пользовательских приложения, с абсолютно одинаковой логикой, но разным дизайном. Если нужно обновление, то 4 задачи на фронтенд + 1 на бэкенд почти стандартная схема.
👉 Админка - это одно веб-приложение, но с гибкой ролевой моделью. В зависимости от роли мы скрываем часть вкладок и данных в интерфейсе UI.
👉 И так далее.

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

Этот артефакт помог снизить количество вопросов “что у вас тут есть” и “как это все связано” и сократить мое время на объяснение одного и того же по 20 раз 😡

Сейчас это один из первых этапов, которые я делаю на старте с любым проектом: создать схему архитектуры, на которой показаны все компоненты, связи, API и БД 🙌

#АрхитектураGA

🏠 Схема архитектуры - компоненты системы 🏠

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

Компоненты выделяют в процессе проектирования системы и отражают на схеме архитектуры.

Компоненты можно поделить на группы. Рассказываю на примере с системой заказа такси #RideFlow 🚕:

✅ Frontend / UI - приложения с пользовательским интерфейсом.
✔ iOS для клиента такси
✔ Android для клиента такси
✔ iOS водителя
✔ Android водителя
✔ Веб-приложение диспетчера
✔ Веб-приложение администратора

✅ Backend / API - серверные приложения со своей логикой и API для взаимодействия с ними. Сюда относятся сервисы, микросервисы, API-Gateway и другие.
✔ Backend- приложений с отдельными REST API для приложений клиентов, водителей, диспетчеров и админов, а также WebSocket для обеспечения работы онлайн-чатов

✅ Внешние системы, с которыми интеграция
✔ Сервис уведомлений: email, SMS
✔ Сервис push-уведомлений
✔ Интернет-эквайринг для приема оплат от клиентов
✔ Банковский API для юрлиц для выплат водителям

✅ БД и ФХ - базы данных и файловые хранилища.
✔ БД основная, PostgreSQL (чтобы знать, с какими типами данных имеем дело)
✔ ФХ для хранения PDF-документов, например, по выплатам водителям

✅Системы обмена сообщениями - очереди MQ / брокеры сообщений, такие как RabbitMQ, Kafka и другие.
✔ Отправка уведомлений, RabbitMQ
✔ Выплаты водителям, Kafka


Схема архитектуры может быть визуализирована одним из основных способов:

✔️Без нотации - с использованием простых фигур и стрелок (понятность ценнее нотации).
✔️Нотация C4 - идеально, когда нужна чисто техническая архитектура.
✔️Archimate - больше связана с бизнес-контекстом.

На картинке к посту я показала вариант архитектуры системы такси без нотации - простые фигуры.

#АрхитектураGA

☀️ Про лето 2024: о бесконечном совершенствовании (и внутреннем самозванце) ☀️

Осталось еще 4 субботы до осени, но уже сейчас хочется поделиться с вами впечатлениями о лете.

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

И я думала, что летом возьму небольшой перерыв от новых разработок. Но…

Я все равно взялась обновлять материалы: куда-то больше фокуса на онлайн, добавить еще практики, срезать теорию из онлайна и отправить запись в теоретический модуль, что-то новое узнала сама - надо добавить!

Улучшение - бесконечный процесс.
Мне кажется это общая особенность системных аналитиков.
Синдром самозванца постоянно говорит “тут можно еще лучше”🌞

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

Зачем, если и так хорошо и прекрасная обратная связь? Если я могу сделать еще лучше, то буду делать.


Например, на этой неделе для группы по интеграциям дала расширенную практику Postman. В онлайне показала как развернуть тестовый бэкенд и без кода сделать эндпоинт REST API, чтобы проверить работу Webhook-ов, глядя в логи сервера 😳

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

Отдохну осенью, наверное 😃🍁


Моя любовь к системному анализу и передаче знаний неисчерпаема. Порой то, что я делаю с её поддержкой, вызывает шок. Ну и ребята со своими радостями от офферов в ЛС мотивации добавляют 🙌

Любимая работа - это важно. С ней есть чувство, что ты не работаешь)) Но перерывы все же нужны.

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