Василий Назаров, сейчас просто гребень волны под названием "войтивайти". А входить проще на простых инструментах (можно быстрее освоить - и начать клепать) - отсюда и растущая популярность той же MongoDB или Vue в случае с фронтендом. Это вообще ничего не значит, увы, в долгосрочной перспективе. Как вы видите, популярность той же JAVA падает, но никто в здравом уме не начнёт внезапно пилить интерпрайз, скажем, на NodeJS (при том, что NodeJS активно набирает популярность). А знаете, почему? Потому что "2" + 3 в js даже ошибку не кинет. То есть хайп вокруг фреймворка/технологии мало о чём говорит, на самом деле.
Василий Назаров, ой, вот не надо передёргивать) Я написал "фреймворк, популярный, в основном, у джунов с опытом разработки 2-4 года". В основном - означает "в основном", а не что-то ещё. По-моему, странно спорить с тем, что среди Angular/React/Vue именно у Vue наиболее низкий порог вхождения, поэтому новички обычно и отдают ему предпочтение.
Сергей Горностаев, я просто мимо проходил, но меня примерно схожий вопрос интересует: скажите, пожалуйста, а принимать какие-то суммы на сайте, не имея ИП, можно? Ну, со статусом самозанятого, скажем.
Василий Назаров, если речь идёт о "беспощадном интерпрайзе", то "монструозная" архитектура обычно никого не смущает. Поэтому в бэкенде, например, JAVA до сих пор и используется. Насчёт "Vue при этом весит в 10 раз меньше" - это смешно. Возьмите не вес отдельного фреймворка в вакууме, а бандл реального приложения (особенно с учётом gzip). Разница будет копеечная. "собственно, если вы его даже не пробовали" чтобы о чём-то судить, надо обязательно попробовать? Это работает далеко не везде и не всегда. Лично я не вижу смысла тратить время на фреймворк, популярный, в основном, у джунов с опытом разработки 2-4 года.
Вчера тыкал Angular, после React (4 года React использую) - огонь просто. Все проекты на React - это велосипеды. Потому что в каждой конторе пишут по-своему, ведь React - библиотека, а не фреймворк. После такого Angular - это глоток свежего воздуха просто.
Роман Сарваров, скорее всего, на таких маленьких объёмах MySQL не будет использовать индекс, даже если вы его создадите. Вообще индексы нужно создавать тогда, когда нужно, либо тогда, когда вы 100% уверены, что он нужен и должен быть именно таким. Для того, чтобы понять, нужен ли индекс, есть оператор EXPLAIN.
Сергей Еремин, т.е., по-вашему, если в базе содержатся дубли по некоторым (не по всем, конечно), то это криво спроектированная БД? Странное утверждение.
Тю Вячеслав, задача простая: в бэкенде в респонсе отдавайте нужные CORS-заголовки и всё. Для этого не нужно быть крутым бэкенд-разработчиком. Тем более, что многие фреймворки это поддерживают либо из коробки, либо имеют для этого официальные плагины. Это самое правильное и самое простое решение. То, что вы хотите сделать - это костыль. Причём это ж прокси, т.е. опять-таки запрос будет идти через сервер. То есть, если вернуться к вопросу: нет, костылить так, как вы хотите, точно не стоит.
Сергей Еремин, это всё отдельная тема для дискуссий. Я Django не сильно люблю, но тут потребовалось. ORM разные вообще бывают: та же Doctrine или TypeORM сильно более гибкие (если query builder юзать), но речь не об этом. Я бы с удовольствием отказался тут от ORM, но дело в том, что тут есть всякие фильтры и сортировки (которые могут быть, а могут не быть) - и очень не хочется raw-запрос в виде строки по кусочкам конкатенировать в if-условиях.
Насчёт "лучше" - не согласен. Почему - написал в комментариях под своим ответом. :)
Единственный плюс написания вручную - это то, что не надо разбираться с аннотациями этой библиотеки. Но минусы, на мой взгляд, сильно более весомые, особенно когда эндпоинтов становится много.
Sergey Ilichev, "Тоже думаю, что наверно проще написать в swagger editor документацию и положить в swagger ui." - я выше писал, что так делал - уже ушёл от этого.
Во-первых, по мере роста проекта этот файл становится просто огромным - и в нём сложно ориентироваться.
Во-вторых, постоянно начинаются расхождения между этим файлом и валидаторами/сериализаторами в коде
В-третьих, при использовании этой библиотеки схемы можно держать прямо рядом с моделями и валидаторами - это уменьшает вероятность расхождений