Immutable действительно пишется дольше, чем {}, однако прелесть его состоит в разнообразии методов для обработки данных. Благодаря функциональной парадигме и продуманности API можно писать очень удобочитаемый код без привлечения сторонних библиотек. А ведь код читают намного чаще, чем пишут.
А можете пояснить, про какой API из ImmutableJs Вы говорите?
В моем представлении, весь необходимый функционал уже есть в ES2015: спреды, мапы, редьюсеры, фильтры…
Дальше просто берем за правило, что никогда не изменяем объекты, который положили в стор и дело с концом. И никаких дополнительных библиотек не нужно для этого.
В противоположность к Java, Kotlin преподносит совершенно другой стиль конкурентного программирования, не блокирующий по своей природе, который не заставляет нас запускать огромное количество нативных потоков.
Справедливости ради, в Java есть множество средств, чтобы обеспечить неблокирующую многопоточность: Atomic, Nio2, Concurrent collections. Даже BlockedQueue предоставляет неблокирующий потокобезопасный API, который позволяет без особого труда сделать коммуникацию на сообщениях между потоками (Channels?).
Для меня остается секретом, почему в каждой подобной статье автора скрывают, что в Java это все есть и это все довольно просто использовать. Умышленно или по не знанию?
D — не являюсь специалистом по javascript и front-end-у, но dependency injection...
Классическая ошибка.
D из SOLID – это Dependency Inversion, а не Dependency Injection.
Dependency Injection говорит, что должен существовать некий DI контейнер, в который будет производить инстанциирование объектов и внедрение зависимостей (это уже развитие идеи и конкретная имплементация принципа D из SOLID).
Dependency Inversion гласит лишь о том, что зависимость будет передана из вне. Точка.
Это может быть передача параметром в конструктор / сеттер, а может быть билдер, а может быть фабрика, это может быть DI контейнер, ну или на крайний случай ServiceLocator.
Применимо к статье: Создается компонент и ему через проперти передается конкретная реализация (инстанс) компонента, который должен будет отобразиться; или функция отрисовки компонента (provider).
Автор в целом пишет правильные вещи, но местами могут быть проблемы с терминологией, – это нормально. Тут главное не терминология, а сама идея.
То как будет отображаться меню – это UX, который выстраивается из требований бизнеса (т.е. своего рода бизнес-логика для отображения).
Вы же не делаете менюшки такими как вам захочется и не лепите их куда вам захочется?
А компоненты и правда делятся на: компоненты общего назначения (их можно переиспользовать) и компоненты, которые выполняют конкретную поставленную задачу (бизнес требование).
Это иногда бывает неудобно для SPA. Отправили запрос, но тут пользователь перешел на другой экран и ответ от предыдущего запроса нас уже не интересует. Но ответ все равно придет и выполнится какой-то обработчик.
Да и вообще говоря, если вас волнует настолько поведение под капотом, которое не меняет api то вы явно как-то зря волнуетесь.
Ох, значит, вы явно не сталкивались с ситуациями, когда несколько модулей начинают работать под капотом немного иначе и это приводит к неожиданным последствиям. Даже в случае, когда API не поменялось.
А если имплементация несовместима с предыдущей, то это проблемно уже для человека, который фигово меняет настолько имплементацию.
Facebook в их рядах. И это уже Ваша проблема, а не проблема вендора, т.к. Ваш продукт сломался из-за обновления версии.
эта запись означает что данный модуль будет обновляться при выходе минорных релизов, т.е. 4.15.4 -> 4.50.1 без проблем будет обновлен.
А учитывая тот факт, что минорные релизы позволяют менять поведение под капотом без изменения API это дает возможность привнести в свой проект совершенно новую имплементацию, которая будет не совместима.
Более того, в новых версиях просто могут быть баги.
Итого, выполнив npm i ваш проект с хорошей долей вероятности может превратиться в тыкву после пары месяцев разработки: обновится десяток модулей до новых минорных версий и потом разруливай, что как и почему.
Обычно это всплывает у новоприбывших на проект, т.к. у них еще нету установленных модулей и модули будут выкачиваться заново.
Мне за 5+ лет работы с Java, так и не удалось ни разу наступить на проблемы с многопоточностью.
Один раз нашел багу, но эта бага была из-за того, что кто-то захотел распараллелить обработку HTTP запроса. Но это человек умышленно решил выстрелить себе в ногу.
Да, с видимостью проблем нету в ноде, а с дедлоком в целом можно устроить, если запускать форки.
А вот на NodeJs совсем недавно я лечил багу связанную с лайвлоком, Jest + setTimeout не подружились и приложение зависло на CI сервере, учитывая, что на локальной машине оно отрабатывало отлично.
Так что, выстрелить себе в ногу можно на любой платформе, было бы желание, везение и/или предрасположенность.
Интересный подход с внедрением Акторов в NodeJS, в целом это выносит кластеризацию ноды в абстракцию фреймворка. Теперь не нужно будет пилить свою инфраструктуру на ноде. Это очень хорошо!
Но почему такое название? Оно крайне слабо коррелирует с системой акторов.
С одной стороны, это хорошо, поскольку избавляет нас от целого класса очень стрёмных и трудновоспроизводимых багов — многопоточных багов. В наших приложениях таких багов быть принципиально не может, и это сильно удешевляет и ускоряет разработку.
Это классическое заблуждение. Переход от многопоточной системы к однопоточному event-loop не решает проблем, а лишь переводит их в другую плоскость.
Вместо паттернов многопоточности теперь нужны паттерны для event-based подхода. Вместо гонки потоков, теперь есть гонка промисов/ивентов/воркеров, которые все так же нужно синхронизировать.
Это не ускоряет и тем более не удешевляет скорость разработки.
Удешевляет старт возможность начать с низкоквалифицированными программистами, не вникая в сложности HTTP/REST. А мидлвари не все принадлежат вашей инфраструктуре. Ну и потом да, нанимать квалифицированных программистов, которые из ваших мидлварей сделают всё то, что уже спроектировано в HTTP.
Дешевые низклквалифицированные специалисты – это очень дорого.
А найм высококвалифицированных, которые потом перепишут все заново – это еще дороже.
Допустим у вас есть ендпоинты /users и /posts, возврающие списки юзеров со списком айдишников постов и список постов с айдишниками авторов(юзеров). Фронт работает по схеме типа: берем список постов с сервера, из них выгребаем айдишник автора, и берем по нему ФИО автора с сервера. 10 постов показать надо — делаем 11 запросов.
Лично я бы почитал требования по проекту, и сделал бы эндпоинт /feed, который будет возвращать посты постранично со всеми необходимыми данными для отображения.
В крайнем случае, я бы сделал batch эндпоинты для получения данных:
/user/list?ids=1,2,3
/post/list?ids=1,2,3
в этом случае запросов будет всего 2.
Спецы по UX и фронтендеры посовещались и пришли к вам просить сделать новый ендпоинт /posts-with-authors. Знакомо?
К счастью в команде, где люди хоть чуть-чуть понимают что делают, такое бывает крайне редко.
В случае GraphQL они к вам не пойдут, а сразу сделают
В случае с GraphQL у них будут все те же /users и /posts, которые они смогут запрашивать через GraphQL. Ни один вменяемый бекенд девелопер и тем более архитектор (или тех.лид) не позволит сделать схему, в которой будут все возможные данные. Потому что эта херь сразу завалится при более-менее нормальной нагрузке.
В этом случае будет создан другой эндпоинт, который будет отдавать френдов с их постами, который будет более логичным. Не так ли?
А GraphQL это технология, которая упрощает взаимодействие со сторонними клиентами, про которых мы ничего не знаем и которых мы не можем контролировать. Как у FB или у GitHub.
Если API слой не предназначен быть общедоступным, то и GraphQL для него будет избыточным.
Если про саму СУБД, то в случае HTTP/WEB API, это будет практически всегда один запрос к базе, он будет спроектирован так, чтобы из СУБД не вытаскивать ничего лишнего и чтобы вся агрегация выполнялась на стороне СУБД.
В случае с GraphQL, нужно будет поддерживать полное множество всех вариаций запросов, чем больше модель данных – тем сложнее логика для этого будет.
Ну, в целом, если плевать на то, как быстро будет работать сервер, и если идти по пути «плевать, докупим еще серверов» – да, это отличная технология. Разработка будет быстрой, проекты будут сдаваться быстро и в срок и все будет круто! =)
GraphQL не подразумевает сложных запросов. Он подразумевает язык общения между клиентом и сервером.
Таки это и подразумевает.
Вы пишите запрос к серверу «дай мне кучу данные вот таких и таких с такими фильтрами», и сервер начинает тужится выгребать и фильтровать их.
Сортировка и Группировка в GraphQL есть? – еще лучше, прям раздолье для повышенной нагрузки на сервер!
Вы описываете список данных, которых нету в схеме, и тут что-то должно произойти: тихо ничего не вернуть? или выдать какую-то ошибку, что таких полей нету?
Как минимум две:
1. Длина URI. Часто длина URL должна быть ограничена, я бы даже сказал, что это правило хорошего тона.
2. GET запрос с длинным query будет плохо кешироваться транслирующими узлами.
Веб это не только Клиент + Сервер, это еще десятки транслирующих и часто по совместительству кеширующих узлов.
просто работа с базой. в /products?include=comments у вас как-то по другому будет или что?
Да, будет по-другому.
Во-первых, не будет необходимости парсить GraphQL и писать свой «Query-engine» для доступа к данным.
Во-вторых, URI остается чистым и красивым (не будет проблем, описанных выше).
Вы можете считать, что это все надуманные проблемы. Но с другой стороны, GraphQL решает все те же надуманные проблемы типа «сложно расширить модель» или «слишком много данных передается в запросе» ;-)
А можете пояснить, про какой API из ImmutableJs Вы говорите?
В моем представлении, весь необходимый функционал уже есть в ES2015: спреды, мапы, редьюсеры, фильтры…
Дальше просто берем за правило, что никогда не изменяем объекты, который положили в стор и дело с концом. И никаких дополнительных библиотек не нужно для этого.
Для меня остается секретом, почему в каждой подобной статье автора скрывают, что в Java это все есть и это все довольно просто использовать. Умышленно или по не знанию?
D из SOLID – это Dependency Inversion, а не Dependency Injection.
Dependency Injection говорит, что должен существовать некий DI контейнер, в который будет производить инстанциирование объектов и внедрение зависимостей (это уже развитие идеи и конкретная имплементация принципа D из SOLID).
Dependency Inversion гласит лишь о том, что зависимость будет передана из вне. Точка.
Это может быть передача параметром в конструктор / сеттер, а может быть билдер, а может быть фабрика, это может быть DI контейнер, ну или на крайний случай ServiceLocator.
Применимо к статье: Создается компонент и ему через проперти передается конкретная реализация (инстанс) компонента, который должен будет отобразиться; или функция отрисовки компонента (provider).
Автор в целом пишет правильные вещи, но местами могут быть проблемы с терминологией, – это нормально. Тут главное не терминология, а сама идея.
То как будет отображаться меню – это UX, который выстраивается из требований бизнеса (т.е. своего рода бизнес-логика для отображения).
Вы же не делаете менюшки такими как вам захочется и не лепите их куда вам захочется?
А компоненты и правда делятся на: компоненты общего назначения (их можно переиспользовать) и компоненты, которые выполняют конкретную поставленную задачу (бизнес требование).
Это иногда бывает неудобно для SPA. Отправили запрос, но тут пользователь перешел на другой экран и ответ от предыдущего запроса нас уже не интересует. Но ответ все равно придет и выполнится какой-то обработчик.
Вы в него не верите, а мы докажем, что он умеет, что он лучше, что он круче!
Facebook в их рядах. И это уже Ваша проблема, а не проблема вендора, т.к. Ваш продукт сломался из-за обновления версии.
npm install expresshttps://www.npmjs.com/package/expressмодуль будет добавлен в депенденси со следующим синтаксисом:
"express": "^4.15.4"Смотрим документацию:
https://docs.npmjs.com/getting-started/semantic-versioning
эта запись означает что данный модуль будет обновляться при выходе минорных релизов, т.е. 4.15.4 -> 4.50.1 без проблем будет обновлен.
А учитывая тот факт, что минорные релизы позволяют менять поведение под капотом без изменения API это дает возможность привнести в свой проект совершенно новую имплементацию, которая будет не совместима.
Более того, в новых версиях просто могут быть баги.
Итого, выполнив npm i ваш проект с хорошей долей вероятности может превратиться в тыкву после пары месяцев разработки: обновится десяток модулей до новых минорных версий и потом разруливай, что как и почему.
Обычно это всплывает у новоприбывших на проект, т.к. у них еще нету установленных модулей и модули будут выкачиваться заново.
Один раз нашел багу, но эта бага была из-за того, что кто-то захотел распараллелить обработку HTTP запроса. Но это человек умышленно решил выстрелить себе в ногу.
Да, с видимостью проблем нету в ноде, а с дедлоком в целом можно устроить, если запускать форки.
А вот на NodeJs совсем недавно я лечил багу связанную с лайвлоком, Jest + setTimeout не подружились и приложение зависло на CI сервере, учитывая, что на локальной машине оно отрабатывало отлично.
Так что, выстрелить себе в ногу можно на любой платформе, было бы желание, везение и/или предрасположенность.
Но почему такое название? Оно крайне слабо коррелирует с системой акторов.
Это классическое заблуждение. Переход от многопоточной системы к однопоточному event-loop не решает проблем, а лишь переводит их в другую плоскость.
Вместо паттернов многопоточности теперь нужны паттерны для event-based подхода. Вместо гонки потоков, теперь есть гонка промисов/ивентов/воркеров, которые все так же нужно синхронизировать.
Это не ускоряет и тем более не удешевляет скорость разработки.
Дешевые низклквалифицированные специалисты – это очень дорого.
А найм высококвалифицированных, которые потом перепишут все заново – это еще дороже.
Такое себе удешевление получается =)
Лично я бы почитал требования по проекту, и сделал бы эндпоинт /feed, который будет возвращать посты постранично со всеми необходимыми данными для отображения.
В крайнем случае, я бы сделал batch эндпоинты для получения данных:
/user/list?ids=1,2,3
/post/list?ids=1,2,3
в этом случае запросов будет всего 2.
К счастью в команде, где люди хоть чуть-чуть понимают что делают, такое бывает крайне редко.
В случае с GraphQL у них будут все те же /users и /posts, которые они смогут запрашивать через GraphQL. Ни один вменяемый бекенд девелопер и тем более архитектор (или тех.лид) не позволит сделать схему, в которой будут все возможные данные. Потому что эта херь сразу завалится при более-менее нормальной нагрузке.
А GraphQL это технология, которая упрощает взаимодействие со сторонними клиентами, про которых мы ничего не знаем и которых мы не можем контролировать. Как у FB или у GitHub.
Если API слой не предназначен быть общедоступным, то и GraphQL для него будет избыточным.
т.е. бекенд реализовывает некую схему, а дальше через GraphQL из этой схемы выбирается только то, что необходимо фронтенду.
соответственно, если API изначально но поддерживает выборку постов для запроса на френдов, то и в выдаче их не будет.
В случае с GraphQL, нужно будет поддерживать полное множество всех вариаций запросов, чем больше модель данных – тем сложнее логика для этого будет.
Ну, в целом, если плевать на то, как быстро будет работать сервер, и если идти по пути «плевать, докупим еще серверов» – да, это отличная технология. Разработка будет быстрой, проекты будут сдаваться быстро и в срок и все будет круто! =)
Вы пишите запрос к серверу «дай мне кучу данные вот таких и таких с такими фильтрами», и сервер начинает тужится выгребать и фильтровать их.
Сортировка и Группировка в GraphQL есть? – еще лучше, прям раздолье для повышенной нагрузки на сервер!
Вы описываете список данных, которых нету в схеме, и тут что-то должно произойти: тихо ничего не вернуть? или выдать какую-то ошибку, что таких полей нету?
Как минимум две:
1. Длина URI. Часто длина URL должна быть ограничена, я бы даже сказал, что это правило хорошего тона.
2. GET запрос с длинным query будет плохо кешироваться транслирующими узлами.
Веб это не только Клиент + Сервер, это еще десятки транслирующих и часто по совместительству кеширующих узлов.
Да, будет по-другому.
Во-первых, не будет необходимости парсить GraphQL и писать свой «Query-engine» для доступа к данным.
Во-вторых, URI остается чистым и красивым (не будет проблем, описанных выше).
Вы можете считать, что это все надуманные проблемы. Но с другой стороны, GraphQL решает все те же надуманные проблемы типа «сложно расширить модель» или «слишком много данных передается в запросе» ;-)