Андрей Хохлов

не нужны. ребята придумали турбо-страницы, чтобы зарабатывать на вас.

https://vc.ru/seo/48902-pochemu-vam-ne-nuzhny-turb...

арендовать впску и поставить амнезию, инструкция есть здесь

дизайнер предоставляет фигму или фотошоп.

Ваш фронтендер все собирает на реакте.

Как мне кажется это наиболее оптимальный путь.
Плюс фронтендер должен составить список требований к дизайну.
Как то:
Именогвание групп и элементов и стилей
Состояния активных элементов
карту желательных цветов

поможет ли запись бессмысленной информации - стереть предедущую и предотвратить ее восстановление?

Да, поможет. Однако, необходимо держать в голове специфику вашего устройства.

На жёстких дисках (HDD) у вас есть возможность записать новые данные поверх именно в те сектора, где хранился стираемый файл. Благодаря этому вы можете взять программу наподобие Eraser и стирать информацию "таргетированно".

Сейчас эта ситуация начинает изменяться - у самых новых жёстких дисков начали появляться трансляторы, похожие на те, которые используются в SSD.
Кроме того, часть моделей использует технологию Shingled Magnetic Recording (SMR), из-за которой возникает вопрос о том, что происходит с лентой, которая сначала записывается в медиакэш. Под капотом эта технология далеко не так проста, как кажется, но говоря кратко, даже формально будучи временным, дублирование информации в разных областях диска оставляет поводы для сомнений.

На твердотельных накопителях (SSD), флешках, и картах памяти записать информацию в нужный сектор не получится из-за механизма wear leveling, равномерно "размазывающего" данные по всему объёму флэш-памяти.

Однако, у ССД есть TRIM, на который отчасти можно положиться, и который часто становится причиной безвозвратной потери информации после случайного удаления.
Но в связи с тем, что наша цель - гарантированное удаление, безопаснее будет действительно заполнить свободное место какими-либо неважными данными.

И HDD и SSD можно затереть целиком, запустив тест записи "по всей поляне", любым софтом, который такое умеет. Например, Р.тестером. В качестве бонуса к затиранию бесплатно получите отчёт о состоянии поверхности/памяти.

Для обоих вариантов нужно помнить, что сектор с секретными данными может быть переназначен накопителем и выведен из пользовательского адресного пространства. После чего перезаписываться будет уже подставленный на его место резервный сектор, а не изначальный.

Это уже одна из последних степеней беспокойства, приближающаяся к паранойе - в большинстве случаев доступ к содержимому переназначенных секторов и медиакэшу требует серьёзных знаний и специального оборудования. Информацию простого пользователя искать таким образом станут вряд ли.

Но если вы удаляете какую-то серьёзную корпоративную информацию, или секреты государственной важности, о последнем абзаце стоит помнить и рассмотреть идею физического уничтожения диска (либо его размагничивания специальными устройствами). Это наиболее безопасный способ, который поможет всем участникам процесса (в т.ч. и диску - ba-dum-tss!) спать спокойно.

Если говорить о юнит тестах:

Контроллеры - тестим, что отдаются верные статус-коды и дергаются нужные сервисы. Можно проверять ответ, можно проверять валидацию параметров

Сервисы - удобнее тестить когда используется паттерн с репозиторием, а в сервисе зашивается лишь бизнес-логика без обращения к БД.
Просто тестируем бизнес-логику зашитую в сервисе, имплементация репозитория/ORM мокается.

Если говорить о e2e тестах:

Можно использовать supertest. Как и в остальных языках/фреймворках - создается тестовая база, забивается различными необходимыми для теста данными (с помощью фабрик, фикстур). В тестах идет прямое обращение к эндпоинтам и сравнивается результат, будто бы мы тестили это вручную в swagger'е

Смешались в кучу кони, люди, GSAP, React, Three.js... Стоит немного систематизировать инструменты хотя бы по задачам, которые они решают. Не привязываясь к конкретным фреймворкам из большой троицы, у нас есть несколько классов инструментов в теме креативных сайтов:

• Про готовые CSS-анимации - animate.css, Wow.js, и.т.д. Там много динозавров из времен jQuery. Такие штуки часто бывают не в тему дизайна, но стоит посмотреть и забыть. Хотя для сайтов в духе дизайнерской дичи, вроде той, что успешно делают в студии Артемия Лебедева - может быть и ок.
  
• Про интерполяцию всего и вся. Тут обычно выбирают между GSAP и Anime.js. Первый вариант - более замороченный, есть полезные плагины, второй - попроще, но тоже хорош, в некоторых кругах даже более популярен. Для совсем простых задач - можно свой инструмент написать.
  
