Дальше будут эмоции. Это блин вообще, что за статья? Она вообще зачем есть? В чем ее цель? Зачем на это было потрачено время? Я думал, что будет интересная история о Дурове, а тут непонятная промо акция за деньги которых большая часть людей, одновременно в одном месте, в глаза не видела…
Лично я здесь за информацией и полезными материалами для развития. Эта статья к ним не относится и лично мне она не нужна, не нужна как посетителю этого ресурса с конкретными целями. И я тоже голосовал бы минусами если бы мог, потому, что иначе статей подобного рода будет больше, а мне это не нужно, я хочу качественную информацию. И те кто ставят минусы в большинстве своем, скорее всего думают также.
P.S. Когда люди расширяют знания человечества (наука), они сначала изучают и стараются понять имеющиеся знания, а затем тратят целую жизнь, чтобы открыть что-то новое. Статьи подобные этой прекрасно показывают, что человек не потратил достаточно времени и усилий для изучения и осознания материалов в которых пытается выставить себя авторитетом. Я отношусь к хабру как к серьезному ресурсу с серьезной информацией в котором почему то стали появляться статьи без токового содержания. Вторая причина минусов, это подача материала и «понт», если человек не прав и готов с этим согласиться, его не будут минусовать, он переведет статью в черновик и исправит ошибки, либо удалит.
Не публикуйтесь и не посещайте ресурс, за товар голосуют рублем, за ресурс голосуют участием. Если Вы уверены, что все так как говорите, то очень быстро на хабре останется только 20-30 человек. Жить в обществе — значит следовать нормам установленным обществом, если общество говорить грабить буржуев, то придется грабить, а то буржуем объявят тебя)
Когда твоя система обвалится под собственным весом, новые программисты не смогут разобраться в хитросплетениях «гениальных решений», а ты будешь жить на работе, на грани нервного срыва внедрять простую фичу в течении уже второго месяца, тогда ты воскликнешь:
— «О хабр, я был не прав, помоги мне!»
Но хабр ответит тебе:
— «Нет.»
Одни умные люди пишут книгу: «как организовать работу IT команды». Другие люди читают эту книгу, и начинают по ней строить свою IT команду, по пути нарушая установленные этой книгой правила и принципы в угоду своему «удобству». А потом идут и говорят, что постулаты из «книги» не работают. Любое утверждение справедливо до тех пор, пока выполняются условия его справедливости (С) Капитан О.
Вот ИМХО но избежать проблем можно было бы если:
1. Выбираем любую готовую CMS с большим комьюнити
2. Запрещайте документировать что бы то ни было кроме того, что внесли сами
3. Зовите Гуру
4. Ваш проект должен состоять из одной зоны ответственности в том числе менеджмента. Если компания нанимает «менеджера» значит не доверяет программисту, тут нужно начинать решать проблему с ее корня. Если программист занимается всем, то пусть занимается всем, что касается программирования, по крайней мере он самостоятельно лучше распределит задачи и выставит приоритеты, а если нет то проблема в программисте, значит он не годится для этой работы. Другой вопрос, что такой спец стоит дорого, иногда слишком, но вы ведь зовете Гуру.
5. Если программист сам отчитывается перед бизнесом, то пятый пункт отпадает.
6. Снова недоверие между руководством и исполнителем и неспособность прозрачно отобразить процесс разработки.
Корневая проблема в том, что бизнес видит в программисте источник расходов. Если он будет видеть в нем перспективу и возможность, то все будет иначе. А для этого нужно сделать процесс разработки прозрачным и понятным, нужно снизить риски бизнеса переложив эти риски на программиста, конечно при условии, что это увеличит гонорар в случае успешного достижения результатов (например, пока сайт лежит программист не зарабатывает).
Ну может не столь радикально, но в целом информации о нас предостаточно, если ее объединить в одну базу или связку баз то вполне возможно уже сейчас определить уникальность человека. Номер у нас есть, это номер паспорта, почти все важные документы имеют свое электронное подтверждение (правда ведь?), получить номера телефонов привязанных к паспортам тоже можно (у нас ведь любят заставлять?), биометрические данные сбер уже собирает (поделится? поделится, заставим, у нас любят заставлять). Все нормально, все осуществимо надо просто сделать, и денег на это много не надо (по сравнению с Российским Фаерволом). В этом и главный минус, много рутинной работы, мало расходов на закупки, это придется платить людям за работу, что немыслимо.
Возможно в крупных столичных компаниях дела обстоят иначе, но в провинции бизнес не предпочитает набирать мидлов. Набирают джунов и сеньоров (иногда мидлов если сеньора не могут найти), в соотношении 10:1. Следуя логике, что на зарплату одного мидла можно нанять 2 или 3 джуна, а 2 или 3 джуна будут работать как полтора мидла (так они думают). А сеньор в этой схеме нужен для того, чтобы подтирать за джунами. Когда джун доростает до мидла и хочет денег, ему намекают на то, что пора двигаться вперед, но в другой компании. И в этой схеме стажировки и набор студентов очень хорошо укладывается, как правило от них требуется просто знание конкретной функциональности приложения и ее расширение, остальные вопросы решают сеньоры. Студент за год такой работы становится неплохим кодером (кодревью ни кто не отменял), но вот разработчик из него не очень, так как голова часто полна всяческих знаний, но нет навыков их применения, и осознания того, что где и как нужно применять, потому, что применять не дадут. Счастливых людей в этой схеме нет, мидлы все время раздавлены обилием ошибок и указаний на качество кода, сеньоры бегают с горящими глазами и растрепанными шевелюрами подтирая продукты творчества джунов. Довольно только руководство, они покупают полтора мидла по цене одного.
Если бы на схеме API был опубликован для вызова из внешнего источника, то я бы увидел здесь SPA, на в данном случае, пользователь получает сформированные страницы с NodeJs, это не опровергает того факта, что со страницы могут идти REST запросы на NodeJs которые будут делегироваться java серверу. Однако подобный подход мне кажется спорным.
Написав это, я подумал, что возможно у Вас очень большой клиент и Вы не хотите отдавать его весь сразу (много файлов, трафика и все такое) и нашли такой выход из ситуации как сборка налету.
В моей практике клиент собирается/упаковывается во время CI/CD с помощью webpack, формируется набор статических файлов которые помещаются в контейнер с вебсервером и ссылкой на эти файлы. С тем, что Вы сейчас пишите я согласен, но почему на схеме вы указываете взаимодействие NodeJs с Java сервером внутри контейнера или внутри виртуальной сети докера? Я понимаю это так, что кроме сборки клиента пользователю NodeJs принимает REST запросы от клиента и делегирует их выполнение через себя на java сервер.
Также, можно положить все приложения в один образ и развернуть как один контейнер.
Это плохая практика, так делать не надо… Зависнет у Вас клиент на NodeJs, а перезагружать придется и бек тоже, лишние ресурсы на запуск бэка (который не требовалось перезагружать вообще), создание для себя лишних трудностей (и героическое их преодоление) когда возникнет потребность в балансировке нагрузки, из-за жесткой связи — один экземпляр клиента к одному экземпляру сервера.
Я не специалист в NodeJs(вообще), объясните кто ни будь, зачем он в этой схеме, какую задачу он должен решать? Из этой схемы мне на ум приходит:
— Серверный рендеринг страниц
— Раз взаимодействие с бэком на java идет за ним, то это некий Gateway, значит он несет в себе еще и функционал валидации запросов и наверно аутентификацию этих запросов.
Я ни в коем случае не придираюсь, и осознаю, что это просто пример, но это не пример из практики и никто так делать скорее всего не будет (правда ведь не будет?), а значит такую статью сложно осмыслить для практического применения теми людьми для которых эта статья написана.
P.S. Когда люди расширяют знания человечества (наука), они сначала изучают и стараются понять имеющиеся знания, а затем тратят целую жизнь, чтобы открыть что-то новое. Статьи подобные этой прекрасно показывают, что человек не потратил достаточно времени и усилий для изучения и осознания материалов в которых пытается выставить себя авторитетом. Я отношусь к хабру как к серьезному ресурсу с серьезной информацией в котором почему то стали появляться статьи без токового содержания. Вторая причина минусов, это подача материала и «понт», если человек не прав и готов с этим согласиться, его не будут минусовать, он переведет статью в черновик и исправит ошибки, либо удалит.
— «О хабр, я был не прав, помоги мне!»
Но хабр ответит тебе:
— «Нет.»
P.S. Чувак, лучше пиши дальше про скриншотеры…
1. Выбираем любую готовую CMS с большим комьюнити
2. Запрещайте документировать что бы то ни было кроме того, что внесли сами
3. Зовите Гуру
4. Ваш проект должен состоять из одной зоны ответственности в том числе менеджмента. Если компания нанимает «менеджера» значит не доверяет программисту, тут нужно начинать решать проблему с ее корня. Если программист занимается всем, то пусть занимается всем, что касается программирования, по крайней мере он самостоятельно лучше распределит задачи и выставит приоритеты, а если нет то проблема в программисте, значит он не годится для этой работы. Другой вопрос, что такой спец стоит дорого, иногда слишком, но вы ведь зовете Гуру.
5. Если программист сам отчитывается перед бизнесом, то пятый пункт отпадает.
6. Снова недоверие между руководством и исполнителем и неспособность прозрачно отобразить процесс разработки.
Корневая проблема в том, что бизнес видит в программисте источник расходов. Если он будет видеть в нем перспективу и возможность, то все будет иначе. А для этого нужно сделать процесс разработки прозрачным и понятным, нужно снизить риски бизнеса переложив эти риски на программиста, конечно при условии, что это увеличит гонорар в случае успешного достижения результатов (например, пока сайт лежит программист не зарабатывает).
Это плохая практика, так делать не надо… Зависнет у Вас клиент на NodeJs, а перезагружать придется и бек тоже, лишние ресурсы на запуск бэка (который не требовалось перезагружать вообще), создание для себя лишних трудностей (и героическое их преодоление) когда возникнет потребность в балансировке нагрузки, из-за жесткой связи — один экземпляр клиента к одному экземпляру сервера.
Я не специалист в NodeJs(вообще), объясните кто ни будь, зачем он в этой схеме, какую задачу он должен решать? Из этой схемы мне на ум приходит:
— Серверный рендеринг страниц
— Раз взаимодействие с бэком на java идет за ним, то это некий Gateway, значит он несет в себе еще и функционал валидации запросов и наверно аутентификацию этих запросов.
Я ни в коем случае не придираюсь, и осознаю, что это просто пример, но это не пример из практики и никто так делать скорее всего не будет (правда ведь не будет?), а значит такую статью сложно осмыслить для практического применения теми людьми для которых эта статья написана.