REST API от парусов.js и webUI на nginx

Недавно я наткнулся на Sailes.js, и он мне очень понравился (поэтому я еще новичок). Мой вопрос связан с развертыванием моих веб-сервисов и пользовательского интерфейса.

Мое приложение будет иметь веб-интерфейс, а также мобильный пользовательский интерфейс, и я выбрал следующее: веб-интерфейс — AngularJS + bootstrap Мобильный пользовательский интерфейс — AngularJS + bootstrap + cordova (для доступа к собственному API)

Я хочу поддерживать общий код в моем веб-интерфейсе и мобильном интерфейсе. Таким образом, у меня есть варианты: разместить паруса.js только как сервер API веб-сервисов и разместить пользовательский интерфейс на отдельном сервере (например, nginx/apache). Мне придется сделать выборочное разделение кода (особенно целевая страница + доступ к нативному слою).

Каковы плюсы/минусы этого подхода? Любой опыт, входы были бы очень полезны.


person user1749672    schedule 11.04.2014    source источник


Ответы (2)


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

Вам не нужно разделять API и само веб-приложение. Вы можете просто запустить Sails на определенном порту (по умолчанию 1337) и Nginx в качестве обратного прокси-сервера, перенаправляя соединения на паруса и обслуживая статические файлы, соответствующие вашему пользовательскому интерфейсу (JS, CSS, шрифты и т. д.).

Вот и пример для настройки Nginx и приложения node с этой настройкой.


В основном у вас есть два варианта:


A — ВЕБ-ПРИЛОЖЕНИЕ С АДАПТИВНЫМ ДИЗАЙНОМ

Отзывчивое веб-приложение Sails с Bootstrap или Foundation позволяет вам использовать 100 % пользовательского интерфейса. Вы обслуживаете скомпилированные и минимизированные статические данные со своего веб-сервера Nginx (или лучше из CDN) со всей логикой Angular, стилями и т. д.

Браузеры и мобильные устройства подключаются к вашему Sails API (например, yourdomain.com/api/v1/)


B – WEBAPP + CORDOVA MOBILE NATIVE APP

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

В этом случае вы можете поддерживать ряд модулей css и angular в отдельном репо, который используется обоими пользовательскими интерфейсами, и загружать его через подмодуль git или аналогичный. Но я бы (лично) предпочел отдельные кодовые базы или адаптивное веб-приложение. Все зависит от того, насколько большой станет кодовая база вашего приложения.

Веб-приложение и приложение Cordova по-прежнему подключаются к вашему Sails API (например, yourdomain.com/api/v1/)


Надеюсь, поможет

person sdude    schedule 13.04.2014
comment
то, к чему я пытаюсь стремиться, - это иметь общую кодовую базу для моего веб-интерфейса и пользовательского интерфейса мобильного приложения (я планирую доставлять мобильное приложение через магазины приложений). При этом я хочу как можно больше повторно использовать код с различиями, связанными с целевой страницей и некоторыми нативными привязками (такими как камера, местоположение). С вашим вариантом B я правильно понял, что мне, возможно, придется поддерживать отдельную базу кода для определенных частей мобильного интерфейса? Существуют ли проверенные способы поддержки этой общей кодовой базы (относительно разработки и развертывания)? - person user1749672; 14.04.2014
comment
На мой взгляд, единственный способ максимизировать кодовую базу пользовательского интерфейса в мобильном приложении и веб-приложении — это использовать один и тот же интерфейс для вашего приложения, потому что SailsJS API будет одинаковым для обоих. Это означает ту же логику AngularJS и тот же CSS для мобильных устройств. - person sdude; 14.04.2014
comment
Обновлен вариант Б с возможным подходом. - person sdude; 14.04.2014

Что касается аспекта дизайна кода вашего вопроса, совершенно нормально использовать паруса для создания веб-сервиса или API.

Следующие ресурсы могут быть полезны:

person Upvote    schedule 12.04.2014
comment
@SDude, спасибо за вклад. Принял ваш ответ. Я собираюсь тщательно организовать свой код, чтобы его можно было повторно использовать в мобильном и веб-интерфейсе. - person user1749672; 16.04.2014