Родриго Рохас
Если вы работали над цифровым продуктом, будь то разработчик, менеджер продукта или руководитель бизнеса, вы знаете, что наиболее распространенные проблемы при разработке программного обеспечения редко бывают такими простыми, как «баги». Чтобы найти корень проблемы, как правило, требуется больше проб и ошибок. Использование Courier ничем не отличается от этого.
В этом посте мы обсудим примеры проблем, связанных с интеграцией Courier в Gmail и ограничениями скорости API, неполным профилем данных и неполным запросом с Inbox и Toast. Мы подробно рассмотрим, как могут проявляться такие проблемы и как самостоятельно устранить неполадки, чтобы решить все проблемы.
Устранение неполадок методом проб и ошибок
Если проблема сложная, это не значит, что решение не может быть простым. Разработчики постоянно сталкиваются с жаргоном и терминологией, которые могут напугать даже тех из нас, кто более технологически грамотен. Несмотря на опыт разработки, программисты научились находить решения методом проб и ошибок, подбора шаблонов и, осмелюсь сказать, гугления.
Излишне говорить, что это почти считается обрядом посвящения в программисты. В этой статье мы рассмотрим некоторые из наиболее распространенных, но важных проблем, с которыми сталкиваются наши разработчики и пользователи при интеграции Courier в инфраструктуру уведомлений. Если вы столкнулись с каким-то препятствием, велика вероятность, что кто-то другой уже придумал, как его преодолеть.
Интеграция с Gmail и ограничения скорости API
Поздравляем, вы успешно подписались на использование Courier и уже на пути к отправке уведомлений!
После того, как вы прошли процесс регистрации и разрешили Gmail отправлять электронные письма от вашего имени, вы сможете интегрировать Gmail в качестве канала в ваши шаблоны уведомлений.
Уведомление выглядит хорошо, и Gmail интегрирован
Проблема
Одна из постоянных проблем, с которой сталкиваются наши разработчики, — это ограничение скорости, т.е. 429 ошибок при отправке массовых транзакционных писем с интеграцией Gmail. Это понятно, получать 400 ошибок ответа не очень весело. Однако, как разработчики, Google-фу является одним из многих навыков, необходимых для устранения неполадок.
Gmail не любит слишком много запросов
Решение проблемы
Здесь нет никакого обходного пути. API Gmail имеет ограничения, основанные на использовании квоты на каждый метод (250 в секунду при 100 квотах на отправку). Таким образом, Gmail действительно предназначен для быстрого начала работы, тестирования или отправки в небольших масштабах. Это отличный способ освоить использование Courier и сделать пару первых отправок.
Мы рекомендуем вам ознакомиться с полным списком провайдеров электронной почты и выбрать наиболее подходящего в зависимости от ваших целей. Если вы планируете отправлять сразу большое количество писем, лучше выбрать провайдера, который не будет ограничивать вас в тарифах.
Неполные данные профиля
Само собой разумеется, Courier имеет обширный список провайдеров уведомлений, которые наши пользователи могут интегрировать в свою инфраструктуру уведомлений. Каждый из этих провайдеров имеет свои требования к объекту профиля в ответе.
Без профиля в запросе некоторые из ваших уведомлений не будут доставлены, и в ответе, который можно получить из журнала сообщений, будет указано, почему.
Проблема
Вы интегрировали провайдера и установили канал для уведомления. Однако журналы сообщений показывают ошибку ‘Unroutable’ / ‘MISSING_PROVIDER_SUPPORT’ в ответе. Это странно, поскольку вы интегрировали провайдера, создали шаблон и отправили тестовое событие.
Самое интересное то, что журналы сообщают вам, чего вам не хватает.
Исправление
Это зависит от провайдера и канала, но для некоторых из наших наиболее распространенных интеграций, например, электронной почты, самым быстрым решением ошибки «unroutable» является добавление получателя электронной почты в профиль. Courier поддерживает множество провайдеров, и вы можете найти требования к профилю каждого провайдера в соответствующей документации по интеграции. В зависимости от того, используете ли вы электронную почту, sms, push и т.д. для отправки уведомлений, вы должны убедиться, что профиль соответствует требованиям канала.
В зависимости от предпочитаемого канала, некоторые провайдеры предъявляют различные требования к профилю.
Наличие в профиле действующего получателя электронной почты позволит отправлять уведомления по электронной почте.
Для уведомлений in-app требуется более подробный профиль в запросе, который будет рассмотрен в следующем разделе.
Исключения из профиля
Допустим, вы интегрировали Pagerduty для отправки уведомлений о системных тревогах. В этом случае Pagerduty не требует профиля, потому что событие сопоставляется с сервисами Pagerduty, а не с отдельным человеком. Поэтому в данном случае профиль можно оставить пустым.
Неполный запрос курьерской входящей почты и тостов
Итак, вы решили, что вам нужна более централизованная лента уведомлений, и внедрили в свое приложение функцию Inbox от Courier. Наше демонстрационное приложение, безусловно, хорошо выглядит, а с дополнительными возможностями настройки под внешний вид вашего приложения и бренда, как можно устоять. А для разработчиков, использующих нереактивные сборки, у нас есть встроенная интеграция.
Прелесть Toast в том, что каждое уведомление позволяет разработчикам передать CTA (призыв к действию).
Вопрос
Допустим, вы успешно внедрили Courier Inbox и Toast в свой фронтенд с правильными зависимостями, и как Toast, так и Inbox являются дочерними компонентами CourierProvider в вашем приложении.
Все выглядит так, как нужно, и даже предоставлен clientKey в качестве реквизита. После того, как мы смогли отправить запрос и не получили никаких ошибок в наших журналах, мы видим, что в нашем приложении появилось уведомление о тосте, но если мы перейдем к виджету входящих сообщений, он окажется пустым.
Мы видим виджет и 2 уведомления, но куда делись наши уведомления?
Решение
Прежде чем мы погрузимся в ответ, давайте посмотрим на образец запроса на отправку в этом случае.
Это тонкое упущение, но оно имеет значение.
Для того чтобы уведомления из почтового ящика сохранялись, нам нужно добавить to.user_id в запрос SEND вместе с to.courier.channel.
Это необходимо по двум причинам:
- to.user_id используется Inbox для сохранения уведомлений.
- to.courier.channel используется Toast для отображения ваших уведомлений.
Теперь событие запроса/теста должно выглядеть следующим образом:
message: {
to: {
user_id: “user_id”,
courier: {
channel: “user_id”,
}
Как только наш запрос SEND будет включать вышеуказанную конфигурацию, ваши входящие сообщения сохранятся.
Примечание о зависимостях/пакетах
Наша команда в Courier постоянно работает над улучшениями, добавлением поддержки новых функций и исправлением ошибок. Это включает в себя пакеты npm/yarn для CourierProvider, Toast и Inbox.
Если вы хотите обновить свои зависимости, вы можете обновить их, просто изменив package.json на самую актуальную версию и запустив yarn/npm из корня вашего проекта. Мы приглашаем вас связаться со службой поддержки, если у вас возникнут другие вопросы или вы почувствуете, что столкнулись с трудностями.
Все еще есть вопросы?
Это природа бизнеса — всегда задавать вопросы, особенно в нашей сфере деятельности. Эта статья призвана помочь ответить на некоторые из наиболее распространенных вопросов, с которыми мы сталкиваемся при работе с нашими разработчиками.
С учетом вышесказанного, мы считаем, что для того, чтобы сделать общение между программным обеспечением и человеком восхитительным, необходима открытая линия связи с разработчиками, которые внедрили Courier для работы со своей инфраструктурой уведомлений. Мы хотим, чтобы у вас было как можно больше вариантов поддержки, будь то самостоятельное обслуживание с помощью наших документов и статей или 1-1 с нашими инженерами и сотрудниками службы поддержки. Мы здесь, чтобы сделать ваш опыт работы с Courier как можно более гладким! Если вы предпочитаете поддержку на уровне предприятия, запишитесь на демо-запрос прямо сейчас!