deworker.pro

Открытие нового рабочего сезона

Спасибо всем за ваши предложения по контенту в комментариях и в обратную связь! С вами мы сделали наши видео лучше, чем изначально планировали.

За всё время мы уже записали около сотни эпизодов и пришли к пониманию, куда двигаться дальше. Разобрались, как более качественно записывать и монтировать видео. Подобрали оборудование. Придумали, как улучшить и перезаписать древние эпизоды. И самое время перейти к созданию нового материала и перезаписи старого.

Поэтому открываем новый активный рабочий сезон. Обо всём этом поговорим с вами на стриме:

Открыть в YouTube

  • 00:04:58 - Ответы на вопросы
  • 00:50:50 - Развитие серии про рактический рефакторинг
  • 00:52:18 - Перезапись имеющихся серий
  • 01:05:18 - Продолжение разработки аукциона на Slim и React
  • 01:40:13 - Ответы на вопросы
  • 02:31:30 - Открытие серии про написание HTTP-фреймворка
  • 02:38:01 - Развитие блога Deworker Pro
  • 02:39:20 - Ответы на вопросы

Подписывайтесь на наш канал и Telegram, чтобы не пропускать эфиры.

Комментарии (38)
Павел

Здравствуйте, Дмитрий! Возможно я что-то упускаю из вашего контента, но личном для меня остро стоит вопрос организации структуры папок и файлов в проекте. Сайт разрастается, появляется куча разношерстных сервисов в папке service (сайт - агрегатор товаров), и как все это причесать нет четкого понимания. Было бы классно увидеть акцент на этой части в ваших видео.

Плюс интересна тема SSR.

Ответить
kashamamina

да, SSR действительно будет интересен круто было бы как на подобие разбора с React знакомство с SSR сделать, то есть написать свое базовое решение, а потом показать готовые

Ответить
Дмитрий Елисеев

Вся суть SSR сводится к тому, что вместо динамического рендера в браузере:

const store = createStore(reducer)

ReactDOM.render(
  <App><StoreProvider store={store} /></App>,
  document.getElementById('root')
)

мы сначала рендерим наше приложение в HTML-код на сервере:

const app = express();

app.get( /\.(js|css|png|jpg|ico)$/, express.static( path.resolve( __dirname, '../dist' ) ) );

app.use( '*', ( req, res ) => {
  // Загружаем шаблон страницы
  const template = fs.readFileSync( path.resolve( __dirname, '../dist/index.html' ) );

  // Собираем состояние по req, загружая все нужные странице данные из API
  const initialState = { /* ... */ }
  const store = createStore(reducer, initialState)

  // Рендерим приложение в HTML-текст
  const app = ReactDOMServer.renderToString(<App><StoreProvider store={store} /></App>)

  // Собираем страницу с HTML и слепком состояния
  const html = template
    .replace('</head>', '<script>__STATE__ = ' + JSON.stringify(store.getState()) + '</script></head>'
    .replace('<div id="app"></div>',  '<div id="app">' + app + '</div>')
  )

  // Возвращаем отрендеренную страницу
  res.contentType( 'text/html' );
  res.status( 200 );
  response.send(html)
})

и потом в браузере восстанавливаем состояние и синхронизируемся уже с этим готовым DOM:

const store = createStore(reducer, window.__STATE__)
ReactDOM.hydrate(
  <App><StoreProvider store={store} /></App>,
  document.getElementById('app')
)

чтобы навесились обработчики событий и выполнились хуки.

Ответить
kashamamina

ого, спасибо за такой ответ) и этого будет достаточно в реальном проекте если моя задача это просто чтобы на первый запрос была отправлена готовая страница, а уже дальше рендер происходил полностью на стороне клиента (типа переход по страницам SPA и так далее)?

Ответить
Дмитрий Елисеев

Если вручную, то так. Но вместо этого проще взять уже готовую сборку NextJS.

Ответить
Дмитрий Елисеев

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

Ответить
Фарух

Привет

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

Как в этом случае поступить, выделить отдельный модуль (контекст), который работает с кэшем.

Скажем какой то модуль (контекст) выбрасывает event, и модуль Кэширования как то реагирует(добавляет/удаляет из кэша).
Возникнет ли проблема: race condition и тд
Вообщем как это все грамотно организовать?

Был бы благодарен, если вы запишите пару роликов на эту тему.

Спасибо ;)

Ответить
Дмитрий Елисеев

