Правда что >80% работы backend'а — это «пилить» CRUD-API?

Question

[Стас]

Наблюдая за собой и за коллегами, заметил что каждый проект идет по одному и тому же сценарию:

• создали модели;
  
• написали к ним тесты;
  
• написали CRUD-контроллеры на каждую модель (принять данные; подключится к БД через ORM; отрендерить json);
  
• написали к ним тесты;
  
• перешли к новому проекту;
  

Конечно бывают более интересные задачи типа:
написать воркер отложенных задач; написать скрипт агрегирования данных; настроить морфологический или префиксный поиск; оптимизировать работу эндпоинта с целью уменьшить время ответа; оптимизировать работу какого-либо скрипта; etc;
Но их количество не большое в каждом проекте.

Интересуюсь опытом коллег. Правда ли это или мир backend разработки более разнообразный?

Comments

[Александр]

80% backend - это править баги

[Максим Федоров]

заметил что каждый проект идет

Ну если все проекты у вас CRUD, то у вас все проекты CRUD :) Кто же виноват, что вы в веб-студии работаете :)

[Толстый Лорри]

В вебе - зачастую это так, потому как в большинстве своем бэкенд там лишь валидирует модели и обеспечивает персистентность.
А в интерпрайзе картина отличается кардинально.

[Стас]

Толстый Лорри, можно подробнее про интерпрайз?

[Толстый Лорри]

Стас, всякие комплексные информационные системы для предприятий. Зачастую это не такой кучерявый интерфейс, а основной фокус на обработке данных. Например - ERP, CRM системы, так или иначе автоматизирующие бизнес-процессы предприятий. Там, как правило, развесистая система прав/ролей, различные интерфейсы для юзеров, кучи взаимодействующих подсистем, очереди и фоновые сервисы со всякими нотификациями и правилами, аналитическими инструментами и аудитом. Непосредственно веб там поедставляет из себя уровень представления и способ коммуникации. Эти системы могут жить и эволюционировать десятки лет, поэтому там ценится высокая надежность и поддерживаемость, особенно в том, что касается дешежных операций (банковская сфера, например).

Answer 1

[d-stream]

Черновая часть бизнес-логики опирается на взаимодействие моделей, которые как правило должны обладать нечто типа CRUD. Зачастую там немало кодописательства, особенно при наличии различных верификаций, поэтому их написание заметно по затраченному времени, а самые изюминки - они чуть раньше (архитектура) и чуть позже (взаимодействие, поведение), но малозаметны именно за счет хорошо подготовленного фундамента в виде оттестированных "кирпичиков".

Answer 2

[Владимир Куц]

создали модели;
написали к ним тесты;
написали CRUD-контроллеры на каждую модель (принять данные; подключится к БД через ORM; отрендерить json);
написали к ним тесты;
перешли к новому проекту;

Если контора клепает пачками однотипные сайты без какой-либо сложной логики, интеграций и особых требований - то данный процесс - норм.
На более сложных проектах бекендерами решается гораздо более широкий спектр задач.

Comments

[Стас]

Можно, пожалуйста, подробнее про спектр задач и примеры.

[Владимир Куц]

Стас, Пожалуйста - несколько из недавних проектов навскидку:
- платежная система: Интеграция с внешними платежными агрегаторами, шифрование, вопросы безопасности и защиты данных
- система автоматизации для обработки сообщений с ЦБР - вопросы шифрования/дешифрования, интеграции с различными банковскими системами, финансовая аналитика и различная банковская математика
- система работы с билингами: программирование на уровне протоколов общения с железом, интеграция с VoIP, мобильными сервисами - Apple APNS/Google Cloud messaging, платежными агрегаторами
- агрегация данных и обработка ОЧЕНЬ большого количества данных китайского провайдера - вопросы распараллеливания обработки, оптимизации, хранения и обработки больших данных
- часть системы документооборота - оптическое распознавание и обработка изображений, классификация документов с использованием нейронных сетей
- система для автоматизации работы теплиц - написание софта для работы с датчиками и управляющими механизмами, создание облачного сервиса для сбора данных
- автоматизированная система для МЧС - обработка спутниковых снимков, реализация мат модели распознавания очагов пожаров на снимках, создание распределенной системы оповещения и сбора данных
- рабочее место сотрудника техподдержки - сбор и агрегация различного рода метрик с разного рода устройств по протоколам snmp, ssh, и прочим.
- система работы с тендерами - парсинг и обработка данных со множества ресурсов - по протоколам https/ftp разнородных данных - html/xml/json, реализация нечеткого поиска
- рабочее место сотрудника IT-безопасности - хранение, парсинг, анализ дампов PCAP, различная аналитика

и т.п.

Answer 3

[timur14]

Если нравятся интересные задачи, то я думаю таковые вы найдете на более нагруженных проектах, где и архитектура приложения гораздо сложнее. Например, где и как хранить данные (реляционное или nosql решение), каким образом масштабировать систему, как и какую часть системы выносить в отдельный сервис и как организовать взаимодействие между сервисами, оптимизация тех же sql запросов, профилирование и нагрузочное тестирование, применение асинхронного подхода. И это только для любого нагруженного проекта, а если при этом довольно интересная предметная область ?!

Answer 4

[Артем]

Нет, это не так. CRUD - это очень маленький пласт задач. Так повелось, что бизнес-логика в подавляющем большинстве случаев выходит за рамки crud, поэтому и задач там больше

Answer 5

[TheAthlete]

На современном проекте, где есть SPA-приложение на React/Vue/Angular, да, бекенд нужен чтобы гонять JSON клиенту/от клиента

Т.е. многое переместилось на фронт

Comments

[Стас]

У нас на фронте логика минимальная: получить json; вставить его на страницу; отправить json на сервер; получить положительный ответ; либо получить массив ошибок валидаций и отобразить их.