не корректно так говорить

На беке жава с микросервисами... Еедпоинтов вагон

иногда можно вывести и частично

и параллельно ретраить те что упали

В моем случае нет

пиши прослойку на ноде

Для работы с моделью нужен десяток работающих ендпоинтов

которая будет фасадом над микросервисами

По этому кейс с половиной рабочих инпутов не рассматриваю

и возвращать нужные модели

Зачем?

Чтобы клиент в 1 ендпоинт стучал?

Микросервисы и так нужные модели возвращают

да, что б дергать 1 ендпоинт

и не тащить на клиент архитектуру бэка

плюс адапторы же будут

такие преобразования дешевле на сервере делать

Ну хз, такое себе предложение

Мне удобно иметь возможность рулить порядком запросов

так делают в проде многие

в случае с микросервисами

Ща покажу портянку

Которая мне не нравится

http://caolan.github.io/async/ и вот это для организации запросов с ретраями удобно

еще момент - 1 запрос с клиента vs пачка

на ноде ты потом кеширование тоже можешь сделать

const Campaign = { namespaced: true, state: { browsers: [], deviceTypes: [], platforms: [], categories: [], creatives: [], countries: [], usagetypes: [] }, actions: { loadBrowsers ({ commit }, payload) { return new Promise((resolve, reject) => { API({ method: 'GET', url: '/api/campaign/browser' }).then(response => { commit('setBrowsers', response.data.slice(0,50)); resolve(response.data); }).catch(err => reject(err)) }); }, loadDeviceTypes ({commit}, payload) { return new Promise((resolve, reject) => { API({ method: 'GET', url: '/api/campaign/device-type', }).then(response => resolve(commit('setDeviceType', response.data))) .catch(err => reject(err)) }); }, loadPlatform ({commit}, payload) { return new Promise((resolve, reject) => { API({ method: 'GET', url: '/api/campaign/platform', }).then(response => resolve(commit('setPlatform', response.data))) .catch(err => reject(err)) }); }, loadCategories ({commit}, payload) { return new Promise((resolve, reject) => { API({ method: 'GET', url: '/api/category', }).then(response => resolve(commit('setCategories', response.data))) .catch(err => reject(err)) }); }, loadCreatives ({commit}, campaignId) { return new Promise((resolve, reject) => { API({ method: 'GET', url: '/api/campaign/'+campaignId+'/creative', }).then(response => resolve(commit('setCreatives', response.data))) .catch(err => reject(err)) }); }, loadCountries ({commit}, payload) { return new Promise((resolve, reject) => { API({ method: 'GET', url: '/api/campaign/country', }).then(response => resolve(commit('setCountries', response.data.map(c => c.name)))) .catch(err => reject(err)) }); }, loadUsageTypes ({commit}, payload) { return new Promise((resolve, reject) => { API({ method: 'GET', url: '/api/campaign/usage-type', }).then(response => resolve(commit('setUsageTypes', response.data))) .catch(err => reject(err)) }); } }, mutations: { setBrowsers (state, browsers) { state.browsers = browsers; }, setDeviceType (state, devicetype) { state.deviceTypes = devicetype; }, setPlatform (state, platforms) { state.platforms = platforms; }, setCategories (state, category) { state.categories = category; }, setCreatives (state, creatives) { state.creatives = creatives; }, setCountries (state, countries) { state.countries = countries; }, setUsageTypes (state, usagetypes) { state.usagetypes = usagetypes; } }, getters: { browsers: state => state.browsers, platforms: state => state.platforms, deviceTypes: state => state.deviceTypes, categories: state => state.categories, countries: state => state.countries, usagetypes: state => state.usagetypes, } } export default Campaign;

если апи поменяется

такие преобразования дешевле на сервере делать

Почему дешевле?

то быстрее поменять на ноде тоже

Кусочек портянки)

Почему дешевле?

потому что клиентская тачка может быть любой

вынеси все запросы для начала в сервис

