Dejcv2, регистрацию и создания юзера имеет смысл делать в middleware, что бы потом сделать доступным этого юзера в всех хендлерах. А реф удобной отдельной логикой в start, хотя тут тоже может быть вкусовщина и тебе удобно в месте создания юзера.
Если есть код, то проще начать с его анализа, т.е подключить python программистов, которые осилят. Ну и простейший костыль от утечек памяти и подобного, перезапускать сервис раз в N минут/часов/суток
ну т.е ты делаешь, то что пока не понимаешь, и скорее всего первый раз всё будет криво, тут надо позвать в проект, того кто это умеет, а не пытаться решить через этот сайт
Владислав, вообще-то надо начать с теории и практики как это работает в SQL
1. уровень изоляции надо трогать только тогда, когда ты точно понимаешь зачем это нужно, в 99% не трогают
2. select_for_update надо применить для тех записей, которые участвую в конкретной обработке, т.е те которые будут изменены или их значения влияют на изменения
slaver chief, иногда надо что-то тестовое в одного собрать, иногда даже MVP. Ну и проекты, где html рендерится на сервере, всё еще достаточно часто встречаются, да и смешанные не редкость.
Артём Белых, ну postgres обычно не задают пароль, а переключаются на него через sudo, запускают psql и создают юзера для работы через CREATE USER и базу через CREATE DATABASE с этим юзером в OWNER