Angular — не имеет отношения к бэкенду, что не является ни достоинством, ни недостатком. С одной стороны — это дает гибкость в выборе бэкенда, с другой — он конечно не может всего того, что могут full-stack фреймворки. Но так как бэкенд для него всё-таки нужен, то я позволил взять на себя смелость и выбрать в качестве оного express.js, чтобы как-то сделать angular немного похожим на full-stack для этого сравнения. Вы можете сказать, что не самый лучший вариант бэкенда для angular. Тогда предложите другой вариант.
Я абсолютно понимаю, что это решения разных уровней. И то, что любой mvc-на клиенте фреймворк (Angular, Ember, Backbone) будет выглядеть хуже, чем full-stack, дак это тоже понятно. Но люди спрашивали.
А что вы подразумеваете под «вкусом разработчика и необходимой ему гибкостью» и «решающее разные задачи»? В каких случаях вы советуете применять mvc-на клиенте фреймворки вместо full-stack?
По поводу инертности IT-среды, я вам советую посмотреть лекции Дугласа Крокфорда. Не всегда люди способны выбирать и прогнозировать. Чаще каждый хвалит свой язык / свою платформу.
Я не надеюсь вправить любовь одной статьей. Мое дело просто посеять семя сомнения.
Я не сказал умирает. Я сказал появляется. У всех проектов в начале не было коммьюнити. Через какое-то время появилось. Да люди инертны. Даже программисты. Так устроен наш мозг. Это не хорошо и не плохо. Если человек пишет на AngularJS, то его сложно переманить на derby, например. Даже если ему доказать что derby лучше, он всё равно найдет причину остаться на Angular (например, скажет что там коммьюнити больше). Но для людей, которые только начинают писать на node.js выбор фреймворка довольно актуален. Тут большое не паханное поле.
И чтобы вы меня не поняли неправильно. Я не преследую ни каких прямых личных интересов. Я просто идейный. Просто верю что derby лучше. Хочу чтобы он развивался.
Конечно моё. Не стоит серьезно к этому относиться.
Да. В данный момент у derby.js есть адаптер только для Mongo DB. Написать другие адаптеры как ты правильно сказал не сложно. Адаптер выглядит буквально вот так
У Метеора тоже пока с адаптерами не густо, но можно написать. Другое дело что api будет всё равно Mongo Queries.
На мой взгляд REST стал популярным в вебе из-за того, что он красиво ложится на http. Но в реальности как вы сами и говорите у REST много ограничений. В чем его недостатки мы поняли. Объясните в чем его преимущества?
Под «классическим» я имел ввиду REST примерно такого вида:
GET: /users
GET: /users/34
POST: /users/34
PUT: /users/34
DELETE: /users/34
В реальности вам например нужно поменять свойство field у юзеров, которые являются создателями продуктов, которые принадлежат категории с id = 2. Сколько будете делать запросов на сервер, если например окажется что таких пользователей 50? Скорее всего у вас появится метод changeFieldForUsersWithProductsInCategory(categoryId, fieldValue). Со временем подобных методов будет много.
У REST есть и другие минусы:
1) не решена проблема синхронизации данных
2) дублирование кода на клиенте и сервере
Есть ли в derby возможность спрятать код от клиента, чтобы он работал только на сервере?
Конечно. Вам не что не мешает делать ajax-запросы и выполнять код на сервере, ведь derby.js — это обычное express.js приложение. Также обсуждался встроенный механизм для этого (server hooks), например тут. Но к сожалению так сходу не могу найти информацию об этом. Возможно он был в версии 0.3 и его пока не добавили в 0.5.
Очень интересуют детали работы синхронизации моделей через редис:
Я правильно понимаю, что при обновлении модели на клиенте это событие через веб-сокет попадает в редис и дальше раздаётся всем активным клиентам?
Да правильно. Но на самом деле немного сложнее. Каждое приложение derby.js на сервере содержит объект store (тут происходит вся магия), из которого вы создаете модели (model). Модели могут быть на сервере, а могут быть на клиенте (связь через browserchanel). Если это первый запрос на сервер (тот при котором на клиент загружается приложение), то созданная на сервере модель будет сериализованна и отправлена на клиент. Вся работа с данными идет через модели (api одинаковый на сервере и клиенте). Вы можете просто читать какие-то данные из бд или записывать в нее. Так же вы можете подписаться (subscribe) на определенные данные (коллекцию, сущность, свойство сущности или даже произвольную выборку через queries), тогда store будет ловить все события из редис, связанные с подписанными данными этой модели и обновлять эти данные на этой модели. Разные модели могут быть подписаны на разные данные. Более того, derby приложение масштабируется, то есть вы можете запустить несколько derby приложений (на одном или разных серверах) каждое со своим store для одной и той же базы данных.
Для связи между сервером и клиентом используется browserchanel (как в Gmail), потому что веб-сокеты не гарантируют соблюдения порядка получения запросов.
На сколько шустро это работает?
Не могу привести каких-то тестов. Полагаю на столько же шустро, на сколько шустро работает pub-sub в redis.
Можно эту синхронизацию отключать для определённых моделей?
Вы сами выбираете что вам синхронизировать.
Если js, не дай бог, выключен, страница отобразится нормально?
Да. Страница отрендерится на сервере.
redis обязателен.
Для того чтобы синхронизировать данные клиентов нужна некоторая модель событий (так называемая pub-sub). Это возможно реализовать в коде. Но минус будет в том что ваше приложение не сможет масштабироваться. Лучше когда это будет в базе данных. К сожалению в mongo этого нету. А в redis есть и это работает очень быстро. По этому без redis никак. В нем хранится история (сами задаете сколько) последних операций. По сути кэш.
Это всё проиходит вот тут: github.com/share/livedb
mongo не обязательно.
По поводу других бд: архитектура Derby позволяет использовать любые базы данных. Вот таким способом livedb соединен с mongo: github.com/share/livedb-mongo Вы можете написать свой адаптер для любой базы данных.
К тому же вы можете хранить данные в одной базе, а операции в другой или вообще операции не хранить (кроме кэша в редисе).
Хочу добавить по поводу сравнения .net и node.js
node.js в целом значительно приятнее для веба, чем .net и тому есть несколько причин:
1) платформа изначально создавалась для веба (написать веб-сервер можно в 3 строчки)
2) ассинхронность (на хабре была уже статья про миллион одновременных соединений на одном сервере)
3) один язык на сервере и клиенте (на самом деле и библиотеки в основном тоже через browserify)
После того как распробовал node.js, возвращаться на .net совсем не хочется, рекомендую.
А что вы подразумеваете под «вкусом разработчика и необходимой ему гибкостью» и «решающее разные задачи»? В каких случаях вы советуете применять mvc-на клиенте фреймворки вместо full-stack?
Рекомендую node.js. Это сэкономит вам время и силы. А там может и дерби распробуете.
Я не надеюсь вправить любовь одной статьей. Мое дело просто посеять семя сомнения.
И чтобы вы меня не поняли неправильно. Я не преследую ни каких прямых личных интересов. Я просто идейный. Просто верю что derby лучше. Хочу чтобы он развивался.
Да, вы правы, не всегда популярными становятся лучшие технологии.
Да. В данный момент у derby.js есть адаптер только для Mongo DB. Написать другие адаптеры как ты правильно сказал не сложно. Адаптер выглядит буквально вот так
У Метеора тоже пока с адаптерами не густо, но можно написать. Другое дело что api будет всё равно Mongo Queries.
GET: /users
GET: /users/34
POST: /users/34
PUT: /users/34
DELETE: /users/34
В реальности вам например нужно поменять свойство field у юзеров, которые являются создателями продуктов, которые принадлежат категории с id = 2. Сколько будете делать запросов на сервер, если например окажется что таких пользователей 50? Скорее всего у вас появится метод changeFieldForUsersWithProductsInCategory(categoryId, fieldValue). Со временем подобных методов будет много.
У REST есть и другие минусы:
1) не решена проблема синхронизации данных
2) дублирование кода на клиенте и сервере
Конечно. Вам не что не мешает делать ajax-запросы и выполнять код на сервере, ведь derby.js — это обычное express.js приложение. Также обсуждался встроенный механизм для этого (server hooks), например тут. Но к сожалению так сходу не могу найти информацию об этом. Возможно он был в версии 0.3 и его пока не добавили в 0.5.
Очень интересуют детали работы синхронизации моделей через редис:
Я правильно понимаю, что при обновлении модели на клиенте это событие через веб-сокет попадает в редис и дальше раздаётся всем активным клиентам?
Да правильно. Но на самом деле немного сложнее. Каждое приложение derby.js на сервере содержит объект store (тут происходит вся магия), из которого вы создаете модели (model). Модели могут быть на сервере, а могут быть на клиенте (связь через browserchanel). Если это первый запрос на сервер (тот при котором на клиент загружается приложение), то созданная на сервере модель будет сериализованна и отправлена на клиент. Вся работа с данными идет через модели (api одинаковый на сервере и клиенте). Вы можете просто читать какие-то данные из бд или записывать в нее. Так же вы можете подписаться (subscribe) на определенные данные (коллекцию, сущность, свойство сущности или даже произвольную выборку через queries), тогда store будет ловить все события из редис, связанные с подписанными данными этой модели и обновлять эти данные на этой модели. Разные модели могут быть подписаны на разные данные. Более того, derby приложение масштабируется, то есть вы можете запустить несколько derby приложений (на одном или разных серверах) каждое со своим store для одной и той же базы данных.
Для связи между сервером и клиентом используется browserchanel (как в Gmail), потому что веб-сокеты не гарантируют соблюдения порядка получения запросов.
На сколько шустро это работает?
Не могу привести каких-то тестов. Полагаю на столько же шустро, на сколько шустро работает pub-sub в redis.
Можно эту синхронизацию отключать для определённых моделей?
Вы сами выбираете что вам синхронизировать.
Если js, не дай бог, выключен, страница отобразится нормально?
Да. Страница отрендерится на сервере.
derby 0.3: github.com/lefnire/habitrpg/tree/master
тут переписывали на derby 0.5: github.com/lefnire/habitrpg/tree/challenges-and-0.5
Тут кто-то составлял дерево знаний необходимых для понимания derby: workflowy.com/shared/9e4d8b18-af04-4f04-1557-88b31a78c324/
Вопросы задавайте тут: Google Groups
Я тоже помогу, чем могу, пишите.
Для того чтобы синхронизировать данные клиентов нужна некоторая модель событий (так называемая pub-sub). Это возможно реализовать в коде. Но минус будет в том что ваше приложение не сможет масштабироваться. Лучше когда это будет в базе данных. К сожалению в mongo этого нету. А в redis есть и это работает очень быстро. По этому без redis никак. В нем хранится история (сами задаете сколько) последних операций. По сути кэш.
Это всё проиходит вот тут: github.com/share/livedb
mongo не обязательно.
По поводу других бд: архитектура Derby позволяет использовать любые базы данных. Вот таким способом livedb соединен с mongo: github.com/share/livedb-mongo Вы можете написать свой адаптер для любой базы данных.
К тому же вы можете хранить данные в одной базе, а операции в другой или вообще операции не хранить (кроме кэша в редисе).
Чем вас пугает redis?
node.js в целом значительно приятнее для веба, чем .net и тому есть несколько причин:
1) платформа изначально создавалась для веба (написать веб-сервер можно в 3 строчки)
2) ассинхронность (на хабре была уже статья про миллион одновременных соединений на одном сервере)
3) один язык на сервере и клиенте (на самом деле и библиотеки в основном тоже через browserify)
После того как распробовал node.js, возвращаться на .net совсем не хочется, рекомендую.