Ядро и вебморду - отдельно
Всем привет!
Хотелось бы узнать ваши мнения и ссылки на "почитать". В общем, наш проект - некая система, которая собирает инфу с неких железок, разбросанных по области, и потом предоставляет эту же самую инфу, только добротно пережёванную и в человеческом виде конечным клиентам. Проблема в том, что само веб-приложение написано криво, начинаются проблемы с перформансом и логикой (в двух разных концах проекта можно найти две идентичные по названию и ожидаемому поведению функции, но возвращающие совершенно разный бред). Соответственно, разработка нового функционала уже начинает сильно напрягать нас самих. А раз уж здесь тусуются клёвые личности в веб-деве..;) В общем: Хочется запилить некое ядро, которое будет иметь только web-API с набором нескольких функций. Таким образом можно будет пилить любые приложения - под мобилку, под десктопы, под веб и даже под чайник))) В первую очеред, конечно же, хочется запилить грамотное single-page приложение с связке с таким ядром. Сам вопрос: 1) на чём\как писать ядро. Ваши best practices. Ну и не только ваши :) 2) как лучше организовать фронтенд (фреймворки, практики) для такой архитектуры? Заранее спасибо |
Ответ: Ядро и вебморду - отдельно
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 приложением с разделенными частями как описано выше. |
Ответ: Ядро и вебморду - отдельно
Спасибо!
|
Ответ: Ядро и вебморду - отдельно
Latency такой, пару месяцев :)
|
Ответ: Ядро и вебморду - отдельно
>4 !
|
Часовой пояс GMT +4, время: 10:37. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot