Backend без проблем. Чудо или будущее?

    Всем привет!

    Друзья, не мне вам рассказывать, да и сами вы знаете о том, как делается backend для серверных/клиент-серверных приложений. В нашем идеальном мире всё начинается с проектирования архитектуры, затем выбираем площадку, затем прикидываем нужное количество машин, как виртуальных, так и нет. Затем происходит сам процесс поднятия архитектуры для разработки/тестирования. Всё готово? Ну поехали писать код, делать первый коммит, обновлять код на сервере из репозитория. Открыли консоль/браузер проверили и поехало. Пока всё просто, а что дальше?

    С течением времени архитектура неизбежно растёт, появляются новые сервисы, новые сервера и тут уже пора подумать о масштабируемости. Серверов чуть больше чем 1?, — надо бы как то логи все вместе собирать. Сразу в голову лезут мысли про аггрегатор логов.

    А когда что-то, не дай бог, падает, сразу приходят мысли о мониторинге. Знакомо, не так ли? Вот и я с друзьями наелся этого. А когда ты в команде — появляются и другие сопутствующие проблемы.

    Можно сразу подумать что мы ничего не слышали про aws, jelastic, heroku, digitalocean, puppet/chief, travis, git-hooks, zabbix, datadog, loggly… Уверяю вас это не так. Мы пытались подружиться с каждой из этих систем. Точнее мы настраивали каждую из этих систем для себя. Но не получали должного эффекта. Всегда появлялись какие то подводные камни и часть работы хотелось бы, как минимум, автоматизировать.

    Живя в таком мире довольно большое количество времени, мы подумали — «ну мы же разработчики, давай-те сделаем с этим что-то». Прикинув проблемы, сопровождающие нас на каждом этапе создания и развития проекта — выписали их на отдельной страничке и превратили их в фичи будущего сервиса.
    И спустя 2 месяца из этого родился сервис — lastbackend.com:



    Проектирование


    Мы начали с самой первой проблемы при построении серверной системы, а именно с построения визуальной схемы проекта. Не знаю как вам, но для меня видеть какой элемент, с каким связан, как текут потоки данных вызывает восхищение, в сравнении со списком серверов и настроенного окружения в вики или в гугл доке. Но судить вам.



    Сам процесс проектирования схемы до боли простой и интуитивный: слева список элементов backend-а, справа рабочее поле. Вот просто берём и перетаскиваем. Надо дать возможность node.js элементу подключиться к mongodb? Пожалуйста — берем и мышкой проводим соединение.



    Настройка и масштабирование


    Каждый элемент в системе уникален, его необходимо настроить и если надо включить его авто-масштабирование. Если элемент является балансировщиком нагрузки, есть место где указываются правила выбора upstream-а. Если элемент имеет исходный код — указываем его репозиторий, переменные окружения, зависимости. Система сама его скачает, установит, запустит.



    И конечно же мы подумали и об авто-деплое — изменились исходники в определённой ветке — хитро и быстро обновили элемент. Мы старались всё сделать удобным, ведь сами пользуемся и первыми видим все недостатки.

    Развёртывание


    И вот самый интересный момент. Когда схема готова и настроена, её развёртывание занимает несколько секунд. Иногда бывает дольше, а иногда вообще моментально. Всё зависит от типов элементов и его исходного кода. Мы в основном программируем на node.js и наши схемы разворачиваются за пару секунд. Самый захватывающий момент — видеть как все настроенные элементы на схеме «оживают» и загораются индикаторы, указывающее текущее состояние элемента.



    Забыл добавить, что мы имеем возможность запускать каждый элемент, у различного хостера/дата-центре. Например для балансировки траффика между странами, можно один элемент запустить в одной стране, другой во второй, а базу данных к примеру где нибудь по центру разместить. Пример конечно не очень, но в целом, думаю, возможность довольно полезная, особенно если знать как и где её применить.



    Вот в принципе и основная часть, позволяющая быстро, красиво и без проблем поднять серверную часть какого либо проекта, однако мы сразу вспомнили про дальнейшие проблемы, а именно:

    Аггрегация логов


    Каждый элемент аггрегирует лог в единое хранилище логов, где можно их смотреть и анализировать, делать поиск и выборки. Теперь нет необходимости подключаться по ssh и grep-ом искать какую либо затаившуюся информацию, или просто анализировать данные

    Мониторинг и система оповещения


    Естественно нам и самим охота поехать на рыбалку или просто отдохнуть зная, что если что-то происходит не то, тебе об этом обязательно доложат. Вот мы и делаем так, что бы обо всех сбоях была моментальная информация. Теперь и голова не болит, о том, что можешь пропустить что нибудь важное.

    Резюме


    Вот в принципе основные проблемы, которые мы старались и стараемся решить нашим сервисом и хоть как то облегчить жизнь брату-разработчику.
    Естественно у меня не получилось перечислить все фичи, постарался выделить только главные, однако в комментариях могу более подробно ответить на все вопросы и пожелания.

    Спасибо за внимание. Очень хотелось бы первым делом прочитать ваше мнение, ответить на ваши вопросы, записать ваши советы и пожелания, а так же всем выдать доступ в закрытое бета тестирование сервиса, которое по предварительным планам начнётся на майских праздниках.

    Получить приглашение на бету можно прямо по этой ссылке. В день открытия тестирования — придёт письмо с данными доступа.

    PS


    Так же друзья, если интересно, можем начать серию технических статей по стеку используемых технологий, а именно node.js, mongodb, redis, sockets, angular, svg и т.п.
    Поделиться публикацией

    Комментарии 79

      +2
      Круто!
      Интересно было бы почитать про SVG и Angular.
        +6
        > Так же друзья, если интересно, можем начать серию технических статей по стеку используемых технологий, а именно node.js, mongodb, redis, sockets, angular, svg и т.п.

        Начинайте прямо сейчас :)
          0
          Бешено плюсую, особенно часть про ноду и монго.
          0
          Не понял одно, это будет какое-то приложение, которое нужно развернуть у себя, или это именно сервис? Или вы «сам себе провайдер»?
            0
            Это сервис, в котором можно мышкой сконструировать себе бекенд, настроить его и запустить в жизнь. А если есть какие то предпочтения по хостингу — амазон или что нибудь другое — то это можно настройками выбрать. В принципе мы являемся прослойкой между хостингом и разработчиком, делая последним жизнь проще.
              0
              То есть у меня есть несколько серверов в разных ДЦ, я просто указываю, на каких серверах какие элементы развернуть и само все взлетает? Оо
                0
                Ну тут есть различные варианты. Можно использовать свои сервера, а можно разворачивать на наших. Второй вариант предпочтительнее, снимает кучу головняка.
                  0
                  А, то есть свои площадки у вас тоже есть… прикольно. Жду бету :)
                    +2
                    Да, всё верно — мы подключаем различных хостеров и настраиваем там наши агенты. Одной из фич у нас записано подбор наиболее бюджетной конфигурации. Другими словами можно будет сравнить, где и как дешевле развернуть систему.
            0
            Довольно интересно, хороший материал.
              0
              Ребят, шикарно!
              Реально хочу попользоваться когда допилите, причем если понравится, думаю даже абонентку платить готов. Только не перемудрите с монетизацией.
                0
                Спасибо. А мы хотим как можно быстрее допилить. А можете посоветовать что нибудь, чего на первый взгляд не хватает, или например — какая модель монетизации была бы ближе всего? Или например какие сервисы тестирования можно было бы подключить, и CI. Хотелось бы набрать побольше отзывов, для дальнейшего развития.
                  0
                  Jenkins & Teamcity нужны просто обязательно
                    +1
                    bamboo )
                    0
                    Sphinx и было б круто какие-либо cmf.
                    Как вариант, интеграцию с Redmine.
                      0
                      Asana.com
                        0
                        Я думаю есть вариант нотификаций из нашей системы в систему управления проектами, однако обратной связи пока придумать не могу. Есть идеи?
                          0
                          Плагин для СУП.

                          Вообще, если что-нибудь типа ifttt прикрутить, то можно разгуляться на любое извращение.
                            0
                            Главное, как мне кажется не перемудрить.
                          0
                          Про Asana в курсе, пробовал, но это не то, что я имел в виду.
                        0
                        Ну пока зверь новый, е понятно чем его кормить и где выгуливать, но посмотрим. На данный момент разве что из мыслей как-то подружить Trello со всей этой радостью, но понимания зачем и как это сделать еще нет.
                          0
                          Как вариант, можете попробовать интегрироваться в продукты Atlasian
                            0
                            bamboo + bitbucket? я правильно понял?
                              0
                              Да хоть в JIRA :)
                        +1
                        А можно как-то это у себя развернуть, а то получается на сторону отдаются доступ к серверам.
                          0
                          По нашим планам — можно будет поставить себе агента, который будет отвечать за разворачивание системы на ваших серверах. На ваше усмотрение. Когда мы продумывали сервис, мы первым делом решили не завязываться с одним хостером, а иметь возможность выбора между облаками, железом и своим железом.
                          0
                          Это всё отлично, но надо же хоть ориентировочную стоимость писать… наверняка же вы этот момент уже продумывали.
                          Без соотношения цены/устранённого головняка картина не полная…
                            0
                            В данный момент мы на этапе разработке и скорейшего выхода в открытую бету. Точная ценовая политика будет понятна только к официальному релизу. Мы хотим что бы сервисом пользовались как крупные корпоративные компании так и независимые разработчики. В свою очередь, хотелось бы услышать ваши пожелания по приемлимой для вас политике ценообразования. Для примера можно привести какой нибудь проект.
                              +2
                              Ну вот смотрите, как пример. Пусть будет сферическое приложение на node. Пусть не нагруженное, но хочется надёжное.
                              1 Load balanser
                              2 node.js (meteor.js)
                              3 MongoDB cluster

                              Всего — 6 сферических машинок. Предположим, проект только стартует и ему с головой хватит 5-10-долларового DO. Выходит 30-60 долларов/месяц.

                              Например, если организацию всего этого хозяйства вы берёте на себя, тогда лично я бы был бы готов заплатить 100-150 долларов, при прочих равных условиях по железу.

                              Как-то так (-:
                            +1
                            У меня несколько странный вопрос:
                            Не могли бы вы открыть доступ к визуальному редактору уже сейчас?
                            К какой-нибудь статической, не привязанной ни к чему версии. И пусть даже всё, что можно будет от неё получить, это только «картинку».
                              +2
                              А почему бы и нет? Думаю к понедельнику может получиться. Я вышлю приглашение.
                                0
                                Тоже бы хотелось получить приглашение в визуальный редактор.
                                И когда ± месяц / год ожидается релиз с рабочим функционалом?
                                  0
                                  Присоединяюсь, и как я понимаю вы без библиотек (svg.js, d3.js, рафаель?) работали с svg?
                                    0
                                    Всё верно. Выбрали чистый svg + angular. Не увидели смысла тащить за собой эти библиотеки.
                                    0
                                    И мне, пожалуйста.
                                    Кажется, это может стать идеальным инструментом для рисования подобных схем (главное, чтобы исходники хранились тектовыми файлами в гите и можно было видеть историю изменений).
                                      0
                                      Вся схема хранится в формате json, со всеми связями и конфигурациями, поэтому экспорт и импорт не составит труда.
                                      0
                                      Получилось? :-)
                                      Или надо было на сайте подписаться, чтобы приглашение получить?
                                        0
                                        Надо было на сайте подписаться конечно.
                                        Но я на самом деле напишу отдельный пост. К понедельнику не получилось, а вот к четвергу железно в наших планах, вместе с небольшими плюшками.
                                      0
                                      Я тоже задолбался рисовать бекенды в gliffy, даже просто удобное набраасывание деплоймент схемы будет весьма полезно
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        +4
                                        Перечитал два раза и так и не понял что же вы предлагаете (посему все что дальше — возможно следствие неправильно истолкованной идеи, но уж извините, как написали так и понял). Комментарии поразили еще больше — такое чувство что это не хабр, а новостное агенство средней степени желтизны.

                                        Если вы реально сталкивались с граблями при построении систем малой и средней степени сложности — как пришли к идее универсализации? В реальных, даже самых простых проектах деплой любого из серверов — это кастомный скрипт немалого размера…

                                        Да, можно и нужно автоматизировать развертывание своей системы (есть даже должность такая — билд-инженер), но это не поддается шаблонизации, по определению! Сколько систем — столько и разных манипуляций с настройками, архитектур и стеков.

                                        Несомненно, ваше решение хорошо подходит для развертывания ваших же серверов под ваши конкретные задачи, но как только к вам потянутся реальные юзеры со своими проблемами — все рассыпется.

                                        Давайте уж графический построитель любого приложения — натянул на экран модуль обработки входящих соединений, 10 обработчиков на все случаи жизни, модуль логгирования (соединяем палочкой с сервером логов) — чего уж там… фейсбук-киллер готов!

                                        P.S. Если вы предлагаете хостинг, настройку и сопровождение — так и пишите, зачем все это заворачивать в Visio-like картинку с клеточками? Совершенно непонятно…
                                          +2
                                          Согласен с вами что существуют системы в которых без напильника не обойтись, однако не все системы такие уж страшные. К примеру можно разобрать деплой системы из комментария выше. Всё просто есть балансер nginx, node.js, mongo.

                                          Чем не простая реальная система?

                                          Ну допустим вы первым делом, будете поднимать окружение для node.js, затем будете поднимать сервер с монгой. Неужели на этапе создания прототипа вы будете писать «кастомный скрипт немалого размера»? Вряд ли! На данном этапе вам надо быстро подготовить окружение для разработки, что бы начать работать.

                                          Далее, когда всё готово к продакшн запуску, необходим тюнинг. Только и на этом этапе, что вы будете например править в конфигах nginx, или в node.js, когда всё и так работает? Никто не говорит что тюнинг не нужен — наоборот! Он даже необходим. Поэтому мы даём возможность настроить каждый элемент схемы. Каждый элемент схемы имеет свой, присущий ему набор конфигураций. Мы даже предусмотрели возможность подгружать конфиг файлы.

                                          Может быть есть какие то специфические места, которые присущи проектам с которыми вы работаете, я бы с удовольствием учёл бы этим моменты при разработки системы.
                                            +1
                                            Рассмотрим пример.
                                            Для инициализации своих серверов я использую иерархию скриптов. Общие скрпиты, которые необходимо выполнять на всех нодах (это всякие мелочи и ньюансы типа вида командной строки, установка пакетов вроде htop, screens, zabbix-agent и т.п., тюнинг параметров ОС) и узко-специальные, для каждой конкретной ноды.
                                            Оставим в стороне скрипт общего назначения (только он один тянет где-то на 200 строк), перейдем к узко-специальному.

                                            Узел с реляционной БД. Скрипт инициализации занимает ~120 строк.

                                            — Установка сервера БД (postgres) из репозитория
                                            — Создание пользователя-админа БД, директорий для БД и индекса (для последующего выноса на отдельный диск)
                                            — Тюнинг /etc/sysctl.conf, /boot/loader.conf специально для данной БД
                                            — Тюнинг postgresql.conf и pg_hba.conf специально для данной БД
                                            — Развертывание самой БД из SQL скриптов (3 разные схемы)
                                            — Набивка базы данными из дампов
                                            — Создание директорий, установка прав
                                            — Копирование на узел и занесение в крон выполнения 8 скриптов по расписанию
                                            — Установка доп. специфич. пакетов (pear-MDB2_Driver_pgsql, php5-pgsql) для выполнения узко-специфич. задач

                                            Ах да, все это я хочу чтобы стояло на ZFS с соотв. тюнингом под БД моего размера, при этом ОС я тоже хочу выбрать себе сам.

                                            В каком месте ваше решение призвано упростить жизнь? Конечно, можно оставить лазейку для «выполнить кастомный скрипт какой угодно сложности», но это уже надувательство, друпальщина…

                                            Кто вообще конечный пользователь вашего продукта? Админ\билд-инженер? Забудьте, вы никогда не перетащите эту категорию из командной строки в гуйню. Неопытный начинающий пользователь? Тоже не выстрелит — неопытный начинающий пользователь споткнется сразу после кружочка WAN и nginx (см. вашу первую картинку).
                                              +1
                                              — Установка сервера БД (postgres) из репозитория
                                              — Создание пользователя-админа БД, директорий для БД и индекса (для последующего выноса на отдельный диск)
                                              — Тюнинг /etc/sysctl.conf, /boot/loader.conf специально для данной БД
                                              — Тюнинг postgresql.conf и pg_hba.conf специально для данной БД
                                              — Развертывание самой БД из SQL скриптов (3 разные схемы)
                                              — Набивка базы данными из дампов
                                              — Создание директорий, установка прав
                                              — Копирование на узел и занесение в крон выполнения 8 скриптов по расписанию
                                              — Установка доп. специфич. пакетов (pear-MDB2_Driver_pgsql, php5-pgsql) для выполнения узко-специфич. задач


                                              Ведь можно скрипты тюнинга прикрутить к элементу? Я же отписал выше —
                                              Мы даже предусмотрели возможность подгружать конфиг файлы.
                                              Для дампов есть специальный раздел настроек сервисов баз данных.

                                              Я не говорю что мы не предусмотрели все нюансы. Эта статья как раз и написана для того что бы их собрать и учесть. Однако, наверное вы упустили одну маленькую деталь: Вы не собираете схему из серверов — вы собираете схему из сервисов, каждый из которых может уникально настраиваться. И наша задача сделать полезный инструмент, которым может пользоваться любой — от разработчика до администратора, до ассистента тех поддержки и мониторинга.

                                              Поэтому и ЗБТ. Был бы рад получить ваши пожелания и рекомендации, я думаю помогли бы учесть некоторые нюансы.

                                              PS
                                              Однако я бы не держал php сервис на одной машине с реляционной бд… судя по вашему скрипту… Потому что как то странно, то тюним на уровне ОС и БД, то саму БД вместе с аппликейшеном держим. Хотя справедливости ради я не знаю что они выполняют. Но выглядит странно.
                                                –3
                                                Вообщем стало понятно: вы покусились задвинуть святое — ком. строку! Что ж, удачи вам в этом неблагодарном (и думается — бесперспективном) деле.
                                                  +1
                                                  Ну почему же сразу задвинуть. Мы и сами используем терминал. Я например программирую исключительно в vi. Да и даже в tmux powerline настраивал, что бы spotify треки мне там рисовал. Это прикольно, но извините, деплоить и обновлять с десяток серверов, уже поднадоело.
                                                    –4
                                                    А что вам мешает написать скрипт, который все это будет делать за вас, почему возникла необходимость в графическом редакторе?
                                                      +2
                                                      Вроде бы черным по белому написано:
                                                      Живя в таком мире довольно большое количество времени, мы подумали — «ну мы же разработчики, давай-те сделаем с этим что-то». Прикинув проблемы, сопровождающие нас на каждом этапе создания и развития проекта — выписали их на отдельной страничке и превратили их в фичи будущего сервиса.

                                                      Еще не опробовав сервис, вы уже начинаете пророчить его крах.
                                                      Вы пишете, что у вас есть скрипт, который все делает за вас, хотя в puppet\chef эти все решения уже есть и это является более взрослым решением, нежели ваши скрипты.

                                                      Возможно, что этот зачаток сможет перерасти в более зрелое решение, для создания инфраструктуры у облачных провайдеров.
                                                        –2
                                                        puppet — типичный overkill. Возможно, кто-то таки потратил время и нервы на его изучение и остался им доволен… И, на секундочку, — все «блекджеки и шлюхи» puppet-а — именно в мощи мета-языка, которым описываются конфиги, GUI там постольку поскольку…

                                                        Будет ли свой мета-язык, сравнимый по мощи с puppet-овским у данного сервиса? Тогда с него и надо было начинать. Пока что подход, выбранный авторами, — дать визуальную картинку на первый план и комментарии типа «Можно использовать свои сервера, а можно разворачивать на наших. Второй вариант предпочтительнее, снимает кучу головняка.» — отпугнет большинство админов и билд-инженеров.
                                                          0
                                                          Судя вашей логике, в принципе использование виртуальных машин так же обречено на провал, как и облачные сервисы.
                                                          Ведь логика всё та же — упростить жизнь и сэкономить время. А по вашим словам получается, что самым идеальным вариантом является построение своего хостинга, саморучно устанавливая сервера в стойки. Можно примеров привести до бесконечности. Просто помню аналогичные холивары на тему облачных сервисов, однако живут и процветают. И более того скажу, есть отличный пример — сервис heroku. Там система push-to-deploy, кстати, довольно распространённая в последнее время. Так что я бы не был бы столь категоричен.
                                                        +1
                                                        Да тогда просто под каждую конфигурацию писать скрипт придётся. Занимались и этим. При этом всё равно нет никакой визуализации. Вот у меня было в проекте 20+ серверов. Была вики с их списком и с перечнем что и как было на них установлено. Когда проект растёт, а живой проект всегда растёт, приходилось каждый раз при внедрении нового сервиса вспоминать и рисовать в голове схему взаимодействия данных. А так всё наглядно и сразу воспринимаешь весь backend. Так же и средства мониторинга сейчас оставляют желать лучшего, не в плане техническом, а в плане визуализации.

                                                        Мы смотрим фильмы с интерфейсами будущего, а сами при этом не понимаем зачем нам визуализация данных. Я предлагаю лучше создавать эти интерфейсы. Пускай методом проб и ошибок, но хоть как то развивать инструменты разработчиков, ведь это помогает быстрее создавать более лучшие продукты.

                                                        Можно привести хорошую аналогию между vi и intellij Idea. Например я не считаю что программировать необходимо исключительно в vi. Есть проекты, в которых хорошая IDE заметно ускорит процесс разработки и позволит избежать ошибок. Иногда и мне приходится так делать, хотя в программировать стараюсь в vi. Так же и в случае проекта.
                                                          0
                                                          Ну поймите же, что деплоймент проектов средней сложности сопоставим по сложности с написанием кода приложений (по сути им и является). До сих пор все попытки визуализировать создание кода с помощью визуальных представлений с треском проваливались. В фильмах конечно все красиво, но на то они и фильмы, что в реальности код пишут руками, а админят из ком. строки. Вашу идею можно сравнить с 3д-файл менеджерами — все баловались, да красиво, да как в фильме, но нафиг никому не нужно. Нарисовать связи можно и в Open Visio каком-нибудь, не ради же красивой картинки вы задумали весь проект?
                                                  0
                                                  Вы пробовали использовать kickstart?
                                                  Про puppet тоже, возможно, что-то слышали.
                                                  Вручную/скриптом я бы делал тут только одно: заливал нуль-дамп в базу.
                                                0
                                                >Несомненно, ваше решение хорошо подходит для развертывания ваших же серверов под ваши конкретные задачи, но как только к вам потянутся реальные юзеры со своими проблемами — все рассыпется.

                                                Может быть поэтому открывают доступ к ЗБТ?
                                                0
                                                комментарий удалён
                                                  0
                                                  Лично мне это чем-то напомнило решения типа Heroku. У них есть входная точка, потом идет роутер, который посылает запросы к worker'ам, а ими может быть все, что угодно — nodejs, go, ruby, python.

                                                  К worker'ам же подключаются различные плагины в виде БД, поиска (elastichsearch), аналитики, отправки писем и т.д., сами эти сервисы работают в «облаках».

                                                  Причем так как это все работает в основном в Amazon датацентрах (и Heroku, и плагины), то связь между системами идет по локальной гигабитной сети и задержки минимальны.
                                                    0
                                                    Всё верно. Heroku это довольно удобно для развёртывания системы. Мы взяли за элемент как раз таки суть dino контейнера. Так-же добавляем сервисы и ко всему прочему логи и мониторинг + визуализация. Вот и в 2х строчках половина сервиса.
                                                    0
                                                    Ставлю плюс. Не за само решение, за хорошую подачу информации. Спасибо.
                                                      0
                                                      пообещайте масштабирование meteor.js приложений — получите хороший PR
                                                        0
                                                        Спасибо за совет. В принципе не вижу проблем в техническом плане.
                                                          0
                                                          Там одна проблема — sticky sessions.
                                                          Именно поэтому я в своём сферическом примере и привёл meteor.js (-:
                                                            0
                                                            Я обязательно напишу вам, как будем интегрировать метеор, для получения бесценных знаний. Сам работал с метеором работал около полугода, но они очень шустро развиваются. Окажете нам помощь в консультациях?
                                                              0
                                                              Ну я в процессе познания пока, пишу проект, а вот где его потом размещать — ещё не придумал. Чем смогу — помогу (-:
                                                              Будем надеяться, что у вас всё получится (-:
                                                        0
                                                        А что означает эта загадочная надпись после регистрации?
                                                        Petrogradsky district.
                                                        St.Petersburg, LED 196626
                                                          0
                                                          Да для экономии времени, мы решили подключить сервис сбора e-mail адресов mailchimp. А он в обязательном порядке решил показывать адрес, введённый мною при регистрации.
                                                          –4
                                                          Было бы интересно узнать состав команды Lastbackend и как развивалась идея и продукт. Что-нибудь типа… сидели мы в кафе и тут упало яблоко. А дальше на салфетках рисовали, а возможно не рисовали.
                                                          Согласитесь, не каждый день рассказывают о таких идеях.
                                                            0
                                                            а к альфе доступ можно както получить?
                                                              0
                                                              На следующей неделе постараемся открыть доступ просто к конструктору-редактору схем. Будем называть эту версию альфой. Так и бета вот вот не за горами.
                                                                0
                                                                куда вам написать для запроса альфы?
                                                                gsamat@gmail.com
                                                                  0
                                                                  Так можно в той-же самой форме на сайте lastbackend.com, я вышлю участникам сообщение об открытии редактора. Спасибо.
                                                                  0
                                                                  Как успехи?
                                                                +1
                                                                Странно но у меня в фаерфоксе диаграмма на вашей главной обрезана
                                                                  0
                                                                  Думаю, даже удобная рисовалка диаграмм конфигураций с заведением спецификаций каждой ноды и возможностью экспорта все этого допустим в pdf или html была бы полезна. Как-нибудь обязательно попробую ваш сервис
                                                                    0
                                                                    Правильно ли я понимаю, что эта штука предназначена для веб-разработчиков, которые хотят обойтись без инженерного отдела для мелких и средних проектов?
                                                                      0
                                                                      Не только. Вот взять к примеру пинтерест. Там есть серверная часть и она довольно большая, с огромным количеством узлов, шедулеров, баз данных и всяких прочих воркеров. Там очень классная система подъема серверов на амазоне, написно тонны скриптов и есть большая вики со схемкой как это всё работает. Так представим на минуту, что ребята берут нашу систему, и тогда у них есть всё так же схема, только живая, из под которой можно управлять всем бекендом и анализировать информацию, мониторить систему.

                                                                      Я считаю что данная система может найти применение как для инди разработчиков, так и для крупных проектов.
                                                                      0
                                                                      Задам вопрос тут по nodejs и Mongodb stackoverflow.com/questions/21269345/handle-lost-connection-to-mongo-db-from-nodejs на который так и нет ответа. Если будет отдельная статья напишу вопрос комментарием там.
                                                                        0
                                                                        Круто! Мне кажется, что даже сам по себе такой редактор с возможностью экспорта/импорта данных в xml/json/yaml имел бы успех)
                                                                        Но вы пошли ещё дальше) Желаю вам не сдаваться и утереть нос всем, кто говорит, что то, что вы делаете — невозможно)

                                                                        Делать невозможные вещи — это самое приятное в работе)
                                                                          0
                                                                          Уже середина июля, а новых фишек, запланированных на июнь пока нет. Проект жив?
                                                                            0
                                                                            Все нововведения пакуются специальным летним релизом, который уже вот вот готов. Проект развивается активно как никогда.
                                                                            Так же из ближайшего релиза — будет специальный новостной блог, для нормального информатирования.

                                                                            Спасибо за интерес к проекту!

                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                          Самое читаемое