Обновить
-6

Пользователь

Отправить сообщение

Тема не раскрыта. Хотя и очень интересная. Так как большому количеству проектов походит вариант глупого бэка, и оптимизации некоторых процессов в далёком будущем когда бизнес вырастет.

Дайте больше конкретики по strapi. Есть ли поддержка:

  • Авторизации/аутентификации

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

  • Хранения схемы БД под git, а не только UI редактор

  • Миграций БД (захотели переименовать поле, или превратить айдишник из числа в строку)

  • Деплоя в Serverless

Сколько кода нужно писать? Как сложно добавить новую сущность или изменить старую (сколько кода и кликов мышкой)?

Как по мне война между разработчиками и девопсами возникает из-за низкой квалификации последних. Хорошие девопсы, это программисты, которые постигли SDLC, CI/CD, Cloud, IaaC практики. Плохие девопсы, это неучи после курсов, либо сисадмины не имеющие никакого представления о разработке ПО.

Виртуальные окружения, инфраструктура как код (императивный код высокого уровня, а не yml или скрипты на баше), удобные и стандартизированные на всю компанию инструменты для логгирования, конфигурирования и отладки -- вот секрет успеха и быстрой разработки.

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

О чем речь если никто не может сказать, что же входит в обязанности девопса? Зачастую, особенно на out-stuff проектах, наличие девопсов только создает проблемы, так как опытные разработчики сами могут все настроить, но у них нет доступов.

Для меня девопс, это эксперт не только по развертыванию ПО, но и по автоматизации развертывания. Это автоматизация должна быть гибкой и простой настолько, что любой разработчик в команде, будет способен легко из шаблонов создать новый микросервис и задеплоить его в дев-окружение. Но как показывает практика, хороших спецов можно встретить крайне редко.

No Code - это негибко. Зачастую, проще написать какую-нибудь библиотеку, покрыть её тестами. а потом реализовывать бизнес требования в пару строк кода. Бизнес пользователи генерирующие бизнес правила, должны четко ставить задачу. А программист быстро превращать это в код.

А ещё можно обучить непрограммистов формату json (некоторым конструкциям js, markdown в зависимости от задачи) и писать конфиги на нем. Можно даже написать инструмент который визуализирует эту json-конфигурацию (проще чем писать визуальный редактор). Главное, что бы ядром был исходный текст.

И вот когда все работают с исходным текстом, то нахаляву получается много возможностей: контроль версий и аудит (git), возможность совместной работы (любые совместные редукторы кода или библиотеки для организации этой работы, проще чем писать с нуля для своей UI-тулы).

Это киллер фича, которая обязывает инициализировать указанные свойства в DTO.

Казалось бы есть конструктор для этого, но систаксис с инициализатором свойств намного удобнее. Это ещё один шаг в борьбе с NullReferreceException.

https://github.com/dotnet/csharplang/blob/main/proposals/required-members.md

https://github.com/dotnet/csharplang/issues/3630

И в догонку Simplified parameters null validation. Которое гарантирует null-безапасность и пишет бойлерплейт за вас.

// Before
void Insert(string s) {
  if (s is null)
    throw new ArgumentNullException(nameof(s));
  ...
}

// After
void Insert(string s!) {
  ...
}

https://github.com/dotnet/csharplang/issues/2145

Required properties не добавили, расходимся.

Идея и реализация замечательная. Однако не работает на Android Firefox с тачем. Наверняка нужно подписать на какие-то touch-события вдобавок к событиям мыши.

Я рекомендую ShareX

12 ...
13

Информация

В рейтинге
4 468-й
Зарегистрирован
Активность