Согласен, что плодить новые сущности в виде кастомных компонентов надо тогда, когда можно существенно упростить разметку. Джаваскриптовое поведение можно и через is аккуратно подключить, оставляя понятные всем теги.
Графоманство в ТЗ больше для юридических вопросов. Например, исполнитель что-то не так сделал, тогда конкретно начинают тыкать в такой-то пункт сто страничного ТЗ.
Я тоже сторонник макетов, схем, таблиц. И только в случае необходимости письменных пояснений.
Один из недостатков: json-rpc в спецификации не гарантирует порядок результатов при пакетных запросах. Но я бы не сказал, что это фатально. Если разработчику важен порядок в массиве результатов, то он просто учтет этот момент у себя в коде. То, что нет четко закреплённого списка ошибок - тоже спорный момент.
Статус 200 - это просто успешный транспорт payload. И дело тут не в батчинге.
Насколько я помню, куки по мнению РКН персонифицируют пользователя. По этой причине всю информацию связанную с сессией надо хранить. Понятное дело, что куки разные бывают: одни для персонификации, другие для сохранения настроек отображения сайта и т.п. Но я не увидел нигде: законодатель разделяет эти понятия или нет. Как кому-то потом рассказывать какие у нас куки.
Если не так, то буду рад. Если есть ссылки на нормативную базу, буду только рад.
Все верно сказали. Классические сниппеты явно нельзя использовать. Только динамическое подключение джаваскриптом сайта. Писать такое пару строк.
Когда дают согласие на куки, то можно в localstorage записать инфу. Далее, проверяем при загрузке страницы если такая пометка в localstorage имеется, то динамически добавляем теги скриптов с метриками.
Вот кстати не факт, что выигрыш в производительности будет: так-то и подключение к бд тоже несёт накладные расходы, в виде организации подключения по tcp, проверка прав пользователя и опять же чтения данных из группы файлов. Если необходимо работать с развесистыми данными, писать, читать, уделять внимание безопасности, то да, тут работа с СУБД лучше. А если выбирать между чтением и разбором мелкого json и использованием огромной махины СУБД для той же цели, то первое может быть более оптимальным выбором. Тем более, если чтение, то блокировки файлов не будет.
Прочитал с интересом) Спасибо, что делитесь опытом.
Расскажите, а чем вас SQLite не устраивает? В ноде на данный момент времени он уже нативный. Скорости операций хватит под вашу задачу. Зачем тащить другую СУБД?
Мне кажется, что причина в том, что вотсап не скрывает номер телефона как минимум. С контактом можно и по gsm связаться, если необходимо. Он "открытый" и является дополнением к обычной связи.
А в телеге больше закрытости: номер скрыт и контакт в чате может удалить всю отправленную информацию.
Плюс вполне вероятно, что в Непале распространен именно вотсап.
Редирект на сайт злоумышленника открывает возможность сбора данных из автокомплита, плюс возможна реализация man in middle через проксирование запросов. Ещё злоумышленник может втюхать какой-нибудь apk для андроида с помощью социнженерии. Это те векторы, которые лежат на поверхности. А так, может быть много других сюрпризов.
+1. Действительно! Я-то думал, что будущее уже наступило и все давно поддерживается) Вот оно что. Тогда только кастомное имя остаётся.
https://caniuse.com/mdn-html_global_attributes_is
Спасибо, что делитесь опытом, интересная работа.
Кстати, а почему всё-таки от ваниллы отказались? С какими сложностями столкнулись?
Согласен, что плодить новые сущности в виде кастомных компонентов надо тогда, когда можно существенно упростить разметку. Джаваскриптовое поведение можно и через is аккуратно подключить, оставляя понятные всем теги.
Графоманство в ТЗ больше для юридических вопросов. Например, исполнитель что-то не так сделал, тогда конкретно начинают тыкать в такой-то пункт сто страничного ТЗ.
Я тоже сторонник макетов, схем, таблиц. И только в случае необходимости письменных пояснений.
Можете раскрыть мысль почему long polling по вашему мнению будет дешевле?
Один из недостатков: json-rpc в спецификации не гарантирует порядок результатов при пакетных запросах. Но я бы не сказал, что это фатально. Если разработчику важен порядок в массиве результатов, то он просто учтет этот момент у себя в коде. То, что нет четко закреплённого списка ошибок - тоже спорный момент.
Статус 200 - это просто успешный транспорт payload. И дело тут не в батчинге.
Насколько я помню, куки по мнению РКН персонифицируют пользователя. По этой причине всю информацию связанную с сессией надо хранить. Понятное дело, что куки разные бывают: одни для персонификации, другие для сохранения настроек отображения сайта и т.п. Но я не увидел нигде: законодатель разделяет эти понятия или нет. Как кому-то потом рассказывать какие у нас куки.
Если не так, то буду рад. Если есть ссылки на нормативную базу, буду только рад.
К get-запросу на получение скрипта можно было бы просто добавить "?<lottie_file_version>".
А так, работа с кешем на таком уровне - это больше про офлайн pwa.
Требование к хранению собранной информации о пользователе предъявляется же к администратору сайта.
Все верно сказали. Классические сниппеты явно нельзя использовать. Только динамическое подключение джаваскриптом сайта. Писать такое пару строк.
Когда дают согласие на куки, то можно в localstorage записать инфу. Далее, проверяем при загрузке страницы если такая пометка в localstorage имеется, то динамически добавляем теги скриптов с метриками.
Вот кстати не факт, что выигрыш в производительности будет: так-то и подключение к бд тоже несёт накладные расходы, в виде организации подключения по tcp, проверка прав пользователя и опять же чтения данных из группы файлов. Если необходимо работать с развесистыми данными, писать, читать, уделять внимание безопасности, то да, тут работа с СУБД лучше. А если выбирать между чтением и разбором мелкого json и использованием огромной махины СУБД для той же цели, то первое может быть более оптимальным выбором. Тем более, если чтение, то блокировки файлов не будет.
Тоже поржал. Надеюсь, что они просто валидацию не стали публиковать, иначе зашквар.
Видимо им в своем велосипеде будет проще разобраться, чем в чужом. Ну, и уверенность в безопасности своего кода.
Прочитал с интересом) Спасибо, что делитесь опытом.
Расскажите, а чем вас SQLite не устраивает? В ноде на данный момент времени он уже нативный. Скорости операций хватит под вашу задачу. Зачем тащить другую СУБД?
Балансировку через cluster будете делать?
Забавно. Ссылочку можно?
Согласен, но форма приема обращений не является средством мгновенного обмена сообщениями.
Мне кажется, что причина в том, что вотсап не скрывает номер телефона как минимум. С контактом можно и по gsm связаться, если необходимо. Он "открытый" и является дополнением к обычной связи.
А в телеге больше закрытости: номер скрыт и контакт в чате может удалить всю отправленную информацию.
Плюс вполне вероятно, что в Непале распространен именно вотсап.
Ключевое - это редирект.
Редирект на сайт злоумышленника открывает возможность сбора данных из автокомплита, плюс возможна реализация man in middle через проксирование запросов. Ещё злоумышленник может втюхать какой-нибудь apk для андроида с помощью социнженерии. Это те векторы, которые лежат на поверхности. А так, может быть много других сюрпризов.
Видимо индекс содержимого документов тоже будет лететь в облако.
Спасибо за ответ и за то, что делитесь опытом.