@nodejs_ru - страница 916 - Telegram web archive

Vladimir

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

ixplo

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

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

Vladimir

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

sanqa

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

sanqa

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

Anonymous

Dropzone

sanqa

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

sanqa

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

Anonymous

Как угодно

Anonymous

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

sanqa

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

sanqa

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

Nikolay

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

доня.

по семверу же

Nikolay

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

Nikolay

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

доня.

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

доня.

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

доня.

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

Lev

о_О

Lev

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

доня.

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

Nikolay

что для чего?

Nikolay

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

Lev

Хммм

Lev

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

파쇼크

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

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

파쇼크

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

доня.

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

파쇼크

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

파쇼크

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

доня.

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

Nikolay

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

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

Nikolay

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

доня.

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

Nikolay

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

Nikolay

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

Nikolay

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

파쇼크

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

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

Nikolay

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

Nikolay

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

파쇼크

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

Nikolay

ну например /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 второй хорошо дополняет первый (как информация к размышлению)