Структурирование моего веб-сервера в узле

Question

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

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

Пока моя структура выглядит следующим образом

const controller = require('../../Controllers');
const libs = require('../../Lib');
/* GET users listing. */
router.get('/', libs.util.isLoggedIn, libs.util.checkPermission('/user-dashboard', 'view'), (req, res, next) => {
controller.UserController.getDashboardDetail(req, res, (error, result) => {
    if (error) {
        next(error);
        return;
    }
    result.session = req.session;
    res.render('consume/user-dashboard', {
        coursearray: result,
        username: req.session.displayname
    });
}) 
});

Как и на этом маршруте '/', я запрашиваю панель пользователя, поэтому перед предоставлением этого я проверяю пользователя, используя 2 middlewares Вход в систему с использованием функции libs.util.isLoggedIn и разрешение с использованием libs.util.checkPermissionтогда мои controllers предоставят необходимые данные.

Как мы можем после получения безошибочных данных, я отрисовываю свои View, используя res.render.

Моя проблема в том, как я могу использовать этотот же API когда мне нужны только те данные, которые я предоставляю для render функции для какого-либо мобильного приложения?

Я не хочу создавать еще один API для того же, что я ужеделать.

Мой API не должен заботиться о том, построена ли страница на server стороне или client стороне.

Как мне изменить мой текущий API, чтобы добиться этого?

Есть ли какая-то ошибка в структуре, которую я использую смой routes?

Answer 1

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

Подход 1 - заголовок Accepted.

Общепринятое правило - проверять заголовок Accepted (или аналогичный), чтобы увидеть, какой формат он запрашивает.Если клиент запрашивает HTML, вы можете ответить ответом res.render (например, веб-браузер), если они запрашивают JSON или XML, тогда вы можете отвечать этими форматами по мере необходимости.Вы должны быть в состоянии упаковать это как промежуточное ПО для своих маршрутов, и при определении маршрута передайте имя шаблона, которое можно игнорировать, например, при ответе JSON.

См. Документацию HTTP для получения дополнительной информации оПринятый заголовок.

Подход 2 - Унифицированная бизнес-логика с двумя тонкими приложениями

Альтернативой (и популярным выбором большинства) является создание вашегобизнес-логика в каком-то модуле "lib".Затем создайте два тонких веб-приложения, одно из которых обслуживает HTML, а другое может работать на конечной точке /api, которая обслуживает только JSON.

Поэтому, если пользователь запрашивает example.com/profile, он получит страницу HTML.назад.Если они запросят example.com/api/profile, они получат ответ JSON.Обе эти конечные точки отправляют запрос к ресурсу user в папке проектов lib, но одна затем форматирует его для HTML, а другая - для JSON.Это часто желаемый подход, поскольку страницы HTML часто используют несколько ресурсов для создания страницы.Например, на этой странице описываются некоторые аспекты профиля пользователя, сам вопрос, ответы, «горячие сетевые вопросы» и «связанные вопросы».Если вы только что запросили представление JSON, вы ожидаете получить только вопрос и последующие ответы.