Comments 15
имхо, вам действительно надо научиться системности и структурированию информации, прежде чем писать статьи для кого-то. весь текст это каша из фактов, типа: берем ключ, крутим эту гайку 3.14 оборота, потом протираем фары.
что, зачем, почему.. ни слова. многабукаф листинга это полнейшая шляпа. никому она тут не интересна. для новичков это непонятные символы, для профи это флуд. сворачивайте все в приложение, которе можно скачать. излагайте кратко и по сути. объясняйте свои действия.
всё это нужно если, конечно, даннвя статья не отчет по какой нибудь курсовой.
Бросилось в глаза, что на промисах (из axios), делаете then и await. Чего-то одного было бы вполне достаточно.
Накину критики от человека который учится: Вы пишите "Так конечно же лучше не делать. ", хочется спросить, а как делать? Если уж пишите учебный материал, то пишите сразу как правильно. В любом случае спасибо за материал, постараюсь что-нибудь подчерпнуть.
"Так лучше не делать" относилось к воркеру который складывал готовое изображение, проблема в том, что он запускается из контекста джанги, и собственно имеет доступ к орм. Для отладки это вариант. можно запускать и тестить любые функции и методы напрямую.
Но в данном конкретном случае его лучше было бы отвязать и сделать похожим на второй воркер. А в ещё более идеальном случае надо каждый воркер в отдельный контейнер засунуть) но я все таки решил что жирновато им отдельную жилплощадь)
Хорошая статья, спасибо, не слушайте этих критиков, Вы делаете, они тут "мульку пестрят" от ЧСВ
Кстати собранную статику из докера джанги можно унести в nginx при сборке при помощи docker-toolkit (export опция)
Круто, для boilerplate app вполне годно. Мои предпочтения если бы делал тоже самое, но типа "продукт" :)
1. DRF хорошо, но почему не class based view? в смысле одна view для list/details/etc...?
2. DRF опять таки стоит скрестить с чем то openapi spec подобным. drf-yasg2 (старо) или drf-spectacular (если нужна openapi spec v3).
3. python зависимости стоит сохранять всеж таки - pip freeze по старинке, или pip compile/poetry если хочется быть в тренде
4. react app стоит нынче делать на TS
5. Я бы взял MUI для UI, но это вкусовщина
6. для api calls из frontend удобен rtk query вместо ручного axios/fetch. Пр наличии openapi spec из p.2 вообще можно генератором стабы для frontend генерировать
За то что всё запихали в docker отдельное спасибо, куча людей до сих пор портят/замусоривают себе OS.
О, опубликовали! Я уж думал утонула статья)) Спасибо за советы, я относительно недолго изучаю python и js, и уже тем более не писал статьи никогда, в будущем учту замечания!
Спасибо за статью. Не совсем понял для чего нужно запускать сервер (который на 3000 порту), это вроде как дев сервер?
Note that the development build is not optimized.
To create a production build, use yarn build.
Не лучше ли сделать npm run build реакт приложения, и по пути / джанги, отдавать внутренности папки /build/?
В целом да, это дев сборка, над prod я не думал) надо пилить отдельный compose для такой сборки, но надо ещё покурить подумать) по поводу запуска реакта по пути джанги не понял. В моей голове это два параллельных сервиса на разных портах, но я могу не догонять... Скиньте пожалуйста что нибудь почитать на эту тему?)
А, блин дошёл до дома и дошло о чём Вы:) да, можно сделать билд, но я не пробовал. На dev проще было отлаживать приложение, все изменения сразу были видны онлайн, добавил случайный символ и сразу видать как всё рассыпалось. надо поэкспериментировать с билдом и написать сборку контейнеров для prod)
Статья у Digital Ocean курит в сторонке
React+Django как написать Hello World