Спасибо за статью. И материал хороший и идея здравая.
И да, это конечно велосипед... мы же называем так новое решение проблемы для которой уже есть старое.
Но хорошо ли это старое решение - вот вопрос. Требования в confluence, задача в jira (условно), комменты в коде... Не претендую на истину, но лично меня этот веб-сёрфинг не радует совершенно.
Идея все держать в одном месте и совместно версионировать - напротив, очень привлекательна. В "традиционной" разработке она правда часто разбивается обо что-то типа "ой, не хочу я в этот ваш гит".
Но современная разработка с агентами (не путать с вайб-кодингом) открывает совершенно новые возможности, и нам конечно надо искать новые решения старых проблем.
Так что не слушайте никого, дорогой зумер. Исследуйте, изобретайте - что-то взлетит, что-то нет, жизнь покажет.
На мой взгляд, ltree вполне себе unix-way штука, которая решает узкую задачу - удобная и быстрая работа с materialized path. Я с ним познакомился вот по этой серии статей: https://patshaughnessy.net/2017/12/12/installing-the-postgres-ltree-extension и использовал в несколько проектов, в том числе с приличной нагрузкой.
То, что в ней не решается вопрос целостности данных - это тоже вполне себе unix-way. Мы же не обламываемся написать `curl ... | jq` и не говорим, что разработчики curl недоделали свою работу, потому что у них нет встроенного форматирования json?
Его не существует в таблице, но он ведь появляется в той же транзакции, что и materialized path. И соответственно, его можно проконтролировать. Например, тем же триггером.
Ну, на счет возврата ошибки с кодом 200 — это прям совсем не к фреймворку. Я знаю, так делают, хотя лично по мне это не очень естественно. А что касается, как возвращать… на мой взгляд два варианта оправданных: кидание эксепшенов и возврат ответа из фильтра, либо возврат обертки (Either, Result) из контроллера, а там уже в интерцепторах решать дальше.
Таких вещей, как соглашение в части строки message или прямой работы с Response, я бы избегал
Спасибо за статью. И материал хороший и идея здравая.
И да, это конечно велосипед... мы же называем так новое решение проблемы для которой уже есть старое.
Но хорошо ли это старое решение - вот вопрос. Требования в confluence, задача в jira (условно), комменты в коде... Не претендую на истину, но лично меня этот веб-сёрфинг не радует совершенно.
Идея все держать в одном месте и совместно версионировать - напротив, очень привлекательна. В "традиционной" разработке она правда часто разбивается обо что-то типа "ой, не хочу я в этот ваш гит".
Но современная разработка с агентами (не путать с вайб-кодингом) открывает совершенно новые возможности, и нам конечно надо искать новые решения старых проблем.
Так что не слушайте никого, дорогой зумер. Исследуйте, изобретайте - что-то взлетит, что-то нет, жизнь покажет.
Привет вам от миллениала!
P. S.
https://github.com/vanzan01/cursor-memory-bank - смотрели? Тут есть похожие идеи
На мой взгляд, ltree вполне себе unix-way штука, которая решает узкую задачу - удобная и быстрая работа с materialized path. Я с ним познакомился вот по этой серии статей: https://patshaughnessy.net/2017/12/12/installing-the-postgres-ltree-extension и использовал в несколько проектов, в том числе с приличной нагрузкой.
То, что в ней не решается вопрос целостности данных - это тоже вполне себе unix-way. Мы же не обламываемся написать `curl ... | jq` и не говорим, что разработчики curl недоделали свою работу, потому что у них нет встроенного форматирования json?
А статья в целом полезная.
Его не существует в таблице, но он ведь появляется в той же транзакции, что и materialized path. И соответственно, его можно проконтролировать. Например, тем же триггером.
вышел )
Несмотря на спорные моменты, очень дельная статья. Мне нехватило sequence-диаграммы
Очень много крайне спорных (хотяи интересных) утверждений. Но за поинт про фальшивый порядок - аплодирую стоя! Как же это верно...
Речь ведь идет не о бизнес-логике, а об инфраструктурной. А её-то как раз от бизнесовой имеет смысл отделять
Ну, на счет возврата ошибки с кодом 200 — это прям совсем не к фреймворку. Я знаю, так делают, хотя лично по мне это не очень естественно. А что касается, как возвращать… на мой взгляд два варианта оправданных: кидание эксепшенов и возврат ответа из фильтра, либо возврат обертки (Either, Result) из контроллера, а там уже в интерцепторах решать дальше.
Таких вещей, как соглашение в части строки message или прямой работы с Response, я бы избегал