AO
но, похоже, всё идёт к тому, что этот OpenAPI закопают и всё будет на gRPC
Size: a a a
2019 August 29
V💊
но, похоже, всё идёт к тому, что этот OpenAPI закопают и всё будет на gRPC
ни разу не видел что бы кто-то грпц юзал, в смысле в вакансиях не пишут
V💊
я тут недавно осознал, что же мне не нравится в api domains, там нет связей на уровне базы типа fk, m2m, и т.д. т.е. все что дает джанга осовываясь на этих связя, нужно будет писать самому, типа каскадного удаления, селект/префетч релейтед и т.д.
AO
я тут недавно осознал, что же мне не нравится в api domains, там нет связей на уровне базы типа fk, m2m, и т.д. т.е. все что дает джанга осовываясь на этих связя, нужно будет писать самому, типа каскадного удаления, селект/префетч релейтед и т.д.
ну, API Domains ведёт пользователя к тому, что от Django только кое-где остаётся ORM
AO
это позволяет легко отделить один сервис от лругого и вынести отдельно или на другой фреймворк
V💊
ну, API Domains ведёт пользователя к тому, что от Django только кое-где остаётся ORM
это отлично, но m2m, fk select reldated, etc кажетс все же часть orm, и с таким подходом теряем кучу плюшек ;(
AO
если модели рядом в одном приложении, то тебе никто не запрещает их использовать
AO
а если в разных, ну, да, это стоит заменять на аналогичные поля с UUID
V💊
если модели рядом в одном приложении, то тебе никто не запрещает их использовать
а если нет?) типа аппка пользователей, и аппка статей, разные домены, а связь fk от статьи до юзера. при удалении юзера хочу удалять все его статьи. всё - пиши сам ;(
AO
а если нет?) типа аппка пользователей, и аппка статей, разные домены, а связь fk от статьи до юзера. при удалении юзера хочу удалять все его статьи. всё - пиши сам ;(
зато в будущем будет легче перейти на микросервисы
AO
а разные базы данных можно даже сразу сделать (и роутера к ним)
AO
c Django API Domains ты как бы уже одной ногой в микросервисах
V💊
я пока плохо микросервисы понимаю, для меня сейчас максимум разделения это типа
users+articles, users+banking, users+smth иначе хз как понимать, что у рого, что запросло микросервис есть права что-то в нем делать. поэтому везде юзеры которых надо еще одновременно создать. короче я какую-то боль придумал ;(AO
я пока плохо микросервисы понимаю, для меня сейчас максимум разделения это типа
users+articles, users+banking, users+smth иначе хз как понимать, что у рого, что запросло микросервис есть права что-то в нем делать. поэтому везде юзеры которых надо еще одновременно создать. короче я какую-то боль придумал ;(а что их понимать? был 1 проект, стало 2, но поменьше 😊
V💊
а что их понимать? был 1 проект, стало 2, но поменьше 😊
как гарантировать что у того, что запрашивает сервис естьна это права, кроме как дублировать логику юзера везде?)
AO
для пользователей свой микросервис, там jwt и прочее, когда ему дают jwt, там можно указывать права, микросервисы видят этот jwt и знают, что можно тому или иному пользователю
AO
это если он может к ним на API постучать
V💊
для пользователей свой микросервис, там jwt и прочее, когда ему дают jwt, там можно указывать права, микросервисы видят этот jwt и знают, что можно тому или иному пользователю
т.е. гранаты пишем в payload токена?
AO
ну всё согласно OpenID Connect
AO
и для этого можно использовать какие-нибудь сервисы типа Auth0, чтобы самому не делать