Ядро и вебморду - отдельно

[Reizel]

Всем привет!

Хотелось бы узнать ваши мнения и ссылки на "почитать".
В общем, наш проект - некая система, которая собирает инфу с неких железок, разбросанных по области, и потом предоставляет эту же самую инфу, только добротно пережёванную и в человеческом виде конечным клиентам.
Проблема в том, что само веб-приложение написано криво, начинаются проблемы с перформансом и логикой (в двух разных концах проекта можно найти две идентичные по названию и ожидаемому поведению функции, но возвращающие совершенно разный бред). Соответственно, разработка нового функционала уже начинает сильно напрягать нас самих. А раз уж здесь тусуются клёвые личности в веб-деве..

В общем:
Хочется запилить некое ядро, которое будет иметь только web-API с набором нескольких функций. Таким образом можно будет пилить любые приложения - под мобилку, под десктопы, под веб и даже под чайник)))
В первую очеред, конечно же, хочется запилить грамотное single-page приложение с связке с таким ядром.
Сам вопрос:
1) на чём\как писать ядро. Ваши best practices. Ну и не только ваши
2) как лучше организовать фронтенд (фреймворки, практики) для такой архитектуры?

Заранее спасибо

[moka]

API first - отличный метод для разработки проектов с будущим развитием.
Я лично использовал такой подход на большом ряду проектов, какие в основном преимущества:

1. Легче изменять разные компоненты.
2. Легче улучшать отдельные компоненты.
3. Клиент - не является первым гражданином для ядра, таким образом можно принимать решения исходя из контекста, а не навязанной зависимости.
4. Много клиентов: мобил, web, десктоп.
5. Чистая БД - архитектура информации будет хранится в бд так как нужно, а не потому что так "удобнее клиенту".
6. Производительность - тут в разы легче профайлить и улучшать разные компоненты.
7. Микросервисы - это один из крутейших преимуществ. Например как ты сказал у вас есть ядро, и есть веб клиент. И есть сторонние источники данных. Следственно у вас должно быть ядро API, для доступа к данным, далее если клиент сам может слать данные, делаешь систему аутентификации и контроля API пользователей. Если объем данных большой, и требует удаленной обработки - тогда нужно иметь горизонтально разделенные сервисы для обработки этих данных до того как пихать в основную бд.

Клиент можно пилить на чем угодно и в разы удобнее делать single-page приложение.

Конкретно мой опыт на одном из проектов: http://lovewall.visitbritain.com/en
API - node.js.
Клиент - php, который curl'ит на стороне сервера и клиента API как полноценный API user.
Медиа сервер - генерирует картинки из CMS и PDF когда нужно для разного контента.
Аналитические приложения - напрямую читают бд, иногда скрипты делают снапшоты данных, и тогда делают аналитику т.к. она бывает тяжелая, следственно должна выполнятся на других серверах.
CMS - полностью single-page приложение, никакого back-end'а, только HTML+CSS+JS.

Сейчас в PlayCanvas у нас такой же подход примерно, есть много разных разделенных сущностей, это позволяет легче двигаться вперед.
Но самое главное, не используйте никаких фреймворков с слишком сильной диктацией, например angular.js - это полный перебор, вы будете слишком зависить от него.
Либо крупные MVC - также очень не рекомендую, для API не нужен MVC - это перебор.

Я очень рекомендую рассмотреть такой вариант:
node.js + express.js + mongodb.
Почему? Все весьма просто:
node.js - джава-скрипт, асинхронная парадигма, для API может быть большая нагрузка и большой поток запросов, если серверная платформа будет использовать потоки и блокировать их, то у вас оперативка и CPU быстро уйдет вникуда. Запросы в бд - это IO операция, в node.js это асинхронно, следтвенно пока сервер ждет ответа от бд, он обрабатывает другие запросы. Также легко поднять много API серверов для горизонтального масштабирования.
JSON - работая с API, это самый удобный формат. Забудьте про legacy XML - это убого, медленно и не удобно. Т.к. работа идет с JSON'ом, то на сервере нужно иметь удобство по работе с ним, также и клиенту очень легко с ним работать.
Express.js - имхо, уже зарекомендовал себя как очень гибкий мини-фреймворк, все что он позволяет по сути это используя middleware парадигму определять цепи методов и обработчиков запросов. В общем поиграйся с ним, там мало "диктации", следственно можно на нем сделать и говно, а можно и конфетку.
MongoDB - это NoSQL база, хранит документы в виде JSON объектов, с очень мощной и гибкой индексацией, есть индексация по массивам, сферическая гео индексация, compound, и другие. Также aggregation и mapReduce - весьма крутые инструменты для работы с большим объемом данных, и сложными запросами.
Работая с JSON'ом, это очень удобно, т.к. бд у тебя будет в очень хорошем состоянии, тем самым получить данные даже напрямую с бд - будет весьма просто. Также формат данных не нужно преобразовывать практически, до самого клиента, и это огромный плюс.

Это лично мои предпочтения после много-летнего опыта с разными проектами, я работал и с MVC фреймворками на C#, PHP, Python, Node.js, и кучей популярных CMS: WordPress, Joomla, Drupal, и все это дерьмецо и рядом не стоит с отлично построенным API-like приложением с разделенными частями как описано выше.

[Reizel]

Спасибо!

[moka]

Latency такой, пару месяцев

[impersonalis]

>4 !