Целью было показать весь путь обработки события — от поступления HTTP-запроса до его асинхронной обработки как эвента. Именно поэтому в примере использовался FastAPI — как удобный и быстрый способ приёма внешних запросов.
Чтобы избежать повторной обработки одного и того же сообщения, каждому событию назначается уникальный идентификатор. На стороне обработчика выполняется проверка по этому идентификатору — обычно через быстрое (горячее) хранилище, например Redis — было ли сообщение уже обработано.
Важно учитывать, что риск зацикливания может возникнуть при использовании политик доставки At Most Once и At Least Once. В таких случаях ответственность за обеспечение идемпотентности и защиту от повторной генерации событий ложится на саму бизнес-логику приложения.
Секции используем, когда нужно детально показать развернутый флоу, включая все этапы и возможные сценарии. Например, процесс подключения устройства по Bluetooth: от поиска до успешного соединения или ошибки. Таким образом макеты становятся подробными и удобными для работы.
Для разделения макетов по их назначению применяем разделы (подробнее в «Структурируем макеты»).
Чтобы забирать макеты разработчики используют встроенные инструменты Figma и Dev Mode. Для экспорта в JSON можно применять плагины, например Figma to JSON.
Спасибо — полезное замечание! В примере мы как раз используем текст на латинице. Можно воспользоваться другими открытыми библиотеками, которые поддерживают кириллицу.
Добрый день, это просто пример кода — для демонстрации сойдёт и dynamic. В рабочем коде, конечно, стоит заменить на ui.Image? для большей надёжности. Спасибо за замечание!
Идея в том, чтобы заключить всю логику бизнес-логику связанную с объектом в одной сущности в данном случае BookBookService. Это и позволяет нам обеспечить внедрение зависимостей. Если по какой то причине этот класс поменяется, данную зависимость легко можно будет подменить в методе get_book_service.
1. В данном примере модели и играют роль DTO, в статье не приведены модели БД, предполагается, что они уже есть и созданы любым удобным способом. 2. Да они анемичные, потому что они выпоkняют роль DTO. 3. На диаграмме бизнес логи зависит не от БД, а от слоя repository, который выполняет взаимодействие с БД. 4. Бизнес логика не приведена в BookBookService, т.к. не хотелось высасывать ее из пальца.
Про ваш вывод вообще не очень понятно, что вы имеете в виду
Логика копипаста статьи в том, что на хабре ее не было, а материал для публикации кажется нам интересным.
По самому комментарию: думаем ваш вариант справдлив для микросервисной архитектуры, когда за работу с токеным отвечает отдельный сервис и приложению приходится ходить в этот сервис. В статье же описана джанга и монолит, так что для выписывания, валидации и других с действиям с токеном беку не нужно идти к другому сервису, он всю эту логику выполняет внутри себя.
Пока не рассматривали
Целью было показать весь путь обработки события — от поступления HTTP-запроса до его асинхронной обработки как эвента. Именно поэтому в примере использовался FastAPI — как удобный и быстрый способ приёма внешних запросов.
Чтобы избежать повторной обработки одного и того же сообщения, каждому событию назначается уникальный идентификатор. На стороне обработчика выполняется проверка по этому идентификатору — обычно через быстрое (горячее) хранилище, например Redis — было ли сообщение уже обработано.
Важно учитывать, что риск зацикливания может возникнуть при использовании политик доставки At Most Once и At Least Once. В таких случаях ответственность за обеспечение идемпотентности и защиту от повторной генерации событий ложится на саму бизнес-логику приложения.
Добрый день! Спасибо за Ваш интерес к статье. Описанная реализация основана на пакете telegram_web_app: https://pub.dev/packages/telegram_web_app
В самой библиотеке есть exampleApp. Вы можете изучить полный исходный код примера там.
Не показалось, сообщением выше мы согласились с вашим мнением из комментария и поста в тг, что ваш вариант организации иконок удобнее)
Мы просто отвечаем на ваш ответ в ветке комментариев.
Да, действительно, вы правы по поводу организации иконок в больших дизайн-системах. Спасибо за комментарий!
В статье мы описывали кейс иконок для мобильного приложения, где разнообразие начертаний или размеров не требуется. Это просто удобнее и быстрее)
Секции используем, когда нужно детально показать развернутый флоу, включая все этапы и возможные сценарии. Например, процесс подключения устройства по Bluetooth: от поиска до успешного соединения или ошибки. Таким образом макеты становятся подробными и удобными для работы.
Для разделения макетов по их назначению применяем разделы (подробнее в «Структурируем макеты»).
Чтобы забирать макеты разработчики используют встроенные инструменты Figma и Dev Mode. Для экспорта в JSON можно применять плагины, например Figma to JSON.
Согласны с ответом выше. Варианты упрощают замену иконок через панель свойств, что особенно удобно в больших дизайн-системах.
Попробуйте использовать библиотеку flutter_tesseract_ocr — она поддерживает кириллицу, но будет работать медленнее, чем ML Kit.
Спасибо — полезное замечание! В примере мы как раз используем текст на латинице. Можно воспользоваться другими открытыми библиотеками, которые поддерживают кириллицу.
Добрый день, это просто пример кода — для демонстрации сойдёт и dynamic. В рабочем коде, конечно, стоит заменить на ui.Image? для большей надёжности. Спасибо за замечание!
Всё зависит от типа бизнеса.
Если бизнесу требуется верификация личности, в Telegram Mini App можно реализовать свою авторизацию:
• Запросить номер телефона через бота.
• Интегрировать OAuth (например, через Сбер, Госуслуги или CRM).
• Использовать Telegram Passport для загрузки документов.
Нет. Потому-что он есть только на Android.
Если его не исключать, то тогда его применение нужно обязательно описывать в Google Play. Без этого нельзя будет зарелизиться.
Идея в том, чтобы заключить всю логику бизнес-логику связанную с объектом в одной сущности в данном случае BookBookService. Это и позволяет нам обеспечить внедрение зависимостей. Если по какой то причине этот класс поменяется, данную зависимость легко можно будет подменить в методе get_book_service.
1. В данном примере модели и играют роль DTO, в статье не приведены модели БД, предполагается, что они уже есть и созданы любым удобным способом.
2. Да они анемичные, потому что они выпоkняют роль DTO.
3. На диаграмме бизнес логи зависит не от БД, а от слоя repository, который выполняет взаимодействие с БД.
4. Бизнес логика не приведена в BookBookService, т.к. не хотелось высасывать ее из пальца.
Про ваш вывод вообще не очень понятно, что вы имеете в виду
Спасибо, добавили)
Логика копипаста статьи в том, что на хабре ее не было, а материал для публикации кажется нам интересным.
По самому комментарию: думаем ваш вариант справдлив для микросервисной архитектуры, когда за работу с токеным отвечает отдельный сервис и приложению приходится ходить в этот сервис. В статье же описана джанга и монолит, так что для выписывания, валидации и других с действиям с токеном беку не нужно идти к другому сервису, он всю эту логику выполняет внутри себя.