Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 71
У вас там рейтинг сам меняется, или кто-то кликает и вы данные подтягиваете?)
Кто-то кликает — и они меняются.
интересная вещь Meteor, сходу мало что понятно, надо будет посмотреть подробнее)
Этот пример работает с базой MongoDB. исходный код примера можно посмотреть тут.
Смахивает на NodeJS
colors.meteor.com уже лежит.
За весь скринкаст ни слова не сказали про то, как оно работает вообще. Кругом магия, все само.
За весь скринкаст ни слова не сказали про то, как оно работает вообще. Кругом магия, все само.
Не удивительно что лежит. На HN новость о Meteor в топе. И и во многих блогах начали появляться статьи об этом фреймворке и много кто сейчас все это пробует.
Насчет магии согласен. Сам пока не особо вкуриваю как там что работает))
Насчет магии согласен. Сам пока не особо вкуриваю как там что работает))
Достаточно запустить пример, чтобы все стало ясно. Там раз в секунду, а то и чаще идет тупой POST-запрос через Ajax на сервер.
То есть вот это:
— это маркетинговая чушь. Пацаны просто не разобрались, что такое REST и зачем он нужен.
То есть вот это:
Пишите ваш код клиентской части, как если бы она была запущена на сервере, и имела прямой доступ к базе данных. Больше не придется получать данные через REST.
— это маркетинговая чушь. Пацаны просто не разобрались, что такое REST и зачем он нужен.
Да я уже почитал сырцы и проверил как оно работает. Все равно, оставило больше вопросов, чем ответов.
Странная задумка вцелом. Не очень понятно на кого расчитано.
С одной стороны, «вау, как круто, я вот тут пишу джаваскрипт лапшу в файлик, а оно само за меня все перегружает и рисует», а с другой все эти темплейты на Handlebars, нода с зависимостями — все это не для новичков-школьников.
Опытный программер не станет это использовать, пока не поймет, как все внутри устроено. А когда поймет, тоже скорее всего не станет. А неопытный тупо не разберется, как с этим работать.
Но демка, конечно, красивая и впечатлающая, нечего сказать.
Странная задумка вцелом. Не очень понятно на кого расчитано.
С одной стороны, «вау, как круто, я вот тут пишу джаваскрипт лапшу в файлик, а оно само за меня все перегружает и рисует», а с другой все эти темплейты на Handlebars, нода с зависимостями — все это не для новичков-школьников.
Опытный программер не станет это использовать, пока не поймет, как все внутри устроено. А когда поймет, тоже скорее всего не станет. А неопытный тупо не разберется, как с этим работать.
Но демка, конечно, красивая и впечатлающая, нечего сказать.
Почему не websocket?
кроме websockets можно еще использовать long polling, server-sent events, местами forever frames. думаю, разработчики должны будут дойти до этого
Лонг пулинг в данном месте плох, ибо не держит постоянного соединения, а события происходят раз в секунду, собственно, ни какого ожидания (чем и знаменит лонг-пулинг) не происходит, для этого случая лонг-пулинг мало чем будет отличаться от долбежки постами. SSE и сокеты — правильное решение для любого случая, а фреймы — для совместимости со старыми браузерами.
Судя по главному сайту, у них long polling с таймаутом в 25 секунд. А думать пока не знаю что, время покажет ;)
яростно плюсую. REST это офигенно, какие ему могут быть замены? Оо
Я так понял, под Windows работать не заставить?
Да, потому что установка производится shell-скриптом.
Это довольно глупо, потому что node.js работает под Windows, так что они могли бы прибегнуть к помощи npm и сделать своё средство кросс-платформенным, кабы пожелали.
Правда, может быть, они употребляют такие модули, которые не кросс-платформенны до сих пор — не портированы под Windows? Список пакетов, на которые Meteor полагается, лежит в соответствующей папке открытого исходного кода на сайте GitHub, так что желающие могут проверить эту версию их побуждений.
Это довольно глупо, потому что node.js работает под Windows, так что они могли бы прибегнуть к помощи npm и сделать своё средство кросс-платформенным, кабы пожелали.
Правда, может быть, они употребляют такие модули, которые не кросс-платформенны до сих пор — не портированы под Windows? Список пакетов, на которые Meteor полагается, лежит в соответствующей папке открытого исходного кода на сайте GitHub, так что желающие могут проверить эту версию их побуждений.
Да собственно то что на windows не работает не так критично.
насколько я слышал, node.js под Windows пока далёк от идеала и местами серьезно барахлит. или это была деза?
> Это довольно глупо, потому что XXX работает под YYY, так что они могли бы прибегнуть к помощи ZZZ и сделать своё средство кросс-платформенным, кабы пожелали.
Вы не представляете сколько в мире десятков тысяч софтин, про которые можно сказать что-то подобное.
Вы не представляете сколько в мире десятков тысяч софтин, про которые можно сказать что-то подобное.
Супер! Даже отдельный пакет для поддержки coffee script есть. Все откладывал изучение ноды, но, видимо, пора начинать :)
У примера какойто глюк. Чужие данные обнавляются если не давить на кнопку какоето время. Если давить сравнительно быстро то только твои клики меняют значение
> Хотелось бы почитать мнений хабровчан об этом Meteor.
— за то, что они пользуются только POST'ом,
— за то, то они используют URI типа xxxx/xxxxx/xhr и xxxx/xxxxx/xhr_send там, где нужно просто использовать GET и POST к xxxx/xxxxx
— за то, что они называют это добром, мол, REST не нужен
— за то, что они таким образом решили посрать на все, что предоставляет REST
убивать
— за то, что они пользуются только POST'ом,
— за то, то они используют URI типа xxxx/xxxxx/xhr и xxxx/xxxxx/xhr_send там, где нужно просто использовать GET и POST к xxxx/xxxxx
— за то, что они называют это добром, мол, REST не нужен
— за то, что они таким образом решили посрать на все, что предоставляет REST
убивать
А вы сделали такие выводы только из анализа приведенной демки? Или основательно почитав документацию и посмотрев другие демки?
За прямой доступ к БД — тоже убивать.
А вот «Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality.»
Да, я уже писал это ниже.
мочить в сортире. xhr_send, back to php
Ух оно и долбит же ж постами сервер.
Разве такое не через постоянное соединение Server-sent events лучше делать?
У меня оно живет минутку, а потом на все JSON запросы начинает отвечать 404 до обновления страницы.
А как с безопасностью, если доступ к базе из клиентской части прямо такой прозрачный?
Разбираться времени нет, а в статье одна реклама вместо ответов на актуальные вопросы по сути.
Если кто копать будет глубже чем «ах» и «вау», то напишите:
1. Разве тут нет кода, который чисто клиентский и чисто серверный? Все может и там и там работать?
2. Как организовано разграничение прав по доступу к API и аутентификация?
3. Какая модель безопасности и защита от поддельных клиентов?
4. При таком активном обмене запросами можно ли SSE прикрутить или sockets?
5. Что с библиотеками контролов для GUI? Можно ли их подключать и как?
Разве такое не через постоянное соединение Server-sent events лучше делать?
У меня оно живет минутку, а потом на все JSON запросы начинает отвечать 404 до обновления страницы.
А как с безопасностью, если доступ к базе из клиентской части прямо такой прозрачный?
Разбираться времени нет, а в статье одна реклама вместо ответов на актуальные вопросы по сути.
Если кто копать будет глубже чем «ах» и «вау», то напишите:
1. Разве тут нет кода, который чисто клиентский и чисто серверный? Все может и там и там работать?
2. Как организовано разграничение прав по доступу к API и аутентификация?
3. Какая модель безопасности и защита от поддельных клиентов?
4. При таком активном обмене запросами можно ли SSE прикрутить или sockets?
5. Что с библиотеками контролов для GUI? Можно ли их подключать и как?
1. Все в одном коде может быть(см. ссылки ниже).
2. Там есть разграничение: Meteor.is_client и Meteor.is_server.
2. Там есть разграничение: Meteor.is_client и Meteor.is_server.
Это JavaScript — можно всё.
А версия 0.3.2 со статусом Preview что-то может говорить?
Прочитал про метеор. Что-то понятно и что-то нет. Я так понял, там внутри какой-то свой веб-сервер. Не понятно, как он справляется с высокими нагрузками? Имеет ли он что-то общее с NodeJS? И у меня не сложилось мнение, что с помощью метеора скорость разработки резко возрастет.
>>но даже и новички
>>Пишите всё приложение полностью на чистом JavaScript
>>Пишите всё приложение полностью на чистом JavaScript
Возможно я не так всё понял, но эта тема похожа с тем, что делал Google, называется всё это вроде pubsubhubup — code.google.com/p/pubsubhubbub/
То, что сделал гугл, вообще вроде как для atom и rss. Meteor работает «поверх» node.js, позволяет писать приложения на javascript (или coffee script), рендеринг шаблонов на клиенте, все данные в json, работа с базой напрямую из клиента (потом введут ограничения на crud, пока вроде их нет), почти отсутствует разделение кода на серверную/клиентскую части + легкий выкат новых версий с обновлением клиентов и т.д.
Пока еще версия 0.3.2, многое будет улучшаться/развиваться. Фреймворк писали несколько человек полгода. Вообще, почитайте лучше тему на HN, там много интересного.
Пока еще версия 0.3.2, многое будет улучшаться/развиваться. Фреймворк писали несколько человек полгода. Вообще, почитайте лучше тему на HN, там много интересного.
Если его сочиняли полгода, то это объясняет, почему он вовсе не работает под Windows. Нормально портировали Node на Windows только в ноябре прошлого года, и даже тогда Node был голым движком, оттого что портирование модулей, сочинённых независимыми разработчиками, только началось. Оно и сейчас-то идёт «со скрипом» (например, у модуля node-sqlite3 нет официальной Windows-версии — а ведь это средство чтения баз SQLite, а не хухры-мухры!…).
Если разработчики ноды использут linux или mac, и не используют windows – зачем им делать порт? Просто, по-моему, здесь все зависит от активности windows-сообщества: никто не мешает сделать pull-request с поддержкой windows. Здесь история как с рельсами: да, можно под win, но зачем?
Просто, по-моему, здесь всё зависит от активности Windows-сообщества: никто не мешает сделатьЕсть такой pull request для модуляpull request с поддержкой Windows.
Фреймворк прикольный.
Если кому интересно, то для .Net есть более низкоуровневый аналог в виде SignalR
Вот за вечер не так давно написал демо для лекции по KnockoutJS и SignalR
todoknockr.apphb.com/Home/History
Если кому интересно, то для .Net есть более низкоуровневый аналог в виде SignalR
Вот за вечер не так давно написал демо для лекции по KnockoutJS и SignalR
todoknockr.apphb.com/Home/History
Это все классно конечно, но как-то не особо понятен смысл подгрузки js на 200кб для обновления одной таблички? Смысл с точки зрения клиента, который, например, зайдет на эту страничку с мобильника с платным трафиком?
Как по мне так: github.com/socketstream/socketstream выглядит получше.
Тем временем кто-то уже добавил Альберта Эйнштейна и Луи Лагранжа.
Не забываем что это лишь превью фреймворка и сторого судить пока не стоит.
Этому нашлось объяснение в документации: «В настоящее время клиенты имеют полный доступ для записи в коллекции. Они могут выполнять произвольные Mongo команды. Как только мы добавим аутентификацию, вы сможете ограничивать доступ клиентов для доступа к записи, изменению и удалению. Мы так-же добавим валидаторы и ORM-подобный функционал.»
Не забываем что это лишь превью фреймворка и сторого судить пока не стоит.
Этому нашлось объяснение в документации: «В настоящее время клиенты имеют полный доступ для записи в коллекции. Они могут выполнять произвольные Mongo команды. Как только мы добавим аутентификацию, вы сможете ограничивать доступ клиентов для доступа к записи, изменению и удалению. Мы так-же добавим валидаторы и ORM-подобный функционал.»
Имеется ввиду в демку. Изначально были персонажи указанные в исходном коде демки.
Технология — интересная, а пример — никудышный, он не раскрывает преимуществ и фокусирует человека на том, что выбран не правильный метод взаимодействия с сервером, а между тем, технология полезна совсем в других случаях, для написания прикладных приложений со сложной бизнес-логикой. Технология покажет себя полностью когда обмен с сервером не такой частый и периодический, как в примере, а на несколько порядков реже и не по таймеру. Или Вы хотите сказать, что тогда он все равно будет долбить постами каждую секунду?
> ехнология полезна совсем в других случаях, для написания прикладных приложений со сложной бизнес-логикой.
Пока они не поймут, что такое REST, и чем он хорош именно для сложной бизнес-логики, полезной эта технология не будет
> Технология покажет себя полностью когда обмен с сервером не такой частый и периодический, как в примере, а на несколько порядков реже и не по таймеру. Или Вы хотите сказать, что тогда он все равно будет долбить постами каждую секунду?
Тогда она не будет ничем отличаться от десятка других технологий — от Backbone до ExtJS
Пока они не поймут, что такое REST, и чем он хорош именно для сложной бизнес-логики, полезной эта технология не будет
> Технология покажет себя полностью когда обмен с сервером не такой частый и периодический, как в примере, а на несколько порядков реже и не по таймеру. Или Вы хотите сказать, что тогда он все равно будет долбить постами каждую секунду?
Тогда она не будет ничем отличаться от десятка других технологий — от Backbone до ExtJS
То, что у них еще сыро и много исканий, это ясно, но это же и не плохо. Если команда или технология прекращает искания и считает, что точно знает, как хорошо, а как плохо, то это значит, что пошли клепать шаблонные закостенелые решения.
А Вы можете нам всем пояснить, чем REST «хорош именно для сложной бизнес-логики»? Без ссылок, а в 5 строчках, кратко и четко. Я думаю, что как для приведенного в статье примера, так и для сложной бизнес-логики, хорош классический клиент-серверный подход с установлением постоянного соединения и выделением на сервере «состояния» (данных в оперативной памяти, связанных с сессией пользователя).
А о пользе REST, я не спорю, но REST хорош совсем для другого, для высоконагруженных систем общего пользования, и ограниченного функционала, не прикладных систем. REST — это подход для не динамических приложений, а для массовой надежной выдачи контента или для массового обслуживания однотипных процессов. Вот тогда нет возможности каждому абоненту память выделять, и хранить в ней особо нечего.
А Вы можете нам всем пояснить, чем REST «хорош именно для сложной бизнес-логики»? Без ссылок, а в 5 строчках, кратко и четко. Я думаю, что как для приведенного в статье примера, так и для сложной бизнес-логики, хорош классический клиент-серверный подход с установлением постоянного соединения и выделением на сервере «состояния» (данных в оперативной памяти, связанных с сессией пользователя).
А о пользе REST, я не спорю, но REST хорош совсем для другого, для высоконагруженных систем общего пользования, и ограниченного функционала, не прикладных систем. REST — это подход для не динамических приложений, а для массовой надежной выдачи контента или для массового обслуживания однотипных процессов. Вот тогда нет возможности каждому абоненту память выделять, и хранить в ней особо нечего.
> А Вы можете нам всем пояснить, чем REST «хорош именно для сложной бизнес-логики»?
— отлаженные, понятные и простые принципы работы
— четкий контроль за многими аспектами работы клиент-серверной системы:
— стандартизированные ошибки
— стандартизированные опции, контролирующие взаимодействие клиента и сервера (кэширование, определение формата посылаемых данных, версионность API, MVCC(!) и т.п.)
— прозрачная (для клиента) масштабируемость
— стандартизированный API, который неплохо ложится поверх CRUD, если уметь его готовить
Вместо всего этого авторы предлагают долбить сервер POST'ами и говорят, что это — хорошо :-\
> REST хорош совсем для другого, для высоконагруженных систем общего пользования, и ограниченного функционала, не прикладных систем.
Давайте, вы сначала почитаете, что такое REST, а потом будете о нем говорить, хорошо?
> REST — это подход для не динамических приложений, а для массовой надежной выдачи контента или для массового обслуживания однотипных процессов.
Большей бредятины я в жизни не видел. Как-будто в динамических приложениях ВНЕЗАПНО изменились запросы к серверу, ага ага. Вы бы хотя бы открыли Firebug и посмотрели, что за запросы этот «мегафреймворк» выполняет.
> Вот тогда нет возможности каждому абоненту память выделять, и хранить в ней особо нечего.
Такой возможности нет никогда. Сервера не резиновые
— отлаженные, понятные и простые принципы работы
— четкий контроль за многими аспектами работы клиент-серверной системы:
— стандартизированные ошибки
— стандартизированные опции, контролирующие взаимодействие клиента и сервера (кэширование, определение формата посылаемых данных, версионность API, MVCC(!) и т.п.)
— прозрачная (для клиента) масштабируемость
— стандартизированный API, который неплохо ложится поверх CRUD, если уметь его готовить
Вместо всего этого авторы предлагают долбить сервер POST'ами и говорят, что это — хорошо :-\
> REST хорош совсем для другого, для высоконагруженных систем общего пользования, и ограниченного функционала, не прикладных систем.
Давайте, вы сначала почитаете, что такое REST, а потом будете о нем говорить, хорошо?
> REST — это подход для не динамических приложений, а для массовой надежной выдачи контента или для массового обслуживания однотипных процессов.
Большей бредятины я в жизни не видел. Как-будто в динамических приложениях ВНЕЗАПНО изменились запросы к серверу, ага ага. Вы бы хотя бы открыли Firebug и посмотрели, что за запросы этот «мегафреймворк» выполняет.
> Вот тогда нет возможности каждому абоненту память выделять, и хранить в ней особо нечего.
Такой возможности нет никогда. Сервера не резиновые
жжошь, согласен.
>Вместо всего этого авторы предлагают долбить сервер POST'ами и говорят, что это — хорошо :-\
обработка поста и гета длится одинаковое время — это как бы для заметки. а в остальном поддерживаю.
REST это унифицированный и самый удобный формат для работы с Ресурсами по HTTP. GET для получения, POST для отправки, DELETE для удаления и тд. Это позволяет четко и решительно работать с бизнес логикой путем массы скаффолдинга, это ЧПУ из коробки, это защита от CSRF придолжном понимании сути реста. Это прекрасно.
>Вместо всего этого авторы предлагают долбить сервер POST'ами и говорят, что это — хорошо :-\
обработка поста и гета длится одинаковое время — это как бы для заметки. а в остальном поддерживаю.
REST это унифицированный и самый удобный формат для работы с Ресурсами по HTTP. GET для получения, POST для отправки, DELETE для удаления и тд. Это позволяет четко и решительно работать с бизнес логикой путем массы скаффолдинга, это ЧПУ из коробки, это защита от CSRF придолжном понимании сути реста. Это прекрасно.
Демо выглядит интересно, но не более.
Скорее всего, данный проект — конь в вакууме; дюже сомнуваюся я, что это выкидыш реального, живого продукта.
Проект нарушает конвенции экосистемы node.js, на котором построен; я бы на месте разработчиков не попадался на глаза Исааку. Почему было не слепить свои пакеты поверх принятого сообществом и давно уже ставшего официальным npm? Даже в сам проект не удосужились положить package.json с описанием зависимостей, поэтому все зависимости, вместо выкачивания из npm репозитория выкачиваются со своего CDN
Сам node.js, кстати, тоже берется оттуда. Ага, в бинарном виде.
Вышеописанное я не могу списать даже на «early stage» проекта. Создать свою систему распространения на коленке было проще, чем использовать готовую и отлично живущую? :\
Скорее всего, данный проект — конь в вакууме; дюже сомнуваюся я, что это выкидыш реального, живого продукта.
Проект нарушает конвенции экосистемы node.js, на котором построен; я бы на месте разработчиков не попадался на глаза Исааку. Почему было не слепить свои пакеты поверх принятого сообществом и давно уже ставшего официальным npm? Даже в сам проект не удосужились положить package.json с описанием зависимостей, поэтому все зависимости, вместо выкачивания из npm репозитория выкачиваются со своего CDN
Сам node.js, кстати, тоже берется оттуда. Ага, в бинарном виде.
Вышеописанное я не могу списать даже на «early stage» проекта. Создать свою систему распространения на коленке было проще, чем использовать готовую и отлично живущую? :\
Пруф по поводу выкачивания бинарного node.js и зависимостей (порезалась ссылка из коммента куда-то):
github.com/meteor/meteor/blob/master/meteor#L47
github.com/meteor/meteor/blob/master/meteor#L57
github.com/meteor/meteor/blob/master/meteor#L47
github.com/meteor/meteor/blob/master/meteor#L57
До Akshell и Wakanda, имхо, пока очень далеко. И открытость решения это не сглаживает.
Судя по всему это продолжение обещающего быть популярным тренда backend-as-a-service. Вот совсем недавно был http://backlift.com, например, который можно использовать для хостинга backbone.js приложений. Правда не знаю, появилась ли там авторизация и управление пользовательскими сессиями.
> Meteor поддерживает любой язык шаблонов.
Хм… надо попробовать с monkeylib.markup.
Хм… надо попробовать с monkeylib.markup.
Ой, так это-ж Nitrogen, только на JS и глючный О_о
чем оно лучше dotCloud?
У меня просьба к людям, которые могут изъянятся на нормальнос языке.
Что это? Чем оно полезно? С чем его можно сравнить? Как это использовать и для чего?
P.S.
Всю статью можно было сократить до ссылки.
Что это? Чем оно полезно? С чем его можно сравнить? Как это использовать и для чего?
P.S.
Всю статью можно было сократить до ссылки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Meteor — Новый способ создания приложений