Давайте представим что у вас уже есть ui-система. Она написана например на ангуляре 14 версии. У нас есть компонент написанный с использованием moment.js .
Задача, доработать способы отображения этого календаря а так же провести оптимизацию для скорости. Или даже лучше сделать что-то такое что базовым функционалом moment.js решить очень сложно или же просто не возможно. В идеале еще поднять перфоманс.
Первым делом , мы такие смотрим что классно было бы просто поднять версию ангуляра например до 16, что дало бы ощутимый прирост производительности так как там появились standalone компоненты что позволят нам сократить размер билда и в целом выкинуть модули как таковые.
И вот мы такие радостно запускаем npm update и вуаля нам очень повезло и все обновилось и даже не возникло конфликтов с версиями. Мы радостно запускаем npm run build/npm run start и видим что мы в глубокой Ж....
Так как moment.js стал deprecated мы лезем к ним на сайт а там душераздирающее сообщение, что они слёзно извиняются но проект закрыт. А так же они рекомендуют использовать новый, современный, легкий date-fns.js. Мы такие радостные бежим туда и читаем документацию, в надежде на то что нам просто надо будет поправить импорты и все. Дело сделано.
После прочтения мы начинаем лысеть, так как понимаем что синтаксис другой, название функций другие, способ задание и в целом все другое.
А теперь мы садимся и начинаем считать трудозатраты всего этого упражнения. Вот перечень работ которые нам потребуется проделать:
Удалить везде где в системе использовался moment.js
Поменять все входные параметры которые были завязаны на формат moment.js
Переписать все функции в которых был задействован moment.js включая вспомогательные.
Написать вагон новых тестов для покрытия того что получилось.
Вроде не так сложно да? А теперь давайте представим как вы это будете объяснять бизнесу(продуктам/ проектам) которые используют вашу ui-систему.
Что им придется потратить +100500 человека часов что бы обновиться на новую версию. Так как потребуется перелопачивать все продукты полностью из-за того что плодить зоопарк из зависимостей вам ни кто не даст, а так же не получится остаться на старой версии так как ее поддержка прекратится.
В таком кейсе как вы считаете ui-система хорошо?
По мне так если бы ее не было то каждый продукт мог постепенно переехать на нужную версию когда им было бы удобно. Пришлось бы просто контролировать тех долг и пушить его, что в разы проще.
Сейчас все начнут накидывать что неправильная система и прочее. Но идеала не существует. Пример немного утрирован но мне кажется доходчиво показывает риски связанные с такой махиной как ui-система.
Давайте, тогда, рассмотрим какие-нибудь конкретные задачи. Вот была одна задача, а возникла другая... Чтобы оценить сложность.
Допустим вам потребовалось сделать новый компонент что является задачей на расширение функциональности в которую входит дизайн, описание и разработка. Но в процессе выясняется что требуется для реализации требуется обновить зависимости своей ui-системы. И как следствие и всех продуктов/ проектов которые используют ее. Вроде обычная рядовая задача по расширению превращается в апдейт. Это как пример, наглядно показывает что простая задача которая на одном продукте бы заняла условно неделю превращается в месяц а то и два с перетряхиванием всех потребителей.
Наверное, то, что Вы сказали, суть одна из причин того, что описанное мною до сих пор не сделано. Я подчеркнул в Вашем высказывании ключевое слово "монстр". В действительности, декомпозиция задачи построения сложной системы посредством использования различных языков, суть разделение на относительно простые подзадачи и должно приводить к ускорению разработки.
В данном случаи я думаю проблема не в столько в декомпазиции, сколько в том что постоянно меняется задача и оценки. А это значит что не возможно спрогнозировать когда это действительно будет приносить прибыль. Тут же все-таки про бизнес. А в бизнесе если нет сроков то нельзя этим управлять.
Проблема в том что не существует универсального способа. Так как постройка такого монстра очень трудозатратное мероприятие и оно зависит от множества фактов:
Какой калификации сотрудники
На сколько их знания в этой области глубоки и есть ли опыт
Есть ли финансирование данной активности и одобрение руководства так как я знаю случаи когда такое старались провернуть в тихоря.
На сколько большая компания
Как быстро нужен результат
На сколько большое легаси в которое надо будет вживлять данную систему
И это далеко не весь список вопросов, ответы на которые повлияют на выбор сценария реализации проекта или же вообще прекращения активности в этом направлении
Сказанное Вами совершенно справедливо. Как только мы что-то выбираем, мы становимся заложниками того, чем пользуемся. Но! Какой из этого вывод? А то, что нужен какой-то специализированный язык для создания таких систем ("движок") и набор трансляторов на различные платформы и стеки.
Вывод немного другой. Я сообщил о риске который надо учитывать и построении планов на будущее. Просто если компания не определилась со стеком, то строить систему до решения этого вопроса просто глупо. А что касается чего-то нативного или абстрактного, то нативное будет работать медленнее компонента который сделан на конкретном стеке, а абстрактного то тут вляпываешься в поддержку, читабельность и прочее.
Строго говоря, здесь нужно три языка:
Язык, на котором создаётся сама дизайн-система.
Язык, на котором описываются пользовательские интерфейсы. Дизайн-система имеет дело с проектами на таком языке.
Язык конечной реализации, на который транслируются описания на языке №2.
Паразительно то, что всё это давно и хорошо известно в Computer Science. Существует понятие T-диаграммы, имеется метод раскрутки компиляторов и т.д. и т.п.
Мне кажется отчасти вы правы, но я не встречал ни одного годного решения которое просто в обращении или хотя бы понятно в использовании. Самое главное я не встречал готовых решение который выдавали бы хоть какой-то приемлемый результат пусть и с плясками. Если знаете с радостью готов выслушать.
проблема размеренного подхода в том что как правила у каждой команды свои релизные циклы и как правило жёсткие. И очень трудно будет заставить команду у которой в KPI стоит вовремя сдать очередной релиз. Так как на это просто может не хватать времени да и думать о том что и как будут использовать другие просто не смогут так как не вкурсе деталей. Предположим начали делать шажками, но систему не только надо создать но и поддерживать, через 2 года вы попадете в точку в которой надо будет ее переписывать.
Эх. сочувствую вашему травмирующему опыту в 90. Сейчас немного подругому. это все равно что говорить что у всех инструментов у которых есть струны это гитары... Но мы то свами знаем что это не так.
1) CDN - это всего лишь способ быстрого доставки нужной (статической информации) до клиента. Например туже цель преследует HTTP2 что тоже ускорит работу... архитектурный паттерн не важны технологии, не мне вам опьянять . важен подход. Например как гексагональная архитектура, без разницы на чем она одна, так и тут.
Так как большинство манипуляций происходит фронт разработчиками которые пишут на js то и в основе аббревиатуры ( надеюсь вы читали) заложен этот смысл. Рекомендую почитать про SSG ( ссылку я уже довал)
Access ( у вас был на локальной машине) вы могли попросить совместно что-то править? вы могли на нем реализовать REST. Вангую что нет. Вот вам и ответ. Headless CMS - это новый уровень классической CMS которые реализуют паттерн микросервестной архитектуры ( надеюсь вам не надо рассказывать что это такое) По этому Access - рядом не стоит .
что касается github - вы упускаете маленький нюанс, и это как в анекдоте про нюансы ( надеюсь знаете). Нам надо не только сгенерировать страницы но и выгрузить на хостинг(CDN) для понимания рекомендую ознакомиться как работает netlife
Где мои слова расходиться с тем что написана на оф сайте?
Еще раз / работает и на локальной машине. просто при генерации чаще всего получается вот так /index.html.
Локально менять не надо, вы задали вопрос о том что как будет реагировать браузер на локальные файлы. я вам ответил точно так же как и на обычном хостинге. Далее вы сказали что безопасность и прочее. Я вам ответил что если у вас что-то тянуться с вашего хостинга или допустим вы локально хотите закинуть отзыв на товар в Headless CMS ( положить в БД) которая у вас развернута где-то на стороне. И только тогда могут быть проблемы с CORS о которых вы сказали и тогда что бы избежать боли надо немного поменять настройки.
Т.е. каждая страница, как бы глубоко она ни была, зачем-то при ссылках использует ..?
Все страницы сразу сгенерированы и в виде файлов лежат на хосте. Все пути захардкожены .
Что насчет CORS это настройки и они легко меняются. А исполнение JS не мешает вы же подключали хоть раз jquery c помощью CDN. У вас на это ругалась система?
Нет веб -сервера, то есть не происходит исполнения. вы просто можете у себя на пк открыть .html файл и гулять по всему сайту как вам вздумается и тестировать весь функционал, без поднимания какого-то денвера или опен сервера.
В конце 90 вы делали его как?? Руками создавали дубли?? Хардкодили меняющийся текст? Jamstack автоматически генерирует страницы согласно шаблону, и без участия бэка ( точнее представления его в классическом виде? . Так же хотел бы спросить а какие вы технологии использовали в 90 - php или java?
если вы обратили внимание то сервис имеет пунктирную линию. и это использование либо для интерактива, как пример написание отзыва или оплата товара( эти действия же должны как-то попасть в бд) либо для генерации статики.
это как посмотреть, можно сделать. Но тут вопрос трудозатрат, а так же какое количество плагинов(сторонних библиотек) надо будит подключить. И опять же e-commerce бывают разные.
Апи нужно для того что бы сгенерировать статичную страницу. То есть при генерации статической страницы, у нас есть сама разметка и динамическая часть. Как пример статья, разметка одна и таже, но вот сам текст другой. Апи как раз нам позволяет вытянуть из базы (или другого истоячника ) нужную информации и сгенерировать статическую информацию.
Ок, понял.
Давайте представим что у вас уже есть ui-система. Она написана например на ангуляре 14 версии. У нас есть компонент написанный с использованием moment.js .
Задача, доработать способы отображения этого календаря а так же провести оптимизацию для скорости. Или даже лучше сделать что-то такое что базовым функционалом moment.js решить очень сложно или же просто не возможно. В идеале еще поднять перфоманс.
Первым делом , мы такие смотрим что классно было бы просто поднять версию ангуляра например до 16, что дало бы ощутимый прирост производительности так как там появились
standaloneкомпоненты что позволят нам сократить размер билда и в целом выкинуть модули как таковые.И вот мы такие радостно запускаем
npm updateи вуаля нам очень повезло и все обновилось и даже не возникло конфликтов с версиями. Мы радостно запускаемnpm run build/npm run startи видим что мы в глубокой Ж....Так как
moment.jsстал deprecated мы лезем к ним на сайт а там душераздирающее сообщение, что они слёзно извиняются но проект закрыт. А так же они рекомендуют использовать новый, современный, легкийdate-fns.js. Мы такие радостные бежим туда и читаем документацию, в надежде на то что нам просто надо будет поправить импорты и все. Дело сделано.После прочтения мы начинаем лысеть, так как понимаем что синтаксис другой, название функций другие, способ задание и в целом все другое.
А теперь мы садимся и начинаем считать трудозатраты всего этого упражнения. Вот перечень работ которые нам потребуется проделать:
Удалить везде где в системе использовался
moment.jsПоменять все входные параметры которые были завязаны на формат
moment.jsПереписать все функции в которых был задействован
moment.jsвключая вспомогательные.Написать вагон новых тестов для покрытия того что получилось.
Вроде не так сложно да? А теперь давайте представим как вы это будете объяснять бизнесу(продуктам/ проектам) которые используют вашу ui-систему.
Что им придется потратить +100500 человека часов что бы обновиться на новую версию. Так как потребуется перелопачивать все продукты полностью из-за того что плодить зоопарк из зависимостей вам ни кто не даст, а так же не получится остаться на старой версии так как ее поддержка прекратится.
В таком кейсе как вы считаете ui-система хорошо?
По мне так если бы ее не было то каждый продукт мог постепенно переехать на нужную версию когда им было бы удобно. Пришлось бы просто контролировать тех долг и пушить его, что в разы проще.
Сейчас все начнут накидывать что неправильная система и прочее. Но идеала не существует. Пример немного утрирован но мне кажется доходчиво показывает риски связанные с такой махиной как ui-система.
опечатка, спасибо поправлено
Допустим вам потребовалось сделать новый компонент что является задачей на расширение функциональности в которую входит дизайн, описание и разработка. Но в процессе выясняется что требуется для реализации требуется обновить зависимости своей ui-системы. И как следствие и всех продуктов/ проектов которые используют ее. Вроде обычная рядовая задача по расширению превращается в апдейт. Это как пример, наглядно показывает что простая задача которая на одном продукте бы заняла условно неделю превращается в месяц а то и два с перетряхиванием всех потребителей.
Такой пример подойдет?
В данном случаи я думаю проблема не в столько в декомпазиции, сколько в том что постоянно меняется задача и оценки. А это значит что не возможно спрогнозировать когда это действительно будет приносить прибыль. Тут же все-таки про бизнес. А в бизнесе если нет сроков то нельзя этим управлять.
Проблема в том что не существует универсального способа. Так как постройка такого монстра очень трудозатратное мероприятие и оно зависит от множества фактов:
Какой калификации сотрудники
На сколько их знания в этой области глубоки и есть ли опыт
Есть ли финансирование данной активности и одобрение руководства так как я знаю случаи когда такое старались провернуть в тихоря.
На сколько большая компания
Как быстро нужен результат
На сколько большое легаси в которое надо будет вживлять данную систему
И это далеко не весь список вопросов, ответы на которые повлияют на выбор сценария реализации проекта или же вообще прекращения активности в этом направлении
Вывод немного другой. Я сообщил о риске который надо учитывать и построении планов на будущее. Просто если компания не определилась со стеком, то строить систему до решения этого вопроса просто глупо. А что касается чего-то нативного или абстрактного, то нативное будет работать медленнее компонента который сделан на конкретном стеке, а абстрактного то тут вляпываешься в поддержку, читабельность и прочее.
Мне кажется отчасти вы правы, но я не встречал ни одного годного решения которое просто в обращении или хотя бы понятно в использовании. Самое главное я не встречал готовых решение который выдавали бы хоть какой-то приемлемый результат пусть и с плясками. Если знаете с радостью готов выслушать.
проблема размеренного подхода в том что как правила у каждой команды свои релизные циклы и как правило жёсткие. И очень трудно будет заставить команду у которой в KPI стоит вовремя сдать очередной релиз. Так как на это просто может не хватать времени да и думать о том что и как будут использовать другие просто не смогут так как не вкурсе деталей. Предположим начали делать шажками, но систему не только надо создать но и поддерживать, через 2 года вы попадете в точку в которой надо будет ее переписывать.
Эх. сочувствую вашему травмирующему опыту в 90. Сейчас немного подругому. это все равно что говорить что у всех инструментов у которых есть струны это гитары... Но мы то свами знаем что это не так.
1) CDN - это всего лишь способ быстрого доставки нужной (статической информации) до клиента. Например туже цель преследует HTTP2 что тоже ускорит работу... архитектурный паттерн не важны технологии, не мне вам опьянять . важен подход. Например как гексагональная архитектура, без разницы на чем она одна, так и тут.
Так как большинство манипуляций происходит фронт разработчиками которые пишут на js то и в основе аббревиатуры ( надеюсь вы читали) заложен этот смысл. Рекомендую почитать про SSG ( ссылку я уже довал)
Access ( у вас был на локальной машине) вы могли попросить совместно что-то править? вы могли на нем реализовать REST. Вангую что нет. Вот вам и ответ. Headless CMS - это новый уровень классической CMS которые реализуют паттерн микросервестной архитектуры ( надеюсь вам не надо рассказывать что это такое) По этому Access - рядом не стоит .
что касается github - вы упускаете маленький нюанс, и это как в анекдоте про нюансы ( надеюсь знаете). Нам надо не только сгенерировать страницы но и выгрузить на хостинг(CDN) для понимания рекомендую ознакомиться как работает netlife
Где мои слова расходиться с тем что написана на оф сайте?
То есть если нет CDN, то уже не Jamstack? просто - так работает быстрее
То есть если генератор написан на Go, то это уже не Jamstack? - Jamstack. Но вы говорите только про SSG который может быть написан на чем угодно
Я настоятельно вам рекомендую посетить официальны сайт после посещения которого у вас снимутся множество вопросов.
это архитектурный паттерн, который использует CDN, Headless CMS и SSG ? При этом все манипуляции происходят на JS. На локальной машине или в GIthub.
Еще раз / работает и на локальной машине. просто при генерации чаще всего получается вот так /index.html.
Локально менять не надо, вы задали вопрос о том что как будет реагировать браузер на локальные файлы. я вам ответил точно так же как и на обычном хостинге. Далее вы сказали что безопасность и прочее. Я вам ответил что если у вас что-то тянуться с вашего хостинга или допустим вы локально хотите закинуть отзыв на товар в Headless CMS ( положить в БД) которая у вас развернута где-то на стороне. И только тогда могут быть проблемы с CORS о которых вы сказали и тогда что бы избежать боли надо немного поменять настройки.
Надеюсь теперь я объяснил понятно
Захардкожены - относительно корня, хотя вы можете изменить эту настройку и они у вас будут валяться на одном уровне
Настройки хостинга, Браузера. если конечно в гугле не заблочены.
Попробуйте подключить в локальных файлах, при наличии интернета поведение не измениться.
Т.е. каждая страница, как бы глубоко она ни была, зачем-то при ссылках использует ..?
Все страницы сразу сгенерированы и в виде файлов лежат на хосте. Все пути захардкожены .
Что насчет CORS это настройки и они легко меняются. А исполнение JS не мешает вы же подключали хоть раз jquery c помощью CDN. У вас на это ругалась система?
если у вас все правильно сделано то у вас не будет такого пути
Нет веб -сервера, то есть не происходит исполнения. вы просто можете у себя на пк открыть .html файл и гулять по всему сайту как вам вздумается и тестировать весь функционал, без поднимания какого-то денвера или опен сервера.
В конце 90 вы делали его как?? Руками создавали дубли?? Хардкодили меняющийся текст? Jamstack автоматически генерирует страницы согласно шаблону, и без участия бэка ( точнее представления его в классическом виде? . Так же хотел бы спросить а какие вы технологии использовали в 90 - php или java?
то есть опционально, и в очень урезанном виде по сравнению с классической схемой.
если вы обратили внимание то сервис имеет пунктирную линию. и это использование либо для интерактива, как пример написание отзыва или оплата товара( эти действия же должны как-то попасть в бд) либо для генерации статики.
это как посмотреть, можно сделать. Но тут вопрос трудозатрат, а так же какое количество плагинов(сторонних библиотек) надо будит подключить. И опять же e-commerce бывают разные.
Апи нужно для того что бы сгенерировать статичную страницу. То есть при генерации статической страницы, у нас есть сама разметка и динамическая часть. Как пример статья, разметка одна и таже, но вот сам текст другой. Апи как раз нам позволяет вытянуть из базы (или другого истоячника ) нужную информации и сгенерировать статическую информацию.
как минимум скорости написания кода, разве нет? Качество кода...