DF
А мне нужно подключить какую-то либу, или с нуля писать всё?
API телеграма работает на подобии вебхуков. Тебе нужно научиться открывать порт, слушать эвенты и выплевывать в ответ какой-то json.
Size: a a a
2020 November 11
DF
Начни с этого.
DF
GET / -> {}.DF
Минимальный сценарий.
X
На расте такое уже делал
X
Я тут нашёл nadia, сейчас попробую с ней что-то сделать
AB
Когда я пробовал, вебхуки плохо работали. Медленно. Быстрее было делать лонгполл
DF
Для практики и такой вариант сойдёт.
DF
Это же велосипед, не предназначенный для серьезного продакшена.
LL
Чат, как тестируете функциональность связанную с базой?
Анонимный опрос
Проголосовало: 36B
Либо вообще не тестирую)
LL
Очень интересно узнать почему такие варианты
Я использую сиды, потому что это легко и удобно, но я слышал поинт, что сиды могут не отражать реального состояния данных, потому что эти данные попадают в базу через апи, которое и определяет их поведение
Я использую сиды, потому что это легко и удобно, но я слышал поинт, что сиды могут не отражать реального состояния данных, потому что эти данные попадают в базу через апи, которое и определяет их поведение
V
что такое сиды?
точнее, в чём разница между сидами и инициализацией?
точнее, в чём разница между сидами и инициализацией?
AN
Очень интересно узнать почему такие варианты
Я использую сиды, потому что это легко и удобно, но я слышал поинт, что сиды могут не отражать реального состояния данных, потому что эти данные попадают в базу через апи, которое и определяет их поведение
Я использую сиды, потому что это легко и удобно, но я слышал поинт, что сиды могут не отражать реального состояния данных, потому что эти данные попадают в базу через апи, которое и определяет их поведение
так тебе свое апи и надо тестировать, работу Ecto тестируют в Elixir Core Team очень тщательно
B
V
что такое сиды?
точнее, в чём разница между сидами и инициализацией?
точнее, в чём разница между сидами и инициализацией?
Кстати тоже интересно 🤔
V
А, понял. Конечно, правильный способ - через существующие функции (внутреннее или внешнее api). Но иногда это заёбно и проще накидать в базу.
RK
Очень интересно узнать почему такие варианты
Я использую сиды, потому что это легко и удобно, но я слышал поинт, что сиды могут не отражать реального состояния данных, потому что эти данные попадают в базу через апи, которое и определяет их поведение
Я использую сиды, потому что это легко и удобно, но я слышал поинт, что сиды могут не отражать реального состояния данных, потому что эти данные попадают в базу через апи, которое и определяет их поведение
ИМХО: Если логика простая и данные почти напрямую кладутся в базу - с сидами норм.
Если на API-call может происходить дохрена логики и сайд-эффектов в разные таблицы и/или большая часть валидаций не отражена в базе - лучше через API херачить.
С идеалистичной точки зрения лучше через API. Сиды - упрощение ради продуктивности.
Если на API-call может происходить дохрена логики и сайд-эффектов в разные таблицы и/или большая часть валидаций не отражена в базе - лучше через API херачить.
С идеалистичной точки зрения лучше через API. Сиды - упрощение ради продуктивности.
RK
Если математично, то сиды безопасны если "любое корректное содержимое базы является корректным состоянием приложения"
AN
с сидами
async: true хрен получишь, так что сидить лучше самый минимум, типо одно юзера, который везде нужен, но ни в одном тесте не изменяетсяRK
с сидами
async: true хрен получишь, так что сидить лучше самый минимум, типо одно юзера, который везде нужен, но ни в одном тесте не изменяетсяМожно если сиды маленькие, под конкретные случаи и заливаются в сетапе теста.
Но с большими сидами так делать - извращение, да)
Но с большими сидами так делать - извращение, да)