Давайте разборки в личку, если так хочется

собственно, у меня был вопрос про передачу бинарников на сервак и обратно. люди постебались над base64 решением, но никто не подсказал ничего. или люди сами не знают, но выёбываются. или мб это норма в этом чате

Файлы обычно передаются в POST запросах в multipart body

Это если из браузера

Если нет, то просто в теле

через fetch мне надо

А откуда берутся данные?

картинка после шифрования crypto

в crypto есть метод to base 64 типа того чото

В браузере?

да

Расскажи юсеркейс

напилил такую дичь

Но браузер вечно грузится

Т.е. ответ не возвращаеться

ВТФ

В браузере?

formData - Это не оно?

Нет

не, Blob бери

а, не

даже Blob не надо

не, Blob бери

ну вот я в своё время блобы через формдату посылал

Можно просто ArrayBuffer или ArrayBufferView

Можно просто ArrayBuffer или ArrayBufferView

мерси, покопаю

https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch

Hi, подскажите каким способом легче залить файл ?) есть форм-груп, одна из них должна заливать файл, в папку например, пробывал multi но или не догнал как ей пользоваться в моей ситации или хз)

не файл, а именно картинки только

Dropzone

она работает только с перетаскиванием Img ?)

тоесть без окна выбора img

Как угодно

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

не, я имел ввиду файлы только перетаскивать можно ?)

нету как у input type="file"

кто как версионирует апи?

по семверу же

а с точки зрения кода?

скажем мне нужно сверсионировать конкретный метод в REST API, писать рядом под новую версию?

я сначала подумал ты про API библиотек ну первое что приходит в голову - проверять версию прямо внутри метода но хз, шо-то подсказывает что с таким подходом со временем методы неоправданно растянутся

ну я вот смотрю примеры из оф. доков django-rest-framework, там именно внутри метода версия проверяется

http://www.django-rest-framework.org/api-guide/versioning/

о_О

А для чего это нужно?

чтобы обновлять API, не ломая существующий код

что для чего?

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

Хммм

Не думал что так можно. Спасибо.

я сначала подумал ты про API библиотек ну первое что приходит в голову - проверять версию прямо внутри метода но хз, шо-то подсказывает что с таким подходом со временем методы неоправданно растянутся

Если версий становится много то можно поднимать несколько контейнеров по принципу – 1контейнер = 1тег

Удобно будет фризить разработку старых версий апи и в новом коде не будет старой логики

типа по отдельному инстансу приложения на каждую версию API?

Ну, по крайней мере, на мажорную. Ну а так да, по требованиям. Заодно очень удобно смотреть статистику использования, отделять клиентов etc

Скажем, посмотрели что на /v1/ ходит только один клиент – написали ему лично, пропушили обновиться

ну в принципе звучит логично

Удобно будет фризить разработку старых версий апи и в новом коде не будет старой логики

а критические багфиксы?

с контейнерами идея ок

ну так если я правильно понял, то и фиксишь в старой версии свои багфиксы, а новые это никак не затрагивает

есть багфиксы котоыре могут вылезти и на старой версии и на новой

ERROR: S client not available

и тебе нужно в обоих местах это исправить

скажем там дырка, чтобы данные не утекли

а критические багфиксы?

Это минорный апдейт или патч. Они не касаются мажорной версии. То есть поправил минор, залил обновления, раскатал актуальные мажорные с фиксом, обратная совместимость не страдает

т.е контейнеры на минорные версии делать?

ну да, контейнеры по semver :)

При необходимости можно, но я описал другое

ну например /v2.1/some/func

по /v1/ раздается последняя мажорная версия, в терминах npm это версия 1. Соответственно если ты зарелизил 1.0.1 то теперь /v1/ указывает на 1.0.1 а не на 1.0.0

можно и минорные вынести в отдельные инстансы, но все же по семверу все, что ломает совместимость – это мажорные релизы

Что применительно к апи обычно означает что для апи достаточно разделять только на мажорные версии

По вопросу, чтобы составить свое мнение, полезно ознакомиться с первыми двумя ответами тут: https://stackoverflow.com/questions/389169/best-practices-for-api-versioning второй хорошо дополняет первый (как информация к размышлению)

денис хватит бухать

оу...сори...

сообщения можно удалять, попробуй

есть ли еще такие каналы для разрабов!?

что лучше для кэша varnish или редис?

что лучше для кэша varnish или редис?

так это совсем разные кеши

а если более подробно?

varhish - это http-кэш, а redis - k/v-хранилище

varnish - это мощный кэширующий прокси по сути

например для данных которые берешь с дб например посты в каком из двоих лучше хранить redis не так?

но можно и через http под гет запросом

например для данных которые берешь с дб например посты в каком из двоих лучше хранить redis не так?

да, тебе подойдет redis

varnish совсем про другое

ну или если интересно почитай про более сложное и эффективное - nginx + tarantool

Не надо тарантул Мемкеш- если нужна надёжность и ничего сложного

Редис- если любишь настраивать

Не надо тарантул Мемкеш- если нужна надёжность и ничего сложного

почему не надо?)