Любое приложение, которое можно написать на JavaScript, будет в итоге написано на JavaScript
const createSetAuthInterceptor = options => config => {
if (options.access) {
config.headers.Authorization = options.access;
} else {
delete config.headers.Authorization;
}
return config;
};
const setAuthCb = createSetAuthInterceptor(store.state.auth);
axios.interceptors.request.use(setAuthCb);let refreshTokenPromise;
const createUpdateAuthInterceptor = (store, http) => async error => {
const message = get(error, 'response.data.message');
if (!['Token expired', 'Invalid token'].includes(message)) {
return Promise.reject(error);
}
if (!refreshTokenPromise) {
refreshTokenPromise = store.dispatch('refreshToken');
}
await refreshTokenPromise;
refreshTokenPromise = null;
return http(error.config);
};
const updateAuthCb = createUpdateAuthInterceptor(store, axios);
axios.interceptors.response.use(null, updateAuthCb);
return возращает в скобках html код
render() {
return (
<h1 className="greeting">
Hello, world!
</h1>
);
}render() {
return React.createElement(
'h1',
{ className: 'greeting' },
'Hello, world!'
);
}{
$$typeof: Symbol(react.element),
key: null,
props: { className: "greeting", children: "Hello, world!" },
ref: null,
type: "h1",
_owner: null,
_store: { validated: false },
_self: null,
_source: null,
__proto__: Object,
}
React компилятор перед сборкой парсит данные в файлах компонентов...
...Я понимаю что реакт собирает все в ES2015...
или же это нормально для ES6
Вопрос 1WebSocket работает не поверх голого tcp, а поверх http (а тот уже поверх tcp или tls -> tcp). 80 порт стандартный для http, а 443 - для https (http поверх tls). WebSocket по умолчанию использует те же 80 и 443 порты для ws и wss протоколов соответственно. Но никто не мешает использовать кастомный порт. Конкретные порты для конкретных протоколов - это не более соглашения. Порты работают на IP уровне, который ничего не знает о прикладном уровне.
Браузер инициирует новое tcp соединение на тот же 80 порт сервера или бывают случаи что на другой ?
Вопрос 2Если речь идет о nginx как о реверси прокси, то для него это обычный http запрос, просто клиент очень долго шлет тело запроса, а сервер тело ответа (главное таймауты тут выключить). Так как http в принципе не запрещает серверу начать слать ответ не закончив чтение запроса, все вполне прекрасно работает.
Что сервер делает с ws пакетами - проксирует их к СП как есть в обертке, или же обертку раскрывает и передает "чистые/сырые" данные далее ?
Вопрос 3По http заголовкам. В частности клиент шлет заголовок upgrade в котором говорит, что хочет WebSocket и еще несколько специфичных для WebSocket заголовков, а сервер отвечает статусом 101 и своим набором заголовков. Это и есть WebSocket рукопожатие. Само общение происходит уже в теле запроса и теле ответа.
Как сервер отличает ws от http - по некой сигнатуре - типа по последовательности первых пришедших байт, по которым можно распознать что это именно ws а не http ?
Вопрос 4На уровне tcp вообще пофиг сколько времени открыто соединение, какая из сторон в какой последовательности и сколько данных отправляет. Тут лишь то, что клиент может попробовать открыть соединение, сервер его может принять (или отклонить), а после любая из сторон может слать данные другой или закрыть соединение. Ну и плюс есть гарантии, что потерянные данные будут отправлены повторно и порядок получения совпадет с порядком отправки. На уровне http у нас обычный запрос-ответ, просто клиент слишком долго шлет тело запроса, а сервер - тело ответа. На уровне WebSocket у нас в обе стороны ходят MessageFrame'ы, содержащие данные + метаданные и имеющие четкие границы.
Как эти данные передаются в сторону СП - через переменные окружения, или через unix-socket или через tcp стек?
Если используя последние два варианта, то получается что сервер держит внутри системы соединения с СП до тех пор пока "наружное" tcp соединение между клиентом и сервером не буде закрыто?
Вопрос 5Как реализуете, так и будет. Но одно можно сказать точно, соединение должно быть открытым на протяжении всего сеанса обмена сообщениями.
В свою очередь СП это отдельный unix процесс отличный от основного бекенд приложения, которое работает по принципу "спросили - запустился - обработал - сформировал ответ - отправил - завершился" Или же это все то же бекенд приложение только в том случае если с ним установлено ws-соединение, оно не прекращает свою работу?
return axios.post(`https://api.vk.com/method/${method}`, baseParametres)
.then(answer => answer.request)
.catch(answer => Promise.reject(answer.error))return axios.post(`https://api.vk.com/method/${method}`, baseParametres)
.then(({request}) => request)
.catch(({error}) => Promise.reject(error))
