Клиентская или серверная структура?

Question

Мой проект был бы своего рода craiglist, местом, где пользователи могли публиковать анонсы (объекты жизни, автомобили, квартира и т. Д.). Итак, аутентификация, страница профиля, создание контента, отображение продаваемых объектов и т. Д.

Я разработал очень большую часть бэкэнд: у меня есть API RESTful в трехуровневой архитектуре, разработанной в Java. Он создает связь с db, чтобы предоставить мне разные URL-адреса и отправить мне соответствующий JSON.

URL, например:

http://api.mywebsite.fr/user?userid=1 посылает меня:

{"user": {"username": "jdoe1234", "email", "jdoe1234@gmail.com"}} 

У меня есть адреса для всех действий, выполняемых на всей территории (создание, обновления Анонс последние данные ... все, и я тщательно декларировали их POST, GET, UPDATE, DELETE и т. д.). Существует также oAuth для защиты API от запросов, которые не разрешены для токена.

Это все для аспекта «сервер», я думаю, что с этим нет никаких проблем.

Но если все действия управляются веб-сервисом, я не вижу интереса, который может принести мне большую инфраструктуру на стороне сервера, такую ​​как Symfony/cakePHP, Zend и т. Д., Чтобы сделать HTTP-запросы в разных точках входа , извлекать JSON и заполнять HTML.

Итак, я посмотрел на инфраструктуру клиента, например, на Угловое, Ember и т. Д. Сначала мне показалось, что это очень подходит для моего случая: возможность HTTP-запросов, управление тем, что делать в случае успеха или ошибки, непосредственно использовать полученный JSON для заполнения вида и т. Д.

Мне даже не удалось сделать мой выбор между angularjs и Ember, оба очень похожи, но с выпуском Angular v2 я опасаюсь поддерживаемости v1 (если я выберу Angular, это будет v1, потому что большинство уроков и вопросов относятся к Angular 1.X).

Я не знаю, правильно ли я делаю это, выбирая рамки на стороне клиента, я боюсь, что они «бразильские» (не уверенные в этом слове, извините) меня. Кроме того, он полностью создан в браузере, поэтому пользователь может полностью изменить весь код и данные, которые я предоставляю. Мне это кажется странным.

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

Резюме: С теми вещами, которые у меня уже есть (webservice/api), неплохо использовать клиентскую инфраструктуру, такую ​​как Angular, или я должен оставаться на большой стороне сервера, например Symfony/Zend и т. Д.? Зная, что я позиционирую себя в контексте, в котором эта платформа будет широко использоваться (сопоставимый трафик).

Answer 1

Я бы сказал - зависит от того, хотите ли вы в будущем быть более опытным парнем или бэкэндом. Если вы хотите быть полным разработчиком стека, то он не применяется.

На мой взгляд, как Symfony/Zend, так и другие крупные серверные структуры не так интересны, как динамические интерфейсные фреймворки JavaScript, такие как Ember/Angular/React.

Кроме того, если у вас уже есть API RESTful и аутентификация OAuth, реализованная в бэкэнд-части, я бы пошел с Ember. Зачем? Ember Data - отличный инструмент для общения с API-интерфейсом. Он зрелый, он лениво загружает записи, когда они нужны, и это очень настраиваемый.

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

Ember имеет встроенную защиту, как дезинфицировать данные, визуализируются в этом шаблонном языке - HTMLBars. Кроме того, существует стандарт CORS и политики безопасности контента (CSP), который реализован в Ember.

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

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

С вещами, которые у меня уже есть (вебсервис/апи), это хорошая идея использовать структуру клиента, как угловые?

Да, это очень популярное решение для использования стека MEAN или использования API Ember + RESTful.

Почему я должен выбирать Ember вместо Angular (у которых есть более обширные сообщества/учебники/ответы на вопросы)?

Угловые имеет большие сообщества/учебники/отвечали на вопросы, но когда я начал какой-то сторонний проект с Угловым, чтобы узнать его возможные преимущества перед Эмбером, я был удивлен, как не было никакого консенсуса в этом сообществе для этого одну вещи. Таким образом, вместо быстрого поиска, как объявлять и использовать директивы (я думаю, это было то, что меня смутило), я должен сделать еще одно исследование, путь которого является лучшим. Кроме того, существует множество способов настройки проекта (где размещать пользовательские директивы, разные угловые объекты), и вам нужно сделать другое исследование, которое нужно выбрать. Я закончил использовать repo healthy-gulp-angular как мой шаблон, но вы можете видеть, что он не обновлялся в течение 8 месяцев, но я думаю, что за эти 8 месяцев у Angular было много изменений, и я не уверен, что это репо - лучший выбор ,

В Ember у вас есть инструмент Ember CLI, который построен с принципом конвенции по конфигурации. У вас также есть данные Ember Data, которые используют JSON API standard - если у вас сейчас нет совместимой с JSON API-серверной стороны, вы можете написать собственный адаптер для нормализации ответов сервера или изменить способ ответа на бэкэнд. В Ember у вас нет всей этой головной боли и различных лучших решений, чтобы сделать одну основную вещь, зависящую от того, кого вы спрашиваете.

Что означает «одностраничное приложение»?

Одностраничное приложение - это, в основном, страница, которая не требует перезагрузки всех активов и HTML при навигации. Это преимущество перед PHP - когда пользователь переезжает в другое место, он загружает только новые данные для этого маршрута. More info here.

Являются ли эти рамки доступными для создания реальных маршрутов? ( www.myapp/profil/userid и т. д.)

Да, конечно. Вам даже не нужно # в вашем URL-адресе. С простым правилом перезаписи и небольшим количеством логики для маршрута profile и указанным путем profile/:userid, когда пользователь откроет URL-адрес www.myapp/profile/userid, он будет автоматически отправлен по маршруту profile, а userid будет интерпретирован как параметр маршрута, поэтому вы можете принять это userid и найти пользователя запись из магазина в model крюк.

Answer 2

Client = скорость, Server = стабильность

JS каркасы обновление один раз в неделю Non-Js фоновой один раз в год

сторона клиента зависит поведение в зависимости от браузера Спина связанные только с машиной, но не с окружающей средой

Я выбрал FE coz Я устал отлаживать код, записывая значения переменных в базу данных, чтобы фактически увидеть, что происходит в контроллерах -_-