• Про скролл, в основном в контексте CSS-анимаций. Тут Locomotive Scroll рулит.
  
• Про переходы между экранами. Грубо говоря прокаченный роутер. Самый популярный - Barba.js. Раньше еще был Highway.js, но в последне время что-то про него мало говорят.
  
• Про экспорт готовых анимаций из софта для анимаций. Тут нужно отталкиваться от софта. Обычно вопрос возникает в контексте AE и простых мультиков - тут Lottie, говорят, неплох. Но нужно дизайнера заранее консультировать по теме, чтобы лишнего не намалевал.
  
• Про визуализацию данных. Тут полезно знать про d3.js, в основном ради готовых примеров.
  
• Про трехмерный WebGL, чтобы не писать все руками. Самый популярный вариант - Three.js, в основном за счет экосистемы и горы готовых решений, но есть и альтернативы на любой кус и цвет. Для 2D -эффектов вообще ничего не нужно в большинстве случаев.
  
• Плюс не стоит забывать про всякие вспомогательные штуки вроде WebFontLoader, Hammer.js, LeaderLine, и.т.д. К анимациям они не относятся, но в работе могут быть полезны, чтобы не писать все самому.
  

Но самое интересное то, что эти инструменты не делают работу сами по себе. Они - лишь вспомогательные штуки, чтобы не писать самому некоторые шаблонные куски проектов. Очень часто можно заменить одно на другое в рамках конкретного класса задач и сложность конечной работы, которую нужно сделать, не изменится никак, потому что реальная сложность заключается в необычной верстке, где нужно сначала понять, что там вообще нужно сделать, а как именно - уже не важно, в хитрых математических расчетах, в адаптивности, где нужно впихнуть невпихуемое, в вопросах доступности в контексте конкретного дизайна, в производительности и способности предотвратить проблемы с ней еще на этапе дизайна, в исправлении проблем кроссбраузерности, которые появляются совершенно внезапно, и.т.д. Эти вещи не особо автоматизируются.

А вообще угадать весь стек на много проектов вперед с первого раза, не имея ни малейшего представления о том, что там будет нужно, а что нет, скорее всего все равно не получится, так что может быть стоит попробовать разное в разных проектах (тем более речь идет про некоммерческие проекты, можно себе позволить), и посмотреть на то, какие вообще варианты бывают в разных классах задач, и что они помогают делать, а что - нет.

а как тестировать крупные приложения?

Да точно также.

Как понять, что именно мне нужно покрыть тестами?

Этот вопрос решает тест-анализ.
Как за минимальное количество прогонов узнать как можно больше о состоянии приложения, и чтобы это принесло как можно больше пользы.

Ведь по логике нужный каждый кусок покрывать, чтобы быть на 100% уверенным в этом коде?

Да, но полное покрытие - это очень дорого, и часто не оправдано.

По тому, если приоложение большое, а тестов нет:
1. Покрываем самое критичное и важное, без чего просто жить нельзя, если оно поломается.
2. Покрывает то, где много изменений происходит, и есть шанс случайно поломать.
3. Покрываем всё новое, как часть реализации фичи.
4. Юнит тестами ещё есть смысл покрыть всякие общие компоненты, которые используются тупо везде.

Всё старое, стабильное, изолированное, считается, что нет большого смысла тестировать, тк оно уже за долгое время вдоль и поперёк протестировано пользователями.
Но со временем лучше повышать процент покрытия - например, когда нет особо других задач или появилось лишнее время.

А vue тут ни при чём.

Если вам непонятно значение терминов декоратор, dto, модуль, сервис и тд, то советую для начала ознакомиться с паттернами проектирования, например, здесь: https://refactoring.guru/ru/design-patterns/
Можно найти отдельную книгу по паттернам и прочесть её, можно взять курс, посмотреть видео на YouTube - как душе угодно.

После этого я бы начал постепенно изучать документацию интересующего вас фреймворка и параллельно гуглить зачем нужна та или иная сущность, если непонятно. Чтобы изучение фреймворка не было беспорядочным и хаотичным, можно опять же взять любой курс, который проведет вас за ручку по основам, а дальше уже дело вашего любопытства.

Если говорить про сниппет кода из вашего примера, то для понимания что здесь происходит можно почитать про JWT (Json Web Token) и библиотеку Passport.js и в целом какие бывают способы авторизации/аутентификации и как они работают

Важные данные обычно никогда не хранятся на клиенте, они передаются, используются и удаляются.