Кэширование используется в основном при выводе контента и для экономии запросов на чтение к сторонним API. К самой доменной модели кэширование никак не относится.

А так да, пишут слушатели, которые по нужным событиям очищают нужные места кэша или предзаписывают денормализованные копии данных в ElasticSearch или Redis для быстрого поиска и вывода.

Ответить
Игорь

Здравствуйте, команда деворкера! Очень нужны знания по построению микросервисной архитектуры высоконагруженных проектов. Спасибо за созданные материалы, очень полезно.

Ответить
Дмитрий Елисеев

Будут, но не скоро. А сейчас в аукциное у нас будет модульный монолит, где мы будем разбивать код на отдельные модули почти так же, как на сервисы.

Ответить
slo_nik

Добрый день, Дмитрий.

Было бы интересно более расширенное видео о безопасности сервера nginx.

У каждого свой подход, а как Вы решаете подобные задачи? Что именно применяете и как?

Ответить
Дмитрий Елисеев

Было бы интересно более расширенное видео о безопасности сервера nginx.

Можно поискать статьи вроде этой.

А так мы не используем экзотические настройки и все серверы запускаем в отдельных контейнерах. Так что настроек по умолчанию нам для безопасности вполне хватит.

Ответить
Ruslan

Здравствуйте. Мне бы хороший проект на Symfony зашел, но не API , а полный MVC, чтоб разбор view присутствовал :)

Ответить
Дмитрий Елисеев

Как раз такой классический проект на Symfony был у меня на сайте. Можете сейчас посмотреть его.

Ответить
Ruslan

Со всем уважением, но это SF3. Но все ваши аргументы я выслушал на недавней встрече (youtube) :) . Кстати, там упоминалось, что вы часто бываете на каких-то PHP форумах, не назовете их?

Ответить
slo_nik

Так же было бы интересно узанать, как вынести админку в отдельный сервис и использовать её для всех остальных сервисов. То есть, есть два сервиса, один на домене, второй на поддомене. Как правильно объеденить админку для этих сервисов и как правильно настроить авторизацию в этом случае для админов?

В контексте Symfony 5

Ответить
Дмитрий Елисеев

Как правильно объеденить админку для этих сервисов

Проще сделать отдельный фронтенд админки, из которого работать с админским API всех сервисов.

и как правильно настроить авторизацию в этом случае для админов?

Для аутентификации использовать общий JWT-токен с ID пользователя и ролью. А для авторизации уже в каждом сервисе хранить свои разрешения, привязанные к каждой роли.

Ответить
slo_nik

Благодарю за подсказки.

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

Я представлял это себе так. Делать сервис для админки, на полном symfony, с разделением по домену. То есть, на главной странице админки делать ссылки на разные части, первая для основного домена, вторая часть админки для поддомена. И делать два frontend-a, первый для основного домена, второй для поддомена, от symfony оставить только необходимый минимум.

Но тут ещё вопрос с базой данных. На основном домене и поддомене расположены два разных сайта, но одной тематики и для одного владельца. Есть некоторое сходство по данным. Например заказы, предлагаемые услуги. Правильным ли будет подход объединения баз данных или лучше оставить для каждого сервиса свою базу? Общими сделать только таблицы для регистрации пользователей.

Ответить
Игорь

Дополнение: хотелось бы отдельную страницу с обновляемым списком рекомендуемой литературы с микрорецензиями от Дмитрия и Юлии. С указанием на слабые и сильные стороны.

Ответить
Дмитрий Елисеев

Подробно разбирать каждую книгу будет весьма долго и сложно.

Ответить
slo_nik

В контексте Symfony 5

Тут не так всё просто. На поддомене вообще на yii проект старый подключили.

Возможно надо начать с глобального рефакторинга, а вернее переписать на symfony, а уж потом лепить одну админку?

Ответить
Дмитрий Елисеев

Быстрее будет сначала добавить API-контроллеры и аутентификацию по токену, а потом уже рефакторить и при желании переписывать.

Ответить
Игорь

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

Ответить
Дмитрий Елисеев

В этом вообще нет конкретики. Изначально все ТЗ разные, так как все заказчики разные по опыту и старательности.

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

А опытные заказчики если и знают, то при активном обсуждении проекта и в процессе разработки обнаруживаются новые нюансы или идеи, которые это ТЗ меняют.

Поэтому изначальное ТЗ стоит воспринимать лишь как примерный ориентир для начала обсуждения.

