Разница реально незначительная, как показали выше. Таких оптимизаций в js может быть много (for вместо других итераций и т.п.), но суммарно они дают очень мало выгоды, можно легко свести на нет все оптимизации одним непродуманным кусочком кода или плохой архитектурой.
Какой то вброс кликбейтный. "Согласно статье 205.1 УК РФ, финансирование терроризма включает сбор или предоставление средств с сознанием того, что они будут использованы для террористической деятельности. Это значит, что уголовная ответственность наступает только если: – У вас был прямой умысел, то есть вы осознавали, что ваши средства идут на поддержку терроризма. – Есть доказательства, подтверждающие вашу причастность (переписка, намеренные действия и т.д.). "
Недальновидное название. В рамках будущей борьбы с тлетворным влиянием запада придется переименовывать. Тогда уж NashMag или NashaLavka. Или вообще что то в духе "ВторЧерМет" или "НАРКОММЯСОМОЛПРОМ"
Путешествия к звездам... Мы тут 10 тыс лет планету перекраиваем, все никак поделить не можем. А так мечталось несколько десятилетий назад, вот еще малость и мы на марсе, а там и до альфа-центавра рукой подать Но за публикацию спасибо
Прямо таки "русскми" прямо таки "запретят" ? Языковой тест при проведении операции или "по паспорту" запрещать будут? А если русский но с канадским паспортом - не повезло?
Для REST API тоже можно сделать возможность указывать какие поля нужно вернуть.
Указание полей ожидаемых в результате крайне маленькая часть GraphQL . Поля указать можно в REST, но поля вложенных объектов с аргументами указать будет уже сложнее и распарсить в REST особенно если они меняются. Как говориться "можно, а смысл"? В GraphQL сам запрос древовидный, отличается по идеологии от REST
Если при REST API на беке можно было написать запрос с JOIN
Все верно и в случае с GraphQL - не имеет разницы - можно написать такой же запрос чтобы вернуть такие же данные за один раз. Если нужны связанные (вложенные) данные которые не вернуть одним запросом - делать несколько запросов к БД придется и в REST и в GraphQL.
Настройка Nginx выходит за рамки данного решения - если его убрать/заменить в приложении ничего не изменится. Если же этот участок (между клиентом и приложением) не был описан - место и цель использования приложения будет не верно понято. Нет смысла рассматривать данное приложение как решение для энтерпрайз, не совсем понятно откуда требования такие, спецификации, тонна документации. На 300 строк кода? Данное приложение как раз для тех случаев, когда не хочется тратить время попытки "осилить большие комбайны".
Мне жаль, но, тут, вероятно, опыт сдерживает понимание. Попробую разъяснить, jwt в данном случае вообще не имеет значения, он не объект статьи и не тема. На его месте в схеме может быть хоть cookie, хоть что угодно. В статье указано что он (jwt) пустой (без полезных данных) исключительно чтобы не отвлекать, "для удобства и простоты демонстрации"., так понятнее? То есть никто не запрещает потом туда включать полезные данные. Но если jwt пустой, то он не становится решением равнозначным cookie, потому что никто же не будет менять решение каждый раз под определенные параметры? Опять же статья не о jwt, он здесь для показа возможности связки приложения с внешними данными.
Боюсь что авторизация это как раз не на этом этапе, а там, куда дальше уходит запрос ( на схеме "API"). В самом приложении "AUTH" только аутентфикация.
Смысл слов "используется для удобства" - в том смысле что нет никакой привязки к нему, можно использовать вместо него что либо другое, хоть http node.js - кий, хоть express.
Данное решение не отрицает ни один из стандартов, это именно приложение, с помощью которого можно реализовать как собственную реализацию (от банального проверки пароля) до всех других протоколов.
JWT и cookie - это все таки разные вещи)) просто в данном случае в jwt не вкладывается ничего лишнего, это дает гибкость в оперировании данными, представьте что какой то микросервис хочет дополнить данные пользователя - ДО того как он обратиться к сервису. (просто пример)
Про "приватный ключ" совсем не понял, честно говоря, это не из статьи?
Насчет в "прод" - ну я то использую, мне удобно чем каждый раз в проекты тащить что то большое, тут конфиг подправил и готово.
Но спасибо, хотя бы понял что статью надо дополнить и расжевать.
Вполне может быть, дело было года 3-4 назад.
Но яндекс все равно избегаю.
Суть комента была в том, что не ездить — как минимум лучше чем отвечать подлостью на хамство, поскольку водители отвечают тем же — но уже другим клиентам.
Вижу в вашем комменте нерациональную интонацию какой-то неоправданной обиды. )) Вы зря приняли комент на свой счет — катайтесь на здоровье, заказывайте хоть по десть машин друг за другом — кто ж вам мешает.
https://messages.google.com/web/conversations
Как минимум на Android с смс даже искать ненадо - Google позаботился
Разница реально незначительная, как показали выше.
Таких оптимизаций в js может быть много (for вместо других итераций и т.п.), но суммарно они дают очень мало выгоды, можно легко свести на нет все оптимизации одним непродуманным кусочком кода или плохой архитектурой.
Какой то вброс кликбейтный.
"Согласно статье 205.1 УК РФ, финансирование терроризма включает сбор или предоставление средств с сознанием того, что они будут использованы для террористической деятельности. Это значит, что уголовная ответственность наступает только если: – У вас был прямой умысел, то есть вы осознавали, что ваши средства идут на поддержку терроризма. – Есть доказательства, подтверждающие вашу причастность (переписка, намеренные действия и т.д.). "
А "MongoDB Compass" ( https://www.mongodb.com/docs/compass/current/ ) это не то, что должно быть в этом списке?
Золотые слова. Но запоздали. Месяца на полтора
Как говорится - "Назвался груздем - полезай в корзину"
Или к
принудительнойобязательной конвертации валютных вкладов по "текущему курсу ЦБ"Недальновидное название. В рамках будущей борьбы с тлетворным влиянием запада придется переименовывать.
Тогда уж NashMag или NashaLavka. Или вообще что то в духе "ВторЧерМет" или "НАРКОММЯСОМОЛПРОМ"
Соцсети без пропаганды?
Подозреваю что на Марсе колонию проще создать.
Путешествия к звездам... Мы тут 10 тыс лет планету перекраиваем, все никак поделить не можем.
А так мечталось несколько десятилетий назад, вот еще малость и мы на марсе, а там и до альфа-центавра рукой подать
Но за публикацию спасибо
Прямо таки "русскми" прямо таки "запретят" ?
Языковой тест при проведении операции или "по паспорту" запрещать будут?
А если русский но с канадским паспортом - не повезло?
К сожалению,
Quod licet Iovi (Jovi), non licet bovi (с лат. — «Что дозволено Юпитеру, не дозволено быку»)
Указание полей ожидаемых в результате крайне маленькая часть GraphQL . Поля указать можно в REST, но поля вложенных объектов с аргументами указать будет уже сложнее и распарсить в REST особенно если они меняются. Как говориться "можно, а смысл"? В GraphQL сам запрос древовидный, отличается по идеологии от REST
Все верно и в случае с GraphQL - не имеет разницы - можно написать такой же запрос чтобы вернуть такие же данные за один раз. Если нужны связанные (вложенные) данные которые не вернуть одним запросом - делать несколько запросов к БД придется и в REST и в GraphQL.
Понял, спасибо.
Тоже на node.js и nginx реализовали ?
Настройка Nginx выходит за рамки данного решения - если его убрать/заменить в приложении ничего не изменится. Если же этот участок (между клиентом и приложением) не был описан - место и цель использования приложения будет не верно понято.
Нет смысла рассматривать данное приложение как решение для энтерпрайз, не совсем понятно откуда требования такие, спецификации, тонна документации. На 300 строк кода?
Данное приложение как раз для тех случаев, когда не хочется тратить время попытки "осилить большие комбайны".
Мне жаль, но, тут, вероятно, опыт сдерживает понимание.
Попробую разъяснить,
jwt в данном случае вообще не имеет значения, он не объект статьи и не тема. На его месте в схеме может быть хоть cookie, хоть что угодно. В статье указано что он (jwt) пустой (без полезных данных) исключительно чтобы не отвлекать, "для удобства и простоты демонстрации"., так понятнее? То есть никто не запрещает потом туда включать полезные данные.
Но если jwt пустой, то он не становится решением равнозначным cookie, потому что никто же не будет менять решение каждый раз под определенные параметры?
Опять же статья не о jwt, он здесь для показа возможности связки приложения с внешними данными.
Боюсь что авторизация это как раз не на этом этапе, а там, куда дальше уходит запрос ( на схеме "API"). В самом приложении "AUTH" только аутентфикация.
Смысл слов "используется для удобства" - в том смысле что нет никакой привязки к нему, можно использовать вместо него что либо другое, хоть http node.js - кий, хоть express.
Данное решение не отрицает ни один из стандартов, это именно приложение, с помощью которого можно реализовать как собственную реализацию (от банального проверки пароля) до всех других протоколов.
JWT и cookie - это все таки разные вещи)) просто в данном случае в jwt не вкладывается ничего лишнего, это дает гибкость в оперировании данными, представьте что какой то микросервис хочет дополнить данные пользователя - ДО того как он обратиться к сервису. (просто пример)
Про "приватный ключ" совсем не понял, честно говоря, это не из статьи?
Насчет в "прод" - ну я то использую, мне удобно чем каждый раз в проекты тащить что то большое, тут конфиг подправил и готово.
Но спасибо, хотя бы понял что статью надо дополнить и расжевать.
Я разве что то продаю?
А логика "не создавать других решений если есть одно" вообще странная. По ней, если есть KeyCloak то не нужнен OAuth2-Proxy ?
Но яндекс все равно избегаю.
Суть комента была в том, что не ездить — как минимум лучше чем отвечать подлостью на хамство, поскольку водители отвечают тем же — но уже другим клиентам.