Ложка в мозге

Привет, Megalexandros.
Вопрос - огонь. Очень актуальный.

Недавно смотрел запись доклада "История развития фронтенда в Яндексе за 10 лет". В какой-то момент докладчик сказал, что в 2009 году попасть в Яндекс мог обычный верстальщик, без особых знаний программирования и алгоритмов. Что собственно с ним, докладчиком, это и произошло. А сейчас, в 2019 году, подбор намного-намного сложнее и он мог бы только мечтать быть фронтом в такой компании.

Первая мысль была - "Вот ему повезло, проскочил в сферу когда это было легко, а я поздно начал". Но потом подумал "А точно ли легко?".

Я заметил, что сравнивания "тогда" и "сейчас", многие люди упирают на требования для начальных позиций. Мол, раньше от джуна требовали меньше, а сейчас целый СПИСОК навыков. Но при этом, упускают момент, что раньше получать знания, чтобы "войти в it" было НАМНОГО сложнее.

Раньше доступны только оффлайн-курсы (в больших городах) и справочники с задачниками. В помощь только тематические форумы и статьи с хабра.

Сейчас есть онлайн-тренажеры(веб и приложения), вебинары, наставничество, онлайн-курсы, Тостер :). Бизнес на "войти в it" как бы его не ругали, породил огромное количество источников информации (телеграм и youtube каналы, новостные сайты, подкасты и т.д.). И все это с контентом и для новичков, и для опытных людей. Хочешь смотри, читай, слушай.

Конечно хочется на это все сказать, что "вот раньше только "HTML, CSS, JS", а сейчас нужно знат зоопарк технологий!!!"
Но на самом деле "HTML, CSS, JS" так и остались, все прочее - это интрументы чтобы эффективнее и качественнее готовить этот самый "HTML, CSS, JS". Библиотеки, препроцессоры и фреймворки - это кайф. А если тяжело заходят, значит что вы еще плохо знаете основы.

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

Тяжело было всегда, сместились только акценты.

Три варианта:
1. Посылать ивент в батю, батя пошлет деду, так до общего предка, общий предок спустит пропс своим наследникам.
2. Использовать Vuex, изменять там состояние, чтобы другой элемент просто обновлялся при изменении затрагивающих его состояний
3. Общаться напрямую через рут
Компонент1:
this.$root.$emit('eventing', data);
Компонент2:

mounted() {
  this.$root.$on('eventing', data => {
    console.log(data);
  });
}

commit('user_success', userData )

Проведите аналогию например с vk.com.
Во Вконтакте есть API.

Что бы получить данные своего профиля, мы передаём токен.

Например:
У вас есть метод https://api.site.com/account.getProfileInfo?token=...
Выполнив get запрос, вы получите нечто похожее.

{
"response": {
"first_name": "Кристина",
"last_name": "Шипилова",
"bdate": "20.3.1991",
"bdate_visibility": 2,
"city": {
"id": 21940,
"title": "Верхний Мамон"
},
"country": {
"id": 1,
"title": "Россия"
},
"home_town": "Воронеж В- Мамон",
"maiden_name": "",
"phone": "+7 *** *** ** 79",
"relation": 1,
"sex": 1,
"status": "ОБОЖАЮ СИРЕНЬ😎"
}
}

Далее, рассовываете в нужные теги.

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

async asyncData({$axios}) {
      let category_items = []
      let promise_category = $axios.$get(`${process.env.api}/categories.get`,
          {
            params: {
              lvl: 0,
              count: 25,
              offset: 0
            }
          })
          .then(({code, count, items}) => {
            if (code === 0) {
              items.forEach((e) => {
                category_items.push({
                  id: e.id,
                  name: e.name,
                  children: [],
                  deleted_loading: false,
                  lvl: e.lvl,
                  selected: false,
                })
              })
            }
          })

      await Promise.all([promise_category])
      return {
        category_items
      }
    },

Нужен ли Vuex?
Вам решать.

Что означаете «утекла база»?

Это значит что данные содержащиеся в базе получил тот кому они не предназначались.

прошу описать вкратце возможный процесс взлома и как хеширование помогает в данном случае

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

Поэтому пароли в базе данных хранить нельзя! И все нормальные сервисы вроде Тостера не хранят пароли в базе.
Но сервису то нужно как-то аутентифицировать пользователя.
Если в базе хранится пароль - все просто. Пользователь отправил Тостеру пароль, тот проверил, что он совпадает с хранящимся в базе, и все - пользователь подтвержден.
А если пароли хранить нельзя?
Для этого используется хэширование.
В базе данных Тостера хранится не пароль, а хэш пароля - например пользователь Вася создал пароль qwerty, Тостер вычисляет хэш этого пароля -d8578edf8458ce06fbc5bb76a58c5ca4 и сохраняет его в базу данных.
Для того чтобы зайти на Тостер Вася отправляет ему свой пароль - qwerty, Тостер вычисляет его хэш и сравнивает хэш с тем что хранится в базе данных. Если они совпадают - пользователь подтвержден.

В итоге пароли в базе не хранятся, и если злоумышленник скопирует базу себе ( база утекла) он не будет знать паролей пользователя. И не сможет под именем Васи зайти на тТостер.
Все что знает злоумышленник это хэш - d8578edf8458ce06fbc5bb76a58c5ca4

Ну вот примерно так если коротко, и очень упрощенно.

Хэширование никак не защищает содержимое базы и не мешает утечке базы - оно защищает от утечки паролей и только.

Если нет сборки то да

Разумеется сохранять файл на сервер, а в бд хранить его путь

Так вот, какой способ лучшее всего подойдёт небольшому сайту?

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

Во втором случае base64 в реляционной СУБД,
либо в MongoDB (в монге можно хранить файлы)
Некоторые так и делают.

Чтобы каждый раз не обращаться к БД, нужно использовать кэширование. А чтобы сохранить возможность горизонтального масштабирования сайта, кэширование организовывать не в памяти процесса, а на чём-нибудь типа memcached.