Ответить
Игорь

Спасибо! Крутой стрим получился!

Ответить
Максим (@myks92)

Здравствуйте, Дмитрий!

Увидел поздно про стрим хотелось бы уточнить пару вопросов/предложений по Аукциону:

  • В аукционах часто бывает такое, что формируют портфели, чтобы продавать несколько вещей или активов (долги, квартиры, земли, гаражи и т.д.) одним лотом. Планируются ли портфели?
  • В некоторых аукционах видел использование подписание продажи с помощью Электронно Цифровой Подписи (ЭЦП). Думаю, что это бы было интересно внедрить в Аукцион для каких-то Важных сделок, такие как Долги, Недвижимость (44-ФЗ, 223-ФЗ), которые требуют подписания документов. Кроме того ЭЦП сейчас внедряется довольно часто и много где. Поэтому было бы интересно рассмотреть это в рамках аукциона.

Если не сложно - можете ответить по этим вопросам/предложениям касаемо дальнейших скринкастов.

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

Ответить
Дмитрий Елисеев

Планируются ли портфели?

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

Ответить
Дмитрий Елисеев

В некоторых аукционах видел использование подписание продажи с помощью Электронно Цифровой Подписи (ЭЦП)... Для каких-то Важных сделок, такие как Долги, Недвижимость...

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

Так что имеет ли смысл делать ЭЦП для бытового аукциона без важных сделок - вопрос весьма сложный.

Ответить
Александр

Здравствуйте ! А когда начнут выходить эпизоды по psr framework ?

Ответить
Дмитрий Елисеев

Уже записываю. Так что скоро.

Ответить
Владимир Перепеченко

Про то, как заходит новый формат скринкастов:

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

  2. У Вас слушатели разных уровней. Часто я, слушая Ваш интересный материал обламываюсь и не могу понять то, что дальше происходит, т.к. я еще не имел опыта с некоторыми технологиями.

Вот примеры тем, на которых я спотыкаюсь:

  • Slim фишки - slimроуинг, middleware и пр.
  • Symfony Doctrine ORM
  • DI
  • ....

Без этого, мне бесполезно смотреть дальше, а где я могу заполнить пробелы в знаниях- не пойму.

Поэтому возможен варант:
Вы составляете список технологий, шаблонов, методик используемых в скринкасте, без которых не будет понимания того, о чем говориться. И даете этот список в описании каста со ссылками на Ваши уроки/материалы\курсы\статьи, где можно пробел восполнить, чтобы пойи дальше. Статьи и документация, понятно, моут быть и не Вашими :)

Ответить
Дмитрий Елисеев

Изначально все эти темы можно посмотреть в моей старой серии по написанию фреймворка на моём личном сайте elisdn.ru, по которой сейчас буду записывать новую здесь.

Ответить
Владимир Перепеченко

Да, я тоже поддерживаю идею поиска по всем комментам.

Даты создания и обновления каста важны, ибо иначе не понять, что каст обновлялся.

Ответить
Роман

Все конечно интересно, но очень глубоко иногда очень очень.

Было бы как по мне не плохо что то для более быстрой разработки, например ларавел или yii Какой то тоже реально вымышленный проект.

Часто нужно клиентам быстрый результат, но это не получился сделать быстро (то как делается аукцион например видео обучение).

Возможно делать паралельно такого плана видео. Что скажете?

P.S. Я еще со времен интернет магазина на yii2 и переделки фреймворка на отдельное ядро, сервсисы и прочее. Очень интересный подход, можно сделать шаблон и использовать для быстрой разработки в принципе, но моментами кажется что это не оптимальное решение и возможно сейчас уже есть более оптимальное может в связке с ларавел?

Ответить
Дмитрий Елисеев

В Yii со времён проекта магазина ничего не изменилось. Тот код для Yii2 до сих пор актуален, так как вторая версия фреймворка не меняется, а третья ещё не вышла.

В Laravel же, наоборот, со временем много чего меняется. Так что материал вроде нашего проекта объявлений местами быстро устаревает.

А для быстрой разработки достаточно делать просто как в документации.

Ответить
Максим (@myks92)

Дмитрий, будет ли какой-то новогодний стрим о планах, сроках и т.д. На подобии данного) Было бы интересно)

Ответить
Дмитрий Елисеев

Будет стрим с рецензированием требований и дизайна для серии о задании.

А планы пока не поменялись.

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu