Как зритель могу дополнить пару моментов: - Не сказал о фильтрах, которые ищут последние активные сессии. Можно засунуть в запрос find. В монге агрегации очень дорогие, прибегаем к ним только в редких случаях. Но это больше специфика, тут не все могут быть подкованы. - На счет DI и уровня сервисов умничка что все таки сказал. Интервьюер тебе намекал что тут в архитектуре проблемка :) - Мб я что-то пропустил: не сказал о том, что в GET запросе принимаются параметры, которые должны отправляться в body POST запроса. Немного о том, почему категорически нельзя передавать в query важные данные: любые запросы по сети можно перехватить берп-сайтом/фиддлером, сниффингом на уровне пакетов (через роутер, либо пакеты). Либо через проксю, которая будет на стороне сервера лежать. Интервьюер почти правильно подметил, GET запросы в query можно легко перехватить через снифферы трафика, а с HTTPS POST запросами сложнее, но все же возможно: всякие берпы позволяют расшифровать трафик и получить доступ к телу запроса. Очень мало было вопросов по лиду и системному дизайну. Больше похоже на собес миддла, где хотят проверить какие проблемы в проектировании архитектуры проекта ты видишь. Я знал собесы на лида NodeJS, где проверяют: умения проектировать микросервисы, выстраивать командные процессы (дейлики, ретро, синки). А еще компании часто ищут лида, чтобы решить их архитектурные проблемы: например, команда стоит на месте, мисскоммуникация в техничке и бизнесе. Вообщем-то куча вопросов можно было задать человеку, который должен быть не только повернут в код бекенда, а и во все остальные важные процессы. Еще не спросили про твои достижения и неудачные архитектурные выборы. Это важно, потому что тут кто обжигался не наступит на те же грабли. Каждый наступал на свои грабли и делал выводы, об этом всегда интересно слушать. Печально что таких вопросов тоже не прозвучало. Я сам на ютуб собесы выкладываю, без хейта или негатива. Станем популярны, будем ездить на дорогих porshe, отдыхать на море и работать в маями на пляже в гамаке :))
Сразу видно, что автор видео не использует FSD в реальной жизни. Грустненько... Не вводите людей в заблуждение, FSD - это поворот не туда во frontend-индустрии.
@@НаильШайхинуров-п7л Поворот не туда, так как это с точки зрения теории чистота кода и упрощение, а на практике выясняется, что наоборот. Кто пробовал в реальных проектах в 90% случаев с этим утверждением будет согласен. А про поворот "туда" скажу так - нужно просто включать голову, брать ответственность за выбор архитектуры и структуры проекта на себя, а затем просто использовать любой вариант модульной архитектуры, удобный команде. Со временем архитектура/структура может уточняться - это нормально. Мне неизвестно за 10 лет работы во фронте ни одного случая, что какому-то проекту было лучше с FSD и хуже без него. Я работал в стартапах, в бигтехе, в аутстафе, в аутсорсе. Проекты были следующие: Ecommerce сайты с различными товарами на международном рынке, Real-time админка на web-сокетах с логистикой, сложные админки для управления бизнесом, включающие большую систему модальных окон. календарей. Ни один из этих проектов не был бы упрощен с помощью FSD. Попробуйте просто взять React + ReduxToolkit + TypeScript и сделать пару страниц с бизнес-логикой с FSD и без. Вопросы отпадут сами собой навсегда. Ответил на ваши вопросы?
Отвратительно объясняешь(скорее всего сам не до конца понимаешь что и как устроено), ты хотя бы ручками код написал,чтобы люди видели наглядно последовательность действий (без негатива)
Чтобы тупо дать доступ своим друзьям к сайту на пару минут не нужен хост и домен. Это не выгодно. Да и я не видел доменов за 80 рублей. Самые дешёвые .ru за 190 рублей вроде бы или 120 я хз. А сервер вроде бы vdsina есть тариф 60 с чем-то рублей в месяц
Нет важного вопроса про node_env=production, без этой переменной нода работает в дев режиме так же некоторые пакеты устанавливаются в дев режиме, тот же express
да, но есть важный нюанс. Начать работать, а не учить неделю-две. Если набраться опыта на нем, то потом будет проще. А вообще, все зависит чисто от вас, так что учите то, к чему лежит душа и нравится область применения)
Вопрос про type и interface. В плюсах, например, тоже есть такие понятия как структура (struct) и класс (class), которые с точки зрения реализации - почти одно и то же. Однако среди разработчиков считается хорошим тоном использовать структуры, когда мы хотим реализовать просто составной тип без всяких методов (например, комплексное число), а классы - когда мы хотим, чтобы он описывал сущность, у которой есть как поля, так и методы. Я правильно понимаю, что с type и interface аналогично: оба в большинстве случаев взаимозаменяемы, но type обычно используют для сложных типов, а interface - для объектов с полями и методами?
А угадайте компилятор какого языка в первую очередь выпускает любой разработчик процессоров / контроллеров и/или ISA. Правильно дети. Это компилятор Си. Именно этот ЯП позволит добавит в аппаратную платформу Линукс и/или эти ваши питоны и прочие руби
Си по определению не может быть худшим языком для изучения. 1. Он чрезвычайно простой (особенно если с плюсами сравнивать) 2. На нем так дохера чего написано, что не знать его не получится, если ты планируешь стать серьезным инженером. Ты можешь на нем не писать, но знать ты его будешь. Даже плюсы (грёбаные) изучит смысл имеет по той простой причине что на них Дохера Чего Написано (ДЧН). И в поистине больших проектах у вас будет неиллюзорная потребность сбиндить ваш код с чем-нибудь написанным на плюсах. А делать вы это будете через мост написанный на Си. Вот какая прелесть
Ключевое это ДЧН))) - зачем компании нанимать чела который будет на сях движок бд писать если уже есть опенсорсный PostgreSQL или писать кеш, если есть Redis, зачем нанимать чела который будет писать лоадбалансер для системы если уже есть NGINX и тд. Опенсорс просто заменил челиков которые на сях или плюсах пишут для компании свои велосипеды. Сейчас IT это разработка коммерческого софта который НАПРЯМУЮ решает задачи бизнеса. Нативные языки нужны токо в специфике (по типу быстрых микросервисов на го).
