Хм.
Непосредственный руководитель (тимлид) не использует никаких кнутов и пряников. Он как старший коллега.
Начальство повыше к нам (разработчикам, с тим-лидом общаются) практически не лезет.
Примерный диалог:
Новичек: Где получать информацию о веб-программировании?
me: Читайте хабр.
Программист: В массе стадо студентов, ламерья. Сейчас из двух десяток заметок — одна стоит внимания. Лучше читать профильные форумы, а хабр в качестве желтой прессы во время кофе с бутербродом.
me: Кстати да. Еще очень самоуверенного.
1. А я и не говорил, что я не могу ошибаться. Перечитайте пункты 2,3, адресованные предыдущему оратору.
2. Люди, которые знают, что делают, конечно же есть. Я этого тоже не отрицал :)
Но не все то золото, что блестит:
Например.
То, что проект большой, не значит, что он умно сделан (тем более во всем). :)
Посмотрите для примера на богомерзкую мордокнигу.
1. Я тоже помню (фрагментарно) :)
2. Не нужно ничего доказывать. Я не стараюсь что-то доказать. Я стараюсь найти аргументацию, что для чего в каких случаях больше подходит, в каких случаях А может быть лучше Б, в каких нет.
В данном случае — в каких случаях и как стоит использовать микросервисы.
3. Если я в чем-то ошибаюсь, приводите аргументы. Но не детский лепет, который разбивается в пух и прах. (Это не только вам адресовано). Если укажете на ошибку, я будут только благодарен.
>Мой личный проект в среднем обрабатывает 10к запросов в секунду, думаю, на этом можно закончить :D
Ну это совсем другой разговор. :)
Мало какие коммерческие имеют такие показатели (а подавляющее большинство и не имеет). Вы могли двигаться в сторону микросервисов, большинство же нет. :)
Но нужно смотреть, что скрывается за этими запросами. :)
Тут https://habrahabr.ru/post/262623/ тоже крутые цифры, а под капотом работа с первичным ключом одной таблицы.
Не надо экстраполировать свою самоуверенность на все отрасли человеческой деятельности.
>Интересно было посмотреть, каких размеров ваши проекты
Вы сначала хотели код.
Так вот, какие оптимизации возможны для медленного DOM я сказал, причем 2 раза.
У Вас еще другие проблемы есть?
>какой сложности UI
1. Сложность UI не стоит связывать с тормозами DOM.
2. Очень сложный.
Каша на jquery местами. :)
Рефакторить никто не спешит, рефакторинг проводится частично только при внесении изменений, но не не глобальный рефакторинг.
Задумываются над редизайном (но мне старшие коллеги (уволившиеся еще до того, как я пришел :) ) говорят, что это уже давно :) ).
В личном проекте каши нет, там и кода мало, и логика не сильно сложная.
А также нету тормозов DOM (это очень редкие проекты их имеют, но мыши побежали топиться в озеро под сладкую музыку, что React.js (любой другой) решит все их проблемы).
>и как вы боретесь со стейтом.
1. Что это такое?
2. Оно вряд ли связано с тормозами DOM? :)
>Нет. В целях обучения мы можем выделять эти сервисы искуственно.
Обучение без необходимости — это дерьмо. Человек ни хрена не поймет.
Знания получил, думать не научился. :)
Прежде всего нужно учить думать.
>Разработчик без личных проектов — тоже самое, что адвокат без судебной практики.
Совсем не то. И это сплошь и рядом.
>У меня например не разбилось, что я делаю не так?
Может это Вам лишь так кажется? :)
>Проектирование это и не задача фреймворков.
Уже нет? Не они задают архитектуру? :)
>Первый раз мы решаем квадратное уравнение до реальной необходимости это сделать
Сравнение некорректное.
Решая квадратное уравнение мы решаем конкретную задачу: найти x.
Здесь же абстрактное обучение в вакууме.
Еще раз:
Есть потребность — делаем, нету — не делаем.
Не нужно искусственно что-то натягивать.
>Да, в таком случае при возникновения этой самой необходимости ты делаешь миллионы ошибок, которые такой же программист УЖЕ преодалел, изучая и практикуясь.
Программист, пишущий на фреймворках? :)
Та они (в основном) и шагу ступить без него не могут.
Я не спорю, что нужна практика. Но эта практика не должна быть надуманной и без понимания. Тогда это не практика. А сферический вакуум.
>Может всетаки дело не в необходимости а отсутствии у кого-то системного подхода к собственному обучению?
1. Я не считаю себя супер-программистом.
2. Необходимости в ООП не было, а я поддался моде. (Ну как вы советуете сейчас идти пилить микросервисы :) )
Если Вы применяли с пониманием (хотя Вы говорите, что без :) ) и оно было необходимо (хотя в случае с микросервисами Вы говорите, что нет), то ок :)
>ФУ, микросервисы мейнстрим, лучше буду дерьмо жрать с кучей инстансов монолитных приложений, зато НИКАК ФСЕ.
Я такого не говорил.
Я всегда говорю: Все нужно использовать по потребности и с умом! А не искать серебрянные пули.
>Назовите хоть одну — уберем.
Вы сами их упомянули:
«Стандарты? Паттерны? Лучшие практики?»
А также: ООП — тру (в последнее время: ФП — тру), фреймворки — тру, goto — зло.
Ну не везде это нужно и оправдано. Тем более без понимания.
>Обратного никто не утверждал.
Как же. Вы же советуете играть с микросервисами без необходимости в них (а значит понимания нету).
>Ну это вообще какой-то вброс дерьма на вентилятор. Стандарты? Паттерны? Лучшие практики? Что объединят три предыдущих вопроса? Это именно то «как делают другие» и разработчику на это не должно быть плевать.
Разработчик, который не умеет думать, а использует готовую догматику, не понимает, что он делает.
На поверхности получаем якобы и стандарты, и паттерны, и практики, только оно такое говнокодное, что капец. Ну или несвязная копипаста из разных мест :)
Это обезьяна, а не разработчик.
Серебрянной пули нету, а вы всем ее суете.
>Для того, что бы у тебя появилось понимание, тебе нужно сначала их как минимум использовать :)
Нет.
Нужно читать стоящие книжки, смотреть примеры, делиться опытом.
Иначе это будет варение в себе.
На поверхности будут вроде и микросервисы, только сторонний наблюдатель подумает: ну нахера это тут?
Если человек применяет подход без понимания, то он обезьяна.
>В это болото можно и нужно лезть и из собственного интереса, но не на деньги работодателя
Я согласен, что заниматься экспериментами на деньги работодателя не стоит.
Я против этого и выступаю, когда крутые перцы говорят: а не переписать ли все на A фреймворк, а не поменять ли нам БД, а не добавить сюда еще эту приблуду.
Хотя необходимости в этом нет, просто им скучно.
Если же есть необходимость, то вряд ли ваш личный проект будет больше требовать разбиения на микросервисы (а они нужны не такому и большому количеству сайтов).
Со стороны пользователя да.
Но при этом мы можем иметь меньше запущенных процессов для обработки того же количества запросов.
А также нету блокировок (если вдруг не наделали их :) )
>Однако требования повышались, исходный код разрастался на глазах, нагрузка возрастала и привычные инструменты перестали справляться.
Повышались не то что требования.
Просто некоторые задачи удобней решать на асинхронном Node.JS.
>И лишь только после этого перейти к обработке следующего запроса.
Вообще-то сервер может более одного запроса в один момент.
У PHP несколько дочерних процессов, которые принимают запросы.
>Тогда это дало бы возможность разрабатывать на одном и том же языке и серверную и клиентскую части сайта.
В этом был главный плюс и причина возникновения Node.JS?
>и запросов таких может одновременно быть пара тысяч
Ну да, ну да.
>Подобные соображения побудили любителей JS к созданию собственных серверных движков.
Вы же сами говорите, что он на V8.
>2 сентября был официально представлен
Какого года?
Напоминает: Украина получит безвиз в октябре (уже 10 лет получает :) ).
>Основными проблемами, которые пришлось решать разработчикам в движке, стали производительность и масштабируемость.
JS однопоточный вообще-то.
То есть запускаем 100500 инстансов. Тут не нужно было думать о масштабируемости.
>Эта модель была выбрана из-за простоты, низких накладных расходов (по сравнению с идеологией «один поток на каждое соединение») и быстродействия.
nginx тоже однопоточный.
PHP тоже однопоточный (если не под многопоточным Апачем модулем).
>в 2010-2015 годах разработчики добавили в хранилище кода более 190 000 модулей для Node.js
Какая-то ерунда непонятная.
Там модуля из 10 строк состоят? Модуль используется только автором?
>Кроме того, она поддерживает 98% стандарта ECMAScript 6.
Как считали проценты? :)
>Однако растут не только номера версий Node.js. По данным Indeed.com, на рынке труда востребованность специалистов по Node.js продолжает расти.
Это какая-то ерунда, а не рисунок.
Node.JS — отдельная технология, а сравнивается с отдельными фреймворками других технологий. :)
А также дальтоникам рисунок непонятен :)
>1. Насколько быстро, по вашему мнению, развивается Node.js? Довольны ли вы текущим темпом?
Блеать, та мне насрать на темпы развития.
Или у него есть то, что мне нужно сейчас, или нет.
Вы ж наклепали 200К модулей, самый быстрый язык, прям ракета.
>Я не заметил какого-то резкого изменения спроса на Node.js разработчиков. Пожалуй, владение Node.js стало обязательным требованием для фронтенд-разработчиков в последнее время.
Шта? Спроса нет, но требования обязательны?
>Node.js — это всего лишь инструмент для выполнения JavaScript сценариев.
Блеать, там не браузерный JS выполняется. Или у него интерес просто JS выполнять?
PHP — это всего лишь инструмент выполнения PHP сценариев :)
>Я считаю Node.js ждет большое будущее. Особенно среди фронтенд-разработчиков.
Рилли? (Относится ко второму предложению).
>Если чистый JavaScript, то очень быстро можно столкнуться с тем, что станет непонятно, что и как в вашей программе связано. Это следствие того, что JS динамический.
Что за ерунда?
PHP тоже динамичный.
>В случае же использования TypeScript, например, у вас будет проверка типов на этапе компиляции
А в рантайме придет не тот тип и здрасте :)
>Тут от задачи зависит. Для микросервисов, на мой взгляд, – самое то.
Микросервис — это проект?
О боже, где вы берете таких экспертов.
>Например, для написания небольших REST-сервисов.
Вообще-то, любой HTTP-сервис — уже REST.
>При большом количестве кода могут быть проблемы с прозрачностью логики работы приложения, но, как я уже говорил, это особенность JavaScript, которая вполне может быть решена с помощью Typescript
Статическая типизация не повышает автоматом качество кода…
>то теперь-то точно в браузере можно будет запускать «байт-код», а это значит – программировать на любом языке.
В браузере? Будем запускать Node.js в браузере? Ооо.
>Node.js откажется от V8 после стабилизации ES6, просто потому, что взаимодействие сервисов имеет несколько иную специфику нежели браузеров.
Тупо бред.
Можно отказаться от ES5 в пользу ES6 после стабилизации последнего
Или от V8 после стабилизации ES6, потому что нам не нужен ES5.
Но при чем тут одновременно V8, ES6 и браузеры?
Вообще-то V8 — быстрая числодробилка. Как браузерный — он не сильно оптимальный.
Но Node.JS и не использует его браузерность.
Масштабировать само приложение не так сложно (в этом не такая большая нужда).
И режут на микросервисы не только из-за масштабируемости, а и:
а) чтобы не было блокировок, когда вместо синхронного выполнения тяжелой операции выполняютт ее в фоне.
б) когда был монолит, но мы захотели предоставлять API доступ к нему: мобильное приложение, сторонние клиенты.
А вот базу сложнее масштабировать.
У кого-то есть данные, сколько занимают главные таблицы пользователей в ВК и ФБ? :)
Основная поболь, кмк, невозможность выполнить запрос над данными более одного сервера.
Хотя тут: https://habrastorage.org/getpro/habr/post_images/a07/038/4e5/a070384e516dd5466ee15fc314b1dc44.png
https://habrahabr.ru/company/oleg-bunin/blog/309330/
как бы есть решение.
А также есть малоизвестный mysql-движок FEDERATED.
Мне интересен такой вопрос:
Как будет работать шардинг с группировками по данным из нескольких шард? :)
Потому что обычные запросы можно выполнить и отдельно на каждом сервер.
Работают ли межсерверные джойны (хотя это ад)?
А также:
Стоит ли делать шардинг по UUID (когда большинство запросов именно по UUID) и кто как его делает.
Есть ли range ранжирование?
Старению подвержены все… :)
Старение не так страшно, когда можешь сам омолаживать по необходимости (самопись).
В случае умирания фреймворка/CMS, выхода новой несовместимой версии поимеем боль :)
Зоопарк сложнее поддерживать.
Сотрудники слабо взаимозаменяемы.
Нужно заранее понимать, нужен ли сервис в данной ситуации или нет.
Иначе это напоминает перебор индекса массива (больше/меньше, строгое/нестрогое неравенство), чтобы программа заработала. :)
Понимания 0.
Мало у кого есть личные проекты (хотя это плюс, а то имеем сапожников без сапог), а тем более требующие микросервисов.
>Практический опыт ДО реальной необходимости
Это типа умение дрочить? :)
В реальности это все разобъется в пух и прах.
В реальности придется думать в каждом конкретном случае, как резать монолит.
Фреймворки за вас это не сделают.
Кмк, вещи нужно использовать по мере необходимости и с пониманием.
У меня тоже был дурной опыт. Например, с ООП. Молодой неокрепший ум (+без опыта коммерческой разработки еще) начитался, что это круто: наследование тебе, инкапсуляция.
Ну и начал натягивать ООП (так был сделан, слава богу, только один подраздел).
На поверхности был как бы ООП. Но это был ад. Я код вообще перестал понимать. :)
Плюнул потом и переписал так, как понимаю.
То есть:
Не нужно пытаться что-то использовать, потому что так все делают. Та плевать, как кто делает.
Не нужно свой код подстраивать под что-то, не понимая этого чего-то.
А также, наверное, не стоит советовать новичкам идти по пути непонимания и наименьшего сопротивления.
Нужно меньше догм.
Но это не значит, что не нужно интересоваться новыми подходами. Нужно. Только применять их с пониманием.
Если Вы этого не поняли:
«Есть куча оптимизаций. Самые простые:
1. Не дергать 100500 раз $('selector').some_operationsN(), а сохранить $('selector') в переменную и работать с ней.
2. Обновлять DOM не кусочками, а допустим сразу аккумулировать в переменную таблицу и вставить ее в DOM.»
Непосредственный руководитель (тимлид) не использует никаких кнутов и пряников. Он как старший коллега.
Начальство повыше к нам (разработчикам, с тим-лидом общаются) практически не лезет.
Новичек: Где получать информацию о веб-программировании?
me: Читайте хабр.
Программист: В массе стадо студентов, ламерья. Сейчас из двух десяток заметок — одна стоит внимания. Лучше читать профильные форумы, а хабр в качестве желтой прессы во время кофе с бутербродом.
me: Кстати да. Еще очень самоуверенного.
2. Люди, которые знают, что делают, конечно же есть. Я этого тоже не отрицал :)
Но не все то золото, что блестит:
Например.
То, что проект большой, не значит, что он умно сделан (тем более во всем). :)
Посмотрите для примера на богомерзкую мордокнигу.
2. Не нужно ничего доказывать. Я не стараюсь что-то доказать. Я стараюсь найти аргументацию, что для чего в каких случаях больше подходит, в каких случаях А может быть лучше Б, в каких нет.
В данном случае — в каких случаях и как стоит использовать микросервисы.
3. Если я в чем-то ошибаюсь, приводите аргументы. Но не детский лепет, который разбивается в пух и прах. (Это не только вам адресовано). Если укажете на ошибку, я будут только благодарен.
>Мой личный проект в среднем обрабатывает 10к запросов в секунду, думаю, на этом можно закончить :D
Ну это совсем другой разговор. :)
Мало какие коммерческие имеют такие показатели (а подавляющее большинство и не имеет). Вы могли двигаться в сторону микросервисов, большинство же нет. :)
Но нужно смотреть, что скрывается за этими запросами. :)
Тут https://habrahabr.ru/post/262623/ тоже крутые цифры, а под капотом работа с первичным ключом одной таблицы.
Не надо экстраполировать свою самоуверенность на все отрасли человеческой деятельности.
Вы сначала хотели код.
Так вот, какие оптимизации возможны для медленного DOM я сказал, причем 2 раза.
У Вас еще другие проблемы есть?
>какой сложности UI
1. Сложность UI не стоит связывать с тормозами DOM.
2. Очень сложный.
Каша на jquery местами. :)
Рефакторить никто не спешит, рефакторинг проводится частично только при внесении изменений, но не не глобальный рефакторинг.
Задумываются над редизайном (но мне старшие коллеги (уволившиеся еще до того, как я пришел :) ) говорят, что это уже давно :) ).
В личном проекте каши нет, там и кода мало, и логика не сильно сложная.
А также нету тормозов DOM (это очень редкие проекты их имеют, но мыши побежали топиться в озеро под сладкую музыку, что React.js (любой другой) решит все их проблемы).
>и как вы боретесь со стейтом.
1. Что это такое?
2. Оно вряд ли связано с тормозами DOM? :)
Обучение без необходимости — это дерьмо. Человек ни хрена не поймет.
Знания получил, думать не научился. :)
Прежде всего нужно учить думать.
>Разработчик без личных проектов — тоже самое, что адвокат без судебной практики.
Совсем не то. И это сплошь и рядом.
>У меня например не разбилось, что я делаю не так?
Может это Вам лишь так кажется? :)
>Проектирование это и не задача фреймворков.
Уже нет? Не они задают архитектуру? :)
>Первый раз мы решаем квадратное уравнение до реальной необходимости это сделать
Сравнение некорректное.
Решая квадратное уравнение мы решаем конкретную задачу: найти x.
Здесь же абстрактное обучение в вакууме.
Еще раз:
Есть потребность — делаем, нету — не делаем.
Не нужно искусственно что-то натягивать.
>Да, в таком случае при возникновения этой самой необходимости ты делаешь миллионы ошибок, которые такой же программист УЖЕ преодалел, изучая и практикуясь.
Программист, пишущий на фреймворках? :)
Та они (в основном) и шагу ступить без него не могут.
Я не спорю, что нужна практика. Но эта практика не должна быть надуманной и без понимания. Тогда это не практика. А сферический вакуум.
>Может всетаки дело не в необходимости а отсутствии у кого-то системного подхода к собственному обучению?
1. Я не считаю себя супер-программистом.
2. Необходимости в ООП не было, а я поддался моде. (Ну как вы советуете сейчас идти пилить микросервисы :) )
Если Вы применяли с пониманием (хотя Вы говорите, что без :) ) и оно было необходимо (хотя в случае с микросервисами Вы говорите, что нет), то ок :)
>ФУ, микросервисы мейнстрим, лучше буду дерьмо жрать с кучей инстансов монолитных приложений, зато НИКАК ФСЕ.
Я такого не говорил.
Я всегда говорю: Все нужно использовать по потребности и с умом! А не искать серебрянные пули.
>Назовите хоть одну — уберем.
Вы сами их упомянули:
«Стандарты? Паттерны? Лучшие практики?»
А также: ООП — тру (в последнее время: ФП — тру), фреймворки — тру, goto — зло.
Ну не везде это нужно и оправдано. Тем более без понимания.
>Обратного никто не утверждал.
Как же. Вы же советуете играть с микросервисами без необходимости в них (а значит понимания нету).
>Ну это вообще какой-то вброс дерьма на вентилятор. Стандарты? Паттерны? Лучшие практики? Что объединят три предыдущих вопроса? Это именно то «как делают другие» и разработчику на это не должно быть плевать.
Разработчик, который не умеет думать, а использует готовую догматику, не понимает, что он делает.
На поверхности получаем якобы и стандарты, и паттерны, и практики, только оно такое говнокодное, что капец. Ну или несвязная копипаста из разных мест :)
Это обезьяна, а не разработчик.
Серебрянной пули нету, а вы всем ее суете.
>Для того, что бы у тебя появилось понимание, тебе нужно сначала их как минимум использовать :)
Нет.
Нужно читать стоящие книжки, смотреть примеры, делиться опытом.
Иначе это будет варение в себе.
На поверхности будут вроде и микросервисы, только сторонний наблюдатель подумает: ну нахера это тут?
Если человек применяет подход без понимания, то он обезьяна.
>В это болото можно и нужно лезть и из собственного интереса, но не на деньги работодателя
Я согласен, что заниматься экспериментами на деньги работодателя не стоит.
Я против этого и выступаю, когда крутые перцы говорят: а не переписать ли все на A фреймворк, а не поменять ли нам БД, а не добавить сюда еще эту приблуду.
Хотя необходимости в этом нет, просто им скучно.
Если же есть необходимость, то вряд ли ваш личный проект будет больше требовать разбиения на микросервисы (а они нужны не такому и большому количеству сайтов).
А тут достаточно подробно.
Вряд ли выйдет в рамках одной статьи объять все моменты (хотя Вы и сами с этим согласны). :)
Не, не слышал.
Сейчас же модно писать на фреймворке и не думать о СУБД. :)
Абстрагироваться, так сказать. :)
Но при этом мы можем иметь меньше запущенных процессов для обработки того же количества запросов.
А также нету блокировок (если вдруг не наделали их :) )
>Однако требования повышались, исходный код разрастался на глазах, нагрузка возрастала и привычные инструменты перестали справляться.
Повышались не то что требования.
Просто некоторые задачи удобней решать на асинхронном Node.JS.
>И лишь только после этого перейти к обработке следующего запроса.
Вообще-то сервер может более одного запроса в один момент.
У PHP несколько дочерних процессов, которые принимают запросы.
>Тогда это дало бы возможность разрабатывать на одном и том же языке и серверную и клиентскую части сайта.
В этом был главный плюс и причина возникновения Node.JS?
>и запросов таких может одновременно быть пара тысяч
Ну да, ну да.
>Подобные соображения побудили любителей JS к созданию собственных серверных движков.
Вы же сами говорите, что он на V8.
>2 сентября был официально представлен
Какого года?
Напоминает: Украина получит безвиз в октябре (уже 10 лет получает :) ).
>Основными проблемами, которые пришлось решать разработчикам в движке, стали производительность и масштабируемость.
JS однопоточный вообще-то.
То есть запускаем 100500 инстансов. Тут не нужно было думать о масштабируемости.
>Эта модель была выбрана из-за простоты, низких накладных расходов (по сравнению с идеологией «один поток на каждое соединение») и быстродействия.
nginx тоже однопоточный.
PHP тоже однопоточный (если не под многопоточным Апачем модулем).
>в 2010-2015 годах разработчики добавили в хранилище кода более 190 000 модулей для Node.js
Какая-то ерунда непонятная.
Там модуля из 10 строк состоят? Модуль используется только автором?
>Кроме того, она поддерживает 98% стандарта ECMAScript 6.
Как считали проценты? :)
>Однако растут не только номера версий Node.js. По данным Indeed.com, на рынке труда востребованность специалистов по Node.js продолжает расти.
Это какая-то ерунда, а не рисунок.
Node.JS — отдельная технология, а сравнивается с отдельными фреймворками других технологий. :)
А также дальтоникам рисунок непонятен :)
>1. Насколько быстро, по вашему мнению, развивается Node.js? Довольны ли вы текущим темпом?
Блеать, та мне насрать на темпы развития.
Или у него есть то, что мне нужно сейчас, или нет.
Вы ж наклепали 200К модулей, самый быстрый язык, прям ракета.
>Я не заметил какого-то резкого изменения спроса на Node.js разработчиков. Пожалуй, владение Node.js стало обязательным требованием для фронтенд-разработчиков в последнее время.
Шта? Спроса нет, но требования обязательны?
>Node.js — это всего лишь инструмент для выполнения JavaScript сценариев.
Блеать, там не браузерный JS выполняется. Или у него интерес просто JS выполнять?
PHP — это всего лишь инструмент выполнения PHP сценариев :)
>Я считаю Node.js ждет большое будущее. Особенно среди фронтенд-разработчиков.
Рилли? (Относится ко второму предложению).
>Если чистый JavaScript, то очень быстро можно столкнуться с тем, что станет непонятно, что и как в вашей программе связано. Это следствие того, что JS динамический.
Что за ерунда?
PHP тоже динамичный.
>В случае же использования TypeScript, например, у вас будет проверка типов на этапе компиляции
А в рантайме придет не тот тип и здрасте :)
>Тут от задачи зависит. Для микросервисов, на мой взгляд, – самое то.
Микросервис — это проект?
О боже, где вы берете таких экспертов.
>Например, для написания небольших REST-сервисов.
Вообще-то, любой HTTP-сервис — уже REST.
>При большом количестве кода могут быть проблемы с прозрачностью логики работы приложения, но, как я уже говорил, это особенность JavaScript, которая вполне может быть решена с помощью Typescript
Статическая типизация не повышает автоматом качество кода…
>то теперь-то точно в браузере можно будет запускать «байт-код», а это значит – программировать на любом языке.
В браузере? Будем запускать Node.js в браузере? Ооо.
>Node.js откажется от V8 после стабилизации ES6, просто потому, что взаимодействие сервисов имеет несколько иную специфику нежели браузеров.
Тупо бред.
Можно отказаться от ES5 в пользу ES6 после стабилизации последнего
Или от V8 после стабилизации ES6, потому что нам не нужен ES5.
Но при чем тут одновременно V8, ES6 и браузеры?
Вообще-то V8 — быстрая числодробилка. Как браузерный — он не сильно оптимальный.
Но Node.JS и не использует его браузерность.
И режут на микросервисы не только из-за масштабируемости, а и:
а) чтобы не было блокировок, когда вместо синхронного выполнения тяжелой операции выполняютт ее в фоне.
б) когда был монолит, но мы захотели предоставлять API доступ к нему: мобильное приложение, сторонние клиенты.
А вот базу сложнее масштабировать.
У кого-то есть данные, сколько занимают главные таблицы пользователей в ВК и ФБ? :)
Основная поболь, кмк, невозможность выполнить запрос над данными более одного сервера.
Хотя тут: https://habrastorage.org/getpro/habr/post_images/a07/038/4e5/a070384e516dd5466ee15fc314b1dc44.png
https://habrahabr.ru/company/oleg-bunin/blog/309330/
как бы есть решение.
А также есть малоизвестный mysql-движок FEDERATED.
Мне интересен такой вопрос:
Как будет работать шардинг с группировками по данным из нескольких шард? :)
Потому что обычные запросы можно выполнить и отдельно на каждом сервер.
Работают ли межсерверные джойны (хотя это ад)?
А также:
Стоит ли делать шардинг по UUID (когда большинство запросов именно по UUID) и кто как его делает.
Есть ли range ранжирование?
Старение не так страшно, когда можешь сам омолаживать по необходимости (самопись).
В случае умирания фреймворка/CMS, выхода новой несовместимой версии поимеем боль :)
Зоопарк сложнее поддерживать.
Сотрудники слабо взаимозаменяемы.
Выгоды от зоопарка больше у крупных компаний.
Иначе это напоминает перебор индекса массива (больше/меньше, строгое/нестрогое неравенство), чтобы программа заработала. :)
Понимания 0.
Мало у кого есть личные проекты (хотя это плюс, а то имеем сапожников без сапог), а тем более требующие микросервисов.
>Практический опыт ДО реальной необходимости
Это типа умение дрочить? :)
В реальности это все разобъется в пух и прах.
В реальности придется думать в каждом конкретном случае, как резать монолит.
Фреймворки за вас это не сделают.
Кмк, вещи нужно использовать по мере необходимости и с пониманием.
У меня тоже был дурной опыт. Например, с ООП. Молодой неокрепший ум (+без опыта коммерческой разработки еще) начитался, что это круто: наследование тебе, инкапсуляция.
Ну и начал натягивать ООП (так был сделан, слава богу, только один подраздел).
На поверхности был как бы ООП. Но это был ад. Я код вообще перестал понимать. :)
Плюнул потом и переписал так, как понимаю.
То есть:
Не нужно пытаться что-то использовать, потому что так все делают. Та плевать, как кто делает.
Не нужно свой код подстраивать под что-то, не понимая этого чего-то.
А также, наверное, не стоит советовать новичкам идти по пути непонимания и наименьшего сопротивления.
Нужно меньше догм.
Но это не значит, что не нужно интересоваться новыми подходами. Нужно. Только применять их с пониманием.
А как сервисам между собой общаться? :)
Часто это сервер очередей или сервис, которы знает, как в кого ходить.
Если же они будут безобразно ходить друг в дружку, то это только увеличение бардака, с которым мы якобы пытались бороться :)
В общем, в неумелых руках любая технология будет порождать проблемы. :)
Если Вы этого не поняли:
«Есть куча оптимизаций. Самые простые:
1. Не дергать 100500 раз $('selector').some_operationsN(), а сохранить $('selector') в переменную и работать с ней.
2. Обновлять DOM не кусочками, а допустим сразу аккумулировать в переменную таблицу и вставить ее в DOM.»
То я Вам ничем больше не помогу.
Шикардос.
Из серии:
Вровень выступать.
7 параллельных взаимоперпендикулярных прямых.