Есть ли какие-то ситуации, когда использование httpOnly сессионной куки нас защищает, а вот использование localStorage и sessionStorage уязвимо?

Если есть компроментация клиента, то никак не защищает. Единственное место, это где JS вообще в принципе не используется, т.е. клиенты с отключенным JS. Ну это как в рыцарских доспехах ходить по улице. Неудобно, но вроде как защищает от меча. Только с мечом уже давно не ходят, все больше с автоматами.

Теперь про токены. Токены в теории лучше всего держать не в localStorage, а в sessionStorage. Это хранилище переживает перезагрузки страниц и не расшарено между табами. Т.е. при открытии того же самого адреса в новом табе будет созданая новая сессия. Хранилище очищается при закрытии браузера и таба. Но это жутко неудобно, каждый раз логиниться. Поэтому здравая логика говорит об использовании localStorage, хотя если вы совсем отбитый, то можете хранить токен в сессионой куке.

Если вы прочли те статьи внимательно, то можно понять, что преимущества сессионных кук нивелируются неудобством их использования.
JWT Токены предназначены для микросервисной архитектуры. Т.е. у вас есть некоторый центр аутентификации, который выдает вам токен. Токен этот подписан относительно стойкой криптографией и постоянно ротируется.
Этот токен передается другим микросервисам, которые могут его верифицировать через публичные ключи (JWKS).
Т.е. если вы хотите, вы можете строить свои сервисы так, что они доверяют не только вашему центру аутентификации, но и гуглу с амазоном через OpenID. Есть ситуации, например когда вы хотите разрешить доступ к сервису сотрудникам другой компании. Например, когда такая компания огромна (десятки тысяч сотрудников). Они аутенфицируются у себя, а вы проверяете, что токен выпущен сервисом данной компании. Это не так сложно реализовать.
Реализация авторизации лежит на плечах каждого микросервиса и напрямую завязана на бизнес-логику. Как правило это некий внутренний микросервис, который интегрирован c middleware микросервиса.

Надо понимать что вы имеете в виду под фразой "когда клиент выходит с сайта", и какие конкретно вебсокеты используете - стандартные, или либу Socket.io работающую по Websocket транспорту.

• Если подразумеваете закрытие вкладки браузера клиентом (как пример), то в этот момент браузер разорвёт соединение с socket.io сервером, а на сервере произойдёт событие `disconnect` у конкретного сокета, который был привязан к данному подключению.
  Более того - при закрытии вкладки с сайтом, у Vue не вызывается `beforeUnmount` или `unmounted`, поэтому ваш код не сработает - клиент (браузер) ничего не отправит, сервер ничего не получит.
  *Но это можно реализовать самому через слушатель события `beforeunload` у `window` (правда событие не сработает, если произойдёт вылет браузера или самой ОС) , подробнее тут:
  https://forum.vuejs.org/t/detect-browser-close/5001/2
  https://developer.mozilla.org/en-US/docs/Web/API/B...
  https://developers.google.com/web/updates/2018/07/...
  https://developer.mozilla.org/en-US/docs/Web/API/W...
  
  
• Если подразумеваете выход из учетной записи клиента на сайте, то ваш код сработает
  

Пример обработки первого случая (когда клиент выходит с сайта закрывая вкладку) на серверной стороне, если используете Socket.io (по аналогии можно и с обычными вебсокетами, но там придётся детектить разрыв соединения на базе отсутствия ответа на ping-pong со стороны браузера):

// https://socket.io/docs/v4/server-initialization/
import * as Server from 'socket.io'
const io = Server()
io.listen(3000)

// коллекция сокет-подключений
const connections = new Set()

// когда Socket.io сервер словил новое подключение
io.on('connection', (s) => {
  // добавляем это подключение в коллекцию
  connections.add(s)
  // слушаем событие отключения сокета и реагируем на него
  s.once('disconnect', () => {
    // удаляем данное сокет-подключение из коллекции
    connections.delete(s)
  })
})
// connections.size - покажет размер коллекции, то есть количество подключенных клиентов к серверу Socket.io (онлайн на сайте в вашем случае)

Однако данный код можно не использовать в таком виде, тк в Socket.io уже есть под капотом готовые функции и коллекции для работы с подключенными сокетами, поэтому нет необходимости создавать и хранить в памяти свои собственные списки сокет-подключений.
Например в v4, количество/список подключенных клиентов можно получить таким способом:

// https://socket.io/docs/v4/server-instance/#Server-engine
io.engine.clientsCount
// или:
// https://socket.io/docs/v4/server-api/#namespace-allSockets
await io.allSockets()