и оттуда их дергай

передавая callback'и

потому что клиентская тачка может быть любой

С таким подходом, кажется проще ssr мутить

API это инстанс axiosa

и?

Мне бы это сократить

А ты предлагаешь к портянки ещё портянку

import api from './service.js api.foo(cb, errorCb)

разделяй запросы от логики сторов

Это оверхед на мой взгляд

ты спросил - я ответил

Ну будет сервис файл в котором запросы которые импортируются потом в экшны

Я спросил как укоротить, реально ли

убрать все запросы на ноду

и дергать с нее 1 запрос

Я спросил как укоротить, реально ли

Глянь на apicase или apipie

А если мне в разном порядке нужно будет что-то? Или что-то отдельно дёрнуть?

это все решения, которые масштабируются удобно

Плодить на ноде обретки запросов?

яндекс так живет

авито так живут

ребят, подскажите, плз. Есть ли в vue/vue-router'e функция, которая на вход принимает объект и возвращает URL строку с параметрами?

яндекс так живет

У них в проде нода есть?

У них в проде нода есть?

а то

А чего они gql не юзают?

У меня пока мысль только убрать запросы из стора

я маркет уже давно на ноде

А сгенерировать модели по сваггер доке

Выглядеть будет красиво

xscript помер в свое время - на ноду ушли

Ну и считай в сервис (модель) унес запрос

ребят, подскажите, плз. Есть ли в vue/vue-router'e функция, которая на вход принимает объект и возвращает URL строку с параметрами?

query builder называется

написать самому - 5 минут)

тебе с какой целью ?

xscript помер в свое время - на ноду ушли

Они там целый кластер из них поддерживают?

Они там целый кластер из них поддерживают?

разрабам такое неизвестно

как это в проде крутится

ребят, подскажите, плз. Есть ли в vue/vue-router'e функция, которая на вход принимает объект и возвращает URL строку с параметрами?

this.$router.resolve({...router_obj}).href

там девопс отдел, который уже архитектурой занимается прода

все под замком)

авито так живут

Авито на своем вело живут

идея таже самая

микросервисы и фасады

Видел из доклад?) "8лет без фреймворков")

написать самому - 5 минут)

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

Видел из доклад?) "8лет без фреймворков")

у меня друзей там много

вполне себе велосипеды

бизнес доволен

сейчас успешно бэк из монолита разносят как раз на микросервисы

У нас вот тоже бек на микросервисы перелезает)

там девопс отдел, который уже архитектурой занимается прода

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

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

URLSearchParams ? С полифилом

this.$router.resolve({...router_obj}).href

Спасибо! Натыкался на эту функцию когда гуглил. Только не могу понять, какой объект на вход туда подать? например, я нахожусь на /foo, надо href /boo?xyz=1. Какой объект туда прокинуть?

думаю как то так {path: '/boo', params:{'xyz':1}}

но вообще зачем, ты же через :to={...obj} это можешь все делать и не писать прямой href в теги

но вообще зачем, ты же через :to={...obj} это можешь все делать и не писать прямой href в теги

{path: 'foo',query: {xyz: 'boo'}} - вот так сработало. Спасибо большое! Надо в новой вкладке открыть просто

ок, как бизнес скажет)

может кто подсказать по данной статейке https://router.vuejs.org/ru/advanced/meta.html у меня всегда вываливается в первый else

код один в один, за исключений наименований путей, вместо /foo стоит /brands

ну и 2ое условие убрал

нашел другой пример, спасибо всем ?

каким образом можно менять App? new Vue({ el: '#app-data', router: router, render: h => h(App) })

new Vue().$mount("#app-data")

извеняюсь, незнаю как правильно задать данный вопрос допустим у нас есть шаблон (где есть шапка, меню и еще чего, + router-view, который меняется при переходах) и есть 2ой шаблон (где нет всего того что есть в первом шаблоне, только один инпут) вот как их можно менять в зависимости от выброного роута