Три вопроса о построении многоплатформенного сервиса?

Доброго времени,
думаю, что многим будет интересно узнать ответы.
исходные данные: пользователю предоставляется некая функциональность на разных платформах, т.е. есть сайт, есть desktop-приложение, есть мобильное приложение. Ну например, банально: TODO list. Где-то функциональность дублируется, т.е. добавить себе в расписание задачку можно с телефона, или на сайт зайти, или же с desktop-версии. Какие-то фичи есть только на одной платформе. Понятно, что раз данные должны сливаться в одно место, синхронизироваться, за всем этим стоит сервер с rest API.

Что я делаю: беру ASP.net 5 (ну т.е. Core 1), делаю там сайт на MVC 6, кладу это все в Azure. Мобилку наверно на Cordova напишу, desktop - на WPF.

Вопрос #1: надо ли WebAPI (который будут дергать все платформы, в т.ч. сайт) делать отдельным проектом? Почему нельзя просто в этом же MVC сайте сделать для rest-вызовов парочку отдельных контроллеров, которые будут отдавать json?

Вопрос #2: как сделать единую авторизацию? Я понимаю, как работает rest, и что обычно юзаются токены, не хочу нагородить велосипед, наверняка в ASP.net все это как-то из коробки работает, т.е. человек регается на сайте,
запрос к WebAPI (если это отдельный проект) - видимо, берем токен из текущего авторизованного юзера.
запрос с Desktop - один раз спрашиваем логин и пароль, отсылаем на WebAPI, получаем токен и храним его на компе? (вот это все велосипедить?)
ну и мобилка видимо также. Как это все сделать из коробки, красиво?

Вопрос #3: по расписанию надо отправлять почту. Правильно ли я понимаю, что в Azure настраивается schedule, который дергает некий rest в моем WebAPI (кстати, какой? post?), а он шлет почту? Там тоже с авторизацией вопрос, Azure дает выбрать либо сертификат клиента, либо логин/пароль задать.

спасибо!
  • Вопрос задан
  • 411 просмотров
Решения вопроса 2
xkeirainx
@xkeirainx
Фулстэк энтерпрайз разной степени кровавости
Ответы на все три вопроса зависят от вашего подхода к разработке и культуры кода. На правах советов:

#1 Наличие отдельного бэкенда даёт больше возможностей масштабирования, и меньшею связанность. Но зачем тогда серверсайд для сайта? Отдельные методы под json — это двойная работа, которая и так уже сделана в WebAPI.

#2 Как корпоративный программист я не силён в человеческой авторизации, но то, что вы описываете и так похоже на современный метод работы с токенами: посмотрите в сторону refresh token.

#3 Это будет авторизация вашей внутри инфраструктуры, так что делайте как удобно. Метод этот — явно не CRUD, можно сконфигурировать отдельный роут для подобных запросов.
Ответ написан
Делать WebAPI отдельным приложением имеет смысл если планируешь ОГРОМНУЮ нагрузку и будешь его запускать на отдельном инстансе. Пока я бы делал одним приложением.

Если использовать asp net identity то в едином приложении MVC+WebAPI проблем нет, для остального придется "ручками" получать токен и передавать его в каждом запросе.

Для отправки почты лучше использовать WebJob. Но тут не совсем понятно зачем тебе аутентификация ты от кого кому письма слать собираешься?
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
modestguy
@modestguy
full-stack web developer
Рекомендую посмотреть видео: www.youtube.com/watch?v=OCYJ7GOp2QY
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы