Наличие лишнего слоя ни чего не говорит о безопасности
Речь не просто о слое, а об ограничении набора бэкенд функционала выставленного для использования на фронте. По аналогии клиент/сервер со стороны фронтенда просто не будет возможности совершить непредусмотренные действия. Для прототипов или шарашкиных проектов это конечно не имеет значения.
это просто лишний слой, который заставляет вас сеарилизовать и десеарилизовывать данные
Сериализация происходит в любом случае, не все это понимают. В случае использования обертки / API взаимодействия, например, механизм сериализации можно изменить так как существует единая точка входа в логику обмена данными между процессами, например паковать данные в MessagePack формат (иногда это приоритетный вариант).
если конечно вы подцепляете fs и читаете файлик с диска прямо рядышком с вашим шаблоном
При «nodeIntegration: true» это технически возможно. То что технически возможно когда-то происходит, не важно по каким причинам.
но как только у вас появляется отдельные сервисы для вашей бизнес логики, то ни проблем с переносом кода во что то другое ни тем более в веб, не возникает
Те кто использует «nodeIntegration: true» как правило не оборачивают весь вызываемый из main/node/backend процесса функционал в фасад. Поэтому там каша, мешанина веб и бэкенд логики. Такую кашу, как правило, в случае неободимости разгребать/разделять не просто.
Причин много, но даже одна нижеуказанная уже является достаточной.
Чаще всего в крупных/серьезных проектах существует разделение на фронтендеров и бэкендеров, со своей зоной ответственности. Включение флага nodeIntegration позволяет фронтендерам выходить за пределы своих полномочий. Поэтому общение между процессами main/node и renderer/web должно происходить через лимитированный набор функций / API. То есть получается архитектура клиент/сервер. В итоге ответственности разделены и наружу из main процесса выставляется только определенный функционал, безопасность обеспечить проще. Кроме этого получаем побочные преимущества тк веб не завязан жестко на прямое использование API ноды/электрона: 1) например проще мокнуть этот API и тестировать веб часть автономно 2) в случае надобности проще поменять/переключить исполнителя запроса от фронтенда или даже заменить электрон на что-то похожее имея тот же веб. 3) и тд.
ставьте nodeIntegration: false и городите усложненную архитектуру с делегацией запросов.
Если используется подход «nodeIntegration: true», то архитектура как таковая отсутствует и следовательно там нечего усложнять. Использовать подход «nodeIntegration: true» это как делать прямые запросы к базе данных из PHP шаблона в 2020 году.
Зато потом можно сказать что я делаю как написано в книгах по ФП и в блогах 5+ летней давности (когда еще не было for-of). А то что под капотом это «ад» дойдет когда человек сам попадет на нормальное код-ривью.
В данном случае reduce применяется по делу — т.е. ровно для того, для чего оно в общем-то и задумано. И в текущем виде код (для меня) выглядит вполне прозрачно.
for-of:
— лучше читается
— меньше кода
— меньше потребления памяти / дерганий GC
— выше скорость
Единственный плюс reduce это изолированность переменной аккумулятора.
И фаворитом в этой «гонке», как видно из таблицы, оказался обычный метод reduce.
То есть для вас главный критерий это количество строк? Разве на подобных собеседованиях не принято искать того кто будет разгребать говны написанные собеседующими?
reduce:
— читается гораздо хуже чем «for of»
— выделяет лишнюю память на функцию аккумуляции, то есть GC лишний раз будет дергаться
— выделяет лишнюю память на promise обертки, то есть GC лишний раз будет дергаться
— не короче чем «for of»:
async function seriesFetch(urls, callback, params) {
for (const url of urls) params = await fakeFetch(url, params);
callback(params);
}
Новичков всегда можно было определить по неумению работы с reduce
Новичков считающих себя «не новичками» можно определить по использованию reduce там где этого не требуется.
> I have analyzed Svelte commits for last half a year. Please correct me if I am wrong, but there is no a single commit related to Typescript support. There is no slightest sign of any progress in the area. I would like to choose Svelte for a project, but I cannot argue it is the right choice. I would like to know if Svelte team has any roadmap and vision of implementing TS. I also want to know whether they just do care. Just say us when there will be any progress in the direction
Я один из тех кто не любит относительные импорты. Они увеличивают когнитивную нагрузку потому что не всегда сразу «быстрым взглядом» поймешь откуда именно идет импорт если вложенность приличная. Алиасы тоже не очень люблю, мне нравится испортировать относительно корня проекта (да импорты могут быть длинными в таком случае, но зато никакой магии и просчитывать эти .../… не нужно, все сразу понятно откуда берется.
Есть и другие альтернативы: не использовать синтаксис throw и вместо этого всегда возвращать пользовательские объекты ошибок.
Глупая идея потому что если вернуть этот fancy Failable, то в случае если этот Failable не обработать, то код продолжит выполнятся, а вот в случае Exception/Error выполнение прервется. В JS нет способов форсировать обязательную обработку этих ваших Rust-подобных Return, поэтому делать подобные вещи в реальных проектах это большое зло, ну а писать в блоги пожалуйста если хочется.
Хорошо:
import { UserService } from '@services/UserService';
Еще лучше если в линтере будет включено правило запрета относительных импортов, особенно которые идут вверх / где "..." в пути импорта.
Убедитесь, что вы используете следующие хорошие практики для операторов import:
Нормальные фреймворки изначально дизайнились «от состояния (иммутабельного и реактивного)» и вот там не приходится потом год за годом добавлять «костыли» для твикинга работы со стейтом тк перформанс не радует. Реакт дизайнился полагая что dirty-checking ихнего vdom c dom это быстро/модно/молодежно и достаточно чтобы отбросить лишние отрисовки. Но с годами до них дошло что dirty-checking сама по себе не быстрая операция и кроме этого еще и vdom висит в памяти что для для мобилок или слабых ПК тоже не очень хорошо. И вот теперь добавляют свои useMemo и прочие хелперы работы со стейтом когда во взрослых фреймворках это изначально сделано. В итоге из изначально простой библиотеки реакт все больше становится костыльной поделкой.
Второй и третий пункты были изначально известны, так что они не могли быть причиной «разочарования».
По первому пункту, если автор горазд писать подобный код, то стоило бы тогда попробовать объявлять все типы как ReadonlyDeep<сам типа> и не знать проблем (реализацию ReadonlyDeep / DeepReadoly можно легко найти в сети).
Валидация в рантайте не должна быть частью TS тк TS не должен влиять на перформанс в райнайме. Кому нужно делают сами или используют множество существующих для этого библиотек. На практике, валидация в рантайме нужно если в систему поступают «ненадежные / сырые» данные от внешних источников. Но в таком случае в любом, даже строгом и компилируемом языке валидация будет выполнятся кастомным (например по описанной схеме) образом тк «сырые данные» это просто набор байт.
PS logrocket.com известны тем что постят подобные/сомнительные материалы ради некого хайпа, чтобы привлечь внимание к своему сервису. Персонаж Eric Elliott кстати из той же серии.
Сериализация происходит в любом случае, не все это понимают. В случае использования обертки / API взаимодействия, например, механизм сериализации можно изменить так как существует единая точка входа в логику обмена данными между процессами, например паковать данные в MessagePack формат (иногда это приоритетный вариант).
При «nodeIntegration: true» это технически возможно. То что технически возможно когда-то происходит, не важно по каким причинам.
Те кто использует «nodeIntegration: true» как правило не оборачивают весь вызываемый из main/node/backend процесса функционал в фасад. Поэтому там каша, мешанина веб и бэкенд логики. Такую кашу, как правило, в случае неободимости разгребать/разделять не просто.
Чаще всего в крупных/серьезных проектах существует разделение на фронтендеров и бэкендеров, со своей зоной ответственности. Включение флага nodeIntegration позволяет фронтендерам выходить за пределы своих полномочий. Поэтому общение между процессами main/node и renderer/web должно происходить через лимитированный набор функций / API. То есть получается архитектура клиент/сервер. В итоге ответственности разделены и наружу из main процесса выставляется только определенный функционал, безопасность обеспечить проще. Кроме этого получаем побочные преимущества тк веб не завязан жестко на прямое использование API ноды/электрона: 1) например проще мокнуть этот API и тестировать веб часть автономно 2) в случае надобности проще поменять/переключить исполнителя запроса от фронтенда или даже заменить электрон на что-то похожее имея тот же веб. 3) и тд.
Если используется подход «nodeIntegration: true», то архитектура как таковая отсутствует и следовательно там нечего усложнять. Использовать подход «nodeIntegration: true» это как делать прямые запросы к базе данных из PHP шаблона в 2020 году.
remote модуль тоже желательно не использовать, он уже диприкейтнут.
Вместо этого следует использовать IPC коммуникацию в явном виде, то есть без nodeIntegration / remote хаков.
After their initial questions, Joe realized that Ryan committed suicide by jumping off Joe's balcony.
Справедливости ради, Halt and Catch Fire я смог смотреть и мне понравилось, а вот Мистер Робот и Кремниевая долина это муть которая мне не зашла.
— лучше читается
— меньше кода
— меньше потребления памяти / дерганий GC
— выше скорость
Единственный плюс reduce это изолированность переменной аккумулятора.
reduce:
— читается гораздо хуже чем «for of»
— выделяет лишнюю память на функцию аккумуляции, то есть GC лишний раз будет дергаться
— выделяет лишнюю память на promise обертки, то есть GC лишний раз будет дергаться
— не короче чем «for of»:
Новичков считающих себя «не новичками» можно определить по использованию reduce там где этого не требуется.
Видимо все еще хайп на первом месте.
_https://github.com/sveltejs/svelte/issues/3677#issuecomment-590060874 (Feb 23 2020):
> I have analyzed Svelte commits for last half a year. Please correct me if I am wrong, but there is no a single commit related to Typescript support. There is no slightest sign of any progress in the area. I would like to choose Svelte for a project, but I cannot argue it is the right choice. I would like to know if Svelte team has any roadmap and vision of implementing TS. I also want to know whether they just do care. Just say us when there will be any progress in the direction
Еще лучше если в линтере будет включено правило запрета относительных импортов, особенно которые идут вверх / где "..." в пути импорта.
«Убеждаться» не нужно, нужно это автоматизировать github.com/renke/import-sort.
Опять же нет упоминания о включении соответствующих правил линтера.
По первому пункту, если автор горазд писать подобный код, то стоило бы тогда попробовать объявлять все типы как ReadonlyDeep<сам типа> и не знать проблем (реализацию ReadonlyDeep / DeepReadoly можно легко найти в сети).
Валидация в рантайте не должна быть частью TS тк TS не должен влиять на перформанс в райнайме. Кому нужно делают сами или используют множество существующих для этого библиотек. На практике, валидация в рантайме нужно если в систему поступают «ненадежные / сырые» данные от внешних источников. Но в таком случае в любом, даже строгом и компилируемом языке валидация будет выполнятся кастомным (например по описанной схеме) образом тк «сырые данные» это просто набор байт.
PS logrocket.com известны тем что постят подобные/сомнительные материалы ради некого хайпа, чтобы привлечь внимание к своему сервису. Персонаж Eric Elliott кстати из той же серии.