Comments 18
Если откровенно как и в прошлый раз не совсем понял выгоду использования вашей платформы, ведь многое из предлагаемого вами можно написать самому за очень короткий период, а если использовать опенсорсные наработки, то в течение дня. Но это все относится к большим проектам. Может если писать маленький проект и нет сервер сайд разработчика… хотя такие проекты уже давно в прошлом.
И еще интересно сколько человек работает над проектом?
И еще интересно сколько человек работает над проектом?
За очень короткий период уже не получится потому что там действительно большой объем работы и с каждым днем платформа будет функциональнее и больше.
Первый момент, пример с клиентскими разработчиками, которые без знаний разработки серверной части спокойно поднимут полноценное настроенное окружение на сервере со своей БД, кешированием и т.д. одним лишь вызовом метода GenerateApp из сервиса управления приложениями, и после этого у них в руках множество сервисов, можно писать на чистом javascript или actionscript веб приложения, которые смогут обмениваться данными через сеть и хранить большие объемы данных в БД, а также получают возможность манипулировать этими данными мощностями платформы.
Второй момент, чем больше приложений тем лучше, так как интерфейсы обмена данными унифицированы, то и интеграция между приложениями будет проще, априори у таких приложений будет существовать API т.е. не нужно делать отдельное API достаточно расшарить данные через сервис Прав доступа на другие приложения или пользователей и все, забирать их можно через существующие методы сервисов.
Третий момент, все таки команда далеко не новичков в этом деле целенаправленно развивает на протяжение многих месяцев сервисы и интерфейсы. Создавая комплексное решение команда сделает качественнее работу, чем просто поднять за один день систему в которой будет и удобная работа с БД (например тот же ORM) и управление правами доступа. Представьте что платформа это более совершенный инструмент. Зачем разработчику делать сначала инструмент, а потом продукт с помощью этого инструмента.
Четвертый момент, это делегирование нагрузок, даже если разработчики имеют свои сервера и серверные наработки, они могут использовать API платформы для дублирования данных и других целей.
Первый момент, пример с клиентскими разработчиками, которые без знаний разработки серверной части спокойно поднимут полноценное настроенное окружение на сервере со своей БД, кешированием и т.д. одним лишь вызовом метода GenerateApp из сервиса управления приложениями, и после этого у них в руках множество сервисов, можно писать на чистом javascript или actionscript веб приложения, которые смогут обмениваться данными через сеть и хранить большие объемы данных в БД, а также получают возможность манипулировать этими данными мощностями платформы.
Второй момент, чем больше приложений тем лучше, так как интерфейсы обмена данными унифицированы, то и интеграция между приложениями будет проще, априори у таких приложений будет существовать API т.е. не нужно делать отдельное API достаточно расшарить данные через сервис Прав доступа на другие приложения или пользователей и все, забирать их можно через существующие методы сервисов.
Третий момент, все таки команда далеко не новичков в этом деле целенаправленно развивает на протяжение многих месяцев сервисы и интерфейсы. Создавая комплексное решение команда сделает качественнее работу, чем просто поднять за один день систему в которой будет и удобная работа с БД (например тот же ORM) и управление правами доступа. Представьте что платформа это более совершенный инструмент. Зачем разработчику делать сначала инструмент, а потом продукт с помощью этого инструмента.
Четвертый момент, это делегирование нагрузок, даже если разработчики имеют свои сервера и серверные наработки, они могут использовать API платформы для дублирования данных и других целей.
Спасибо за развернутый ответ. Как и предполагал ваша платформа неплохо подойдет для программирования виджетов и программ для мобильников.
SAAS подход будет и в монитезации? Или пока рано спрашивать?
SAAS подход будет и в монитезации? Или пока рано спрашивать?
Да, наверное пока рано спрашивать.
> Как и предполагал ваша платформа неплохо подойдет для программирования виджетов и программ для мобильников.
На самом деле все зависит от наполнения сервисами. Можно вызвать метод, и где то далеко десятки серверов произведут сложный расчет и пользователь увидит результат который бы на локальной машине (не говоря уже о портативном устройстве) он получал часами. Да, разработчик как и пользователь получает легкую оболочку, но под ней может скрываться серьезный монстр :) Нужно дать сложные вещи через простой интерфейс доступа.
> Как и предполагал ваша платформа неплохо подойдет для программирования виджетов и программ для мобильников.
На самом деле все зависит от наполнения сервисами. Можно вызвать метод, и где то далеко десятки серверов произведут сложный расчет и пользователь увидит результат который бы на локальной машине (не говоря уже о портативном устройстве) он получал часами. Да, разработчик как и пользователь получает легкую оболочку, но под ней может скрываться серьезный монстр :) Нужно дать сложные вещи через простой интерфейс доступа.
Кстати, уж кому кому а вам ли не знать, что Javascript отнюдь не только клиентский язык ;) на нем интереснейшие сервера есть ;)
Вам не кажется, что для продвижения вашей платформы необходимо создать несколько реальных приложений, которые будут её использовать? Создать целиком вашими силами, или силами других команд, с которыми вы как-то договоритесь.
Если такие приложения уже есть, то почему нет их списка на главной странице? Пока я там вижу только примеры использования. Из этих примеров лишь один можно назвать законченным приложением — галерея картинок. Назвать его реальным, а тем более использующим всю мощь платформы — наверное, даже у вас язык не повернётся ;)
Если такие приложения уже есть, то почему нет их списка на главной странице? Пока я там вижу только примеры использования. Из этих примеров лишь один можно назвать законченным приложением — галерея картинок. Назвать его реальным, а тем более использующим всю мощь платформы — наверное, даже у вас язык не повернётся ;)
В статье было написано
> К слову, на днях будет анонсирован виджет формы обратной связи
На все рук не хватает. Постепенно делаем, например если бы зашли в форум, то нашли бы сервис формы обратной связи, он с админкой и виджетом написан полностью на js. Осталось докрутить дизайн, остальная функциональность почти завершена. Если интересная галерея, то ее можно довести до готового продукта. Просто цель примеров показать как создавать приложения на базе плафтормы.
> К слову, на днях будет анонсирован виджет формы обратной связи
На все рук не хватает. Постепенно делаем, например если бы зашли в форум, то нашли бы сервис формы обратной связи, он с админкой и виджетом написан полностью на js. Осталось докрутить дизайн, остальная функциональность почти завершена. Если интересная галерея, то ее можно довести до готового продукта. Просто цель примеров показать как создавать приложения на базе плафтормы.
На самом деле, проблема отсутствия приложений (а они практически отсутствуют — именно реальные, с реальными режимами работы, с реальными пользователями, с реальной нагрузкой) ещё более глубока (осознаю глубину постепенно).
Возьмём за основу вашу аналогию: платформа — инструмент. Как можно разрабатывать, допустим, универсальную отвёртку, не имея под рукой набор разных шурупов? Штамповать их позже, чтобы к отвертке подошли? :))
Другой пример, более близкий к теме. Как появлялись такие платформы как Django, Ruby on Rails? Есть набор задач, выделяется общая часть, под неё делается интрумент, который со временем становится универсальным. А затем и общедоступным, и популярным. Но сначала — для внутренних нужд.
Подытожу «философией»: нельзя сделать хорошего обобщения, не накопив статистику по частным случаям, и не проверив обобщения на ещё большем количестве частных случаев. Вообще непонятно, как вы смогли написать платформу для приложений, которые ещё не написаны :)
P. S. Упреждающий удар: ответ в смысле, что кое-что всё же есть и работает — не впечатляет. Эти приложения не должны были писаться позже. Они должны были писаться одновременно с платформой, даже с некоторым опережением. Они уже должны быть, сейчас, вчера, а не появляться со дня на день. И они уже должны быть рабочими, масштабными, известными. Тогда с продвижением платформы не было бы никаких проблем. Вы бы просто сказали интернетам: «А вы знаете такие проекты как A, B, C? Так вот, они все работают на Hivext, и мы решили сделать эту платформу доступной и для вас».
Возьмём за основу вашу аналогию: платформа — инструмент. Как можно разрабатывать, допустим, универсальную отвёртку, не имея под рукой набор разных шурупов? Штамповать их позже, чтобы к отвертке подошли? :))
Другой пример, более близкий к теме. Как появлялись такие платформы как Django, Ruby on Rails? Есть набор задач, выделяется общая часть, под неё делается интрумент, который со временем становится универсальным. А затем и общедоступным, и популярным. Но сначала — для внутренних нужд.
Подытожу «философией»: нельзя сделать хорошего обобщения, не накопив статистику по частным случаям, и не проверив обобщения на ещё большем количестве частных случаев. Вообще непонятно, как вы смогли написать платформу для приложений, которые ещё не написаны :)
P. S. Упреждающий удар: ответ в смысле, что кое-что всё же есть и работает — не впечатляет. Эти приложения не должны были писаться позже. Они должны были писаться одновременно с платформой, даже с некоторым опережением. Они уже должны быть, сейчас, вчера, а не появляться со дня на день. И они уже должны быть рабочими, масштабными, известными. Тогда с продвижением платформы не было бы никаких проблем. Вы бы просто сказали интернетам: «А вы знаете такие проекты как A, B, C? Так вот, они все работают на Hivext, и мы решили сделать эту платформу доступной и для вас».
вы правы, относительно продвижения. на самом деле так и будет. но сейчас задача не в продвижении. мы сделали очень сложную и интересную «весчь». нам радостно поделится этим с кем-то еще понимающим. вдруг кто подскажет как сделать удобнее, лучше…
платформа разрабатывалась под решение конкретных задач (под конкретные шурупы), которые встречались при разработке приложений до платформы. Но все же, отвертка и шуруп плохое сравнение. Шуруп это уже готовый продукт. Шурупы в текущем примере — это сторонние готовые сервсисы. Под них будет со временем адаптирована отвертка.
Гораздо больше подходит вариант Топор (платформа) и Буратино (приложение). Так вот топор со времен станет пилорамой, с помощью которой можно будет быстро стругать буратин.
платформа разрабатывалась под решение конкретных задач (под конкретные шурупы), которые встречались при разработке приложений до платформы. Но все же, отвертка и шуруп плохое сравнение. Шуруп это уже готовый продукт. Шурупы в текущем примере — это сторонние готовые сервсисы. Под них будет со временем адаптирована отвертка.
Гораздо больше подходит вариант Топор (платформа) и Буратино (приложение). Так вот топор со времен станет пилорамой, с помощью которой можно будет быстро стругать буратин.
а у меня такой вот вопрос — как видится, является или будет ли являться ограничение, накладываемые НТТР, критическими для приложений, использующих ваши сервисы? в частности — быстродействие? Будут ли другие протоколы, например, мне было бы очень интересно использовать что-то вроде сокета и/или Thrift, google proto buffer и прочие.
естественно определенные ограничения HTTP будет накладывать. все завит от решаемой задачи. к примеру если вам нужно отправить СМС через сервис, то я не думаю что ограничения скорости HTTP важны вообще в данном случае. Ну вот в случае если вам необходимо получать часто + большие объемы данных на один экземпляр приложения, потом складывать обратно такие же кучи, тогда да. В таком случае наилучшим решением является максимально приблизить логику обработки данных к ядру платформы, чтобы обмен данными производился в оперативной памяти.
По поводу сокетов — это интересная мысль, давайте смоделируем ситуацию или попробуем решить какую-то насущную проблему. Думаю в процессе обсуждения найдем оптимальное решение.
По поводу сокетов — это интересная мысль, давайте смоделируем ситуацию или попробуем решить какую-то насущную проблему. Думаю в процессе обсуждения найдем оптимальное решение.
Сама архитектура такая: ядро -> логика сервисов -> протоколы доступа.
Т.е. сервисы существуют сами по себе и не привязаны ни к каким протоколам изначально, следовательно сервисы могут иметь очень много протоколов доступа включая бинарные. Вариант с бинарными протоколами интересен (спасибо за внимание и хорошую идею) и он нужен, в течении ближайшего времени мы определимся с ним.
Т.е. сервисы существуют сами по себе и не привязаны ни к каким протоколам изначально, следовательно сервисы могут иметь очень много протоколов доступа включая бинарные. Вариант с бинарными протоколами интересен (спасибо за внимание и хорошую идею) и он нужен, в течении ближайшего времени мы определимся с ним.
Мне кажется вы немного путаете. HTTP и тот же thrift (это фэйсбуковский же или что-то другое?) лежат на разных уровня. Thrift или гуглевское решение — это замена xml. HTTP — это протокол прикладного уровня передачи данных. Т.е. трифт и буфер протокол от гугли это форматы сериализации данных для rpc. Трифт немножко больше, чем просто сериализатор (это полноценный протокол rpc, «немного» описанием вызовов расширен ;) ). А как протокол передачи данных на прикладном уровне остается HTTP, куда нам от него деться :) На нем сейчас все, включая потоковое видео и аудио.
ЗЫЖ моя аналогия такова. Thrift — замена SOAP/XML(rpc), GPB — замена xml, именно как сериализатора данных.
ЗЫЖ моя аналогия такова. Thrift — замена SOAP/XML(rpc), GPB — замена xml, именно как сериализатора данных.
да, это я про фейсбуковский протокол, переданный апачу.
Нет, там используется бинарная передача через сокет, посмотрите пример для питона например на офф сайте (http://incubator.apache.org/thrift/). Кроме этого, в случае размещения на одной машине, это даст выиграш — все же HTTP был создан для совсем другого и в других средах.
Кстати, вроде как потоковое видео и ауддио всеже не по HTTP передается, кроме случая его закачки в виде save as, а все же через RTTP протокол…
Нет, там используется бинарная передача через сокет, посмотрите пример для питона например на офф сайте (http://incubator.apache.org/thrift/). Кроме этого, в случае размещения на одной машине, это даст выиграш — все же HTTP был создан для совсем другого и в других средах.
Кстати, вроде как потоковое видео и ауддио всеже не по HTTP передается, кроме случая его закачки в виде save as, а все же через RTTP протокол…
RTP это протокол другого уровня, относительно HTTP. Он по сути находится на транспортном уровне, хоть и использует для передачи UDP, но это полноценный протокол 4го уровня (если OSI модель). Так что в сети для потокового контента прекрасно используется HTTP без серьезных проблем. Точнее проблемы есть, но все же потоковое видео преобладает пока на HTTP (http streaming).
По поводу трифта, так это практически аналогично передачи XML через сокеты. В принципе трифту всеравно, хттп, его протокол по сокетам, через шаред мемори или через файл. Это как бы не часть протокола, это часть фрэймворка трифтовского. Для чего интерфейс будет реализован, через то и пойдет обмен.
ЗЫЖ Так что, если с точки зрения транспортного протокола, то трифт не совсем таков. Вот эффективность ухода здесь не столько от HTTP, сколько от XML-RPC, конечно убирается и лишний HTTP, хотя мягко говоря не всегда лучше от него отказываться, как по надежности, так и по скорости.
Ну а для вызова на одной машине(сервере лоально) есть намного более продвинутые RPC протоколы.
По поводу трифта, так это практически аналогично передачи XML через сокеты. В принципе трифту всеравно, хттп, его протокол по сокетам, через шаред мемори или через файл. Это как бы не часть протокола, это часть фрэймворка трифтовского. Для чего интерфейс будет реализован, через то и пойдет обмен.
ЗЫЖ Так что, если с точки зрения транспортного протокола, то трифт не совсем таков. Вот эффективность ухода здесь не столько от HTTP, сколько от XML-RPC, конечно убирается и лишний HTTP, хотя мягко говоря не всегда лучше от него отказываться, как по надежности, так и по скорости.
Ну а для вызова на одной машине(сервере лоально) есть намного более продвинутые RPC протоколы.
вчера добавили AMF и AMFx. на очереди Thrift.
Sign up to leave a comment.
Hivext — Платформа для разработки веб приложений