SO
это механизм работы connection pool, как вы верно заметили
Size: a a a
2020 March 16
SO
То есть вы дали своему приложению разрешение на 10 одновременных подключений к постгресу, он их и держит в "горячем" состоянии, чтобы при следующем запросе не тратить накладные расходы на создание подключения
И
А,понял,вопрос именно в том,что каким образом можно указать эти 10 при использовании postgres и psycopg2
SO
А,понял,вопрос именно в том,что каким образом можно указать эти 10 при использовании postgres и psycopg2
VS
Всем привет!
Подскажите пожалуйста по архитектуре
Делаю pet-project из нескольких сервисов, которые должны общаться как друг с другом, так и с клиентом (js)
Как лучше организовать взаимодействие между сервисами (В частности, как лучше делать авторизацию)?
Нормально ли использовать для общения между сервисами json-rpc, а для общения с клиентами - rest api?
Заранее благодарю!
Подскажите пожалуйста по архитектуре
Делаю pet-project из нескольких сервисов, которые должны общаться как друг с другом, так и с клиентом (js)
Как лучше организовать взаимодействие между сервисами (В частности, как лучше делать авторизацию)?
Нормально ли использовать для общения между сервисами json-rpc, а для общения с клиентами - rest api?
Заранее благодарю!
И
если у вас connection pool, и никакая транзакция не выполняется, все соединения будут idle.
Если вы дали 10 соединений для pool, все 10 будут idle
Если вы дали 10 соединений для pool, все 10 будут idle
И ещё один момент, в документации джанги сказано,что если не указывать переменную CONN_MAX_AGE, или установить в None ,то соединения будут закрываться,а получается,что они всё равно висят в idle
AB
Всем привет!
Подскажите пожалуйста по архитектуре
Делаю pet-project из нескольких сервисов, которые должны общаться как друг с другом, так и с клиентом (js)
Как лучше организовать взаимодействие между сервисами (В частности, как лучше делать авторизацию)?
Нормально ли использовать для общения между сервисами json-rpc, а для общения с клиентами - rest api?
Заранее благодарю!
Подскажите пожалуйста по архитектуре
Делаю pet-project из нескольких сервисов, которые должны общаться как друг с другом, так и с клиентом (js)
Как лучше организовать взаимодействие между сервисами (В частности, как лучше делать авторизацию)?
Нормально ли использовать для общения между сервисами json-rpc, а для общения с клиентами - rest api?
Заранее благодарю!
зависит от характера межсервисного общения, нагрузки, и вообще проекта
в целом я бы предпочел rest api везде ( swagger схемы )
или вообще grpc
в целом я бы предпочел rest api везде ( swagger схемы )
или вообще grpc
VS
зависит от характера межсервисного общения, нагрузки, и вообще проекта
в целом я бы предпочел rest api везде ( swagger схемы )
или вообще grpc
в целом я бы предпочел rest api везде ( swagger схемы )
или вообще grpc
🙏
AB
если планируется нагрузка - то только асинхронное взаимодействие через MQ
p
Всем привет!
Подскажите пожалуйста по архитектуре
Делаю pet-project из нескольких сервисов, которые должны общаться как друг с другом, так и с клиентом (js)
Как лучше организовать взаимодействие между сервисами (В частности, как лучше делать авторизацию)?
Нормально ли использовать для общения между сервисами json-rpc, а для общения с клиентами - rest api?
Заранее благодарю!
Подскажите пожалуйста по архитектуре
Делаю pet-project из нескольких сервисов, которые должны общаться как друг с другом, так и с клиентом (js)
Как лучше организовать взаимодействие между сервисами (В частности, как лучше делать авторизацию)?
Нормально ли использовать для общения между сервисами json-rpc, а для общения с клиентами - rest api?
Заранее благодарю!
норм вариант
p
если планируется нагрузка - то только асинхронное взаимодействие через MQ
почему?
AB
почему?
почему что?
p
почему что?
> если планируется нагрузка - то только асинхронное взаимодействие через MQ
почему только этот вариант?
почему только этот вариант?
YV
DI
стебёт npm? )
YV
ага, видимо)
2020 March 17
p
ДК
Можно ли делать функцию в функции?
М
Можно ли делать функцию в функции?
можно