AK
В го весь вывод ачинхронный по-дефолту
вот и я о том же. Говорить, что javascript асинхронный, а го - нет - глупость
Size: a a a
2020 April 03
p
нет, у меня здесь только public api 😃 и про него речь
сильно зависит от такого насколько хочешь заморочиться. посылая userID как ты планируешь контролировать что это корректный id?
VS
читаю, вопрос как это работал у автора демо
еще раз говорю, у многих девайсов есть определенные тайминги, там не стоят армы как в топовых самсунгах, на питоне программа может выполняться дольше, чем эти тайминги и поэтому там на них насрать поэтому нужно прочитать даташит и убедиться, что твой код на го выполняется за время необходимое для реакции контроллера.
VS
например, взять экран 44780, там тайминги по 40 мс бывают, особенно на стадии инициализации
RS
сильно зависит от такого насколько хочешь заморочиться. посылая userID как ты планируешь контролировать что это корректный id?
вот кстати хороший аргумент, ведь тут дополнительная проверка на существование пользователя понадобится
VS
если ты туда бахнешь без таймингов, то контроллер не увидит всего этого праздника жизни, все последовательности будут сливаться
p
нет, у меня здесь только public api 😃 и про него речь
и то что ты хочешь impersonate в 1м случае делается довольно просто: делается CreateDebugSession(userID) и она живёт в debug-части api
p
вот кстати хороший аргумент, ведь тут дополнительная проверка на существование пользователя понадобится
и главный вопрос - зачем во втором случае таскать UserID? и если ты его таскаешь, зачем нужна сессия?
RS
и то что ты хочешь impersonate в 1м случае делается довольно просто: делается CreateDebugSession(userID) и она живёт в debug-части api
вобщем у варианта Б есть 2 недостатка:
1. лишняя явность (и лишние байтики, но это не страшно)
2. надо чекать существование user’а по ID, что в случае userid из сессии не требуется
странно тогда, почему 61% проголосовали за второй вариант (изначало было аж 80%)
1. лишняя явность (и лишние байтики, но это не страшно)
2. надо чекать существование user’а по ID, что в случае userid из сессии не требуется
странно тогда, почему 61% проголосовали за второй вариант (изначало было аж 80%)
p
вобщем у варианта Б есть 2 недостатка:
1. лишняя явность (и лишние байтики, но это не страшно)
2. надо чекать существование user’а по ID, что в случае userid из сессии не требуется
странно тогда, почему 61% проголосовали за второй вариант (изначало было аж 80%)
1. лишняя явность (и лишние байтики, но это не страшно)
2. надо чекать существование user’а по ID, что в случае userid из сессии не требуется
странно тогда, почему 61% проголосовали за второй вариант (изначало было аж 80%)
я ж не просто так сказал про public/private. 2й вариант проще тестировать
RS
я ж не просто так сказал про public/private. 2й вариант проще тестировать
> 2й вариант проще тестировать
поясни плиз 🙂
поясни плиз 🙂
RS
и главный вопрос - зачем во втором случае таскать UserID? и если ты его таскаешь, зачем нужна сессия?
impersonation, по большей степени
p
> 2й вариант проще тестировать
поясни плиз 🙂
поясни плиз 🙂
проще написать тест, когда у тебя в чистая функция )))
RS
проще написать тест, когда у тебя в чистая функция )))
а чем она не чистая то? 🙂 userID передаётся так или иначе, просто в сессии запроса
p
а чем она не чистая то? 🙂 userID передаётся так или иначе, просто в сессии запроса
ну так можно всё сложить в context.Context и тоже сказать что у нас чистая ф-я ))
RS
ну так можно всё сложить в context.Context и тоже сказать что у нас чистая ф-я ))
