т.е. в компоненте или на странице

, async fetch () {
            this.items = await this.$api('controller_name', 'index');
...

и 2 плагина

api-context.client.js

inject('api', async (controller, method, params) => {
        return await context.$axios['$' + (params ? 'post' : 'get')]('/api/' + controller + '/' + method, params); 
...

api-context.server.js

inject('api', async (controller, method, params) => {
...
        let api = require('~/api/' + controller);
        let result = await api[method](db, params);
...

ну хоть через контроллер. И что это дает кроме повышенной сложности?

Один сервис,вместо двух?)
*Экономия на спичках*

еси дело в скорости то круто было бы увидеть замеры

1. пониженную сложность
2. отсутствие лишних звеньев в архитектуре (однако возможности масштабирования остаются)
3. весь код сервера и клиента вместе
4. существенно более быстрый рендеринг SSR, т.к. мы вместо
Nuxt->HTTP->Node(или другой язык)->MySQL(или другая БД)->Node(или другой язык)->HTTP->Nuxt
идём напрямую
Nuxt->MySQL(или другая БД)->Nuxt

1, 2 спорно, но допустим, дело вкуса, зависит от кейса

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

нет, не делал, но тут будет существенно насколько далеко http api

А как нукст можно использовать в качестве сервера? Точнее бэкенда

Типа все время чекать isServer?

понятно, зря. Вот в твоем случае апи на том же сервере (еси делать все запросы по хттп). Т.е. задержка примерно 2-5мс. Т.е. в пределах погрешности общего времени рендеринга, сложно такую оптимизацию назвать «существенной»

да, можно использовать, всё время чекать не надо
просто 2 плагина, 1 клиентский другой серверный

есть serverMiddleware или сам нухт может быть поднят поверх нодовского бэкэнда, как мидлвер

я прост 2 года назад тоже над этим экспериметировал

смотри, просто по логике, чтобы выполнить 1 http запрос, надо на стороне апи сервера:
1. принять запрос
2. распарсить и вализировать параметры
3. проверить авторизацию
4. собственно получить данные
5. отправить данные по http

а теперь представь, что у тебя страница собирается из скажем 10 таких запросов, т.е. на каждый запрос выполняются пункты 1-5, а в моём случае, 1 раз выполнили авторизацию и выполнили п.4 10 раз

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

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

а в чём могут быть минусы такого решения? я их пока не вижу

в конце концов, я всегда могу перейти обратно, просто
1. удалив файл api-context.server.js
2. переименовав файл api-context.server.js -> api-context.js

то что бэкэнд на js-e?))

это вопрос? да, бэкэнд на Node получается

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