И где брать библиотеки, например, для React и Angular для работы с флоу в данной статье?
Для мобилы (Android/iOS) тоже есть ряд стандартных библиотек для Authorization Code Flow, т.е. вопрос тоже открытый как работать с мобилы с таким API Gateway.
Если подытожить, зачем что-то менять, если и так всё хорошо работает будь то API Gateway, BFF или просто API (для клиента это только детали реализации)?
OAuth — это протокол авторизации, а не аутентификации (https://ru.wikipedia.org/wiki/OAuth), а вот OpenID Connect — это протокол аутентификации по верх протокола авторизации (такая вот чехарда), т.к. наличие клэймов в JWT-токене (конкретно в id_token) гарантирует только само наличие, а вот автрозизацией уже будет заниматься приложение доверяющее, например, списку ролей в клэймах
«Вы не любите кошек? Да вы просто не умеете их готовить!»
Заметил такую особенность в своём коде — почти все поля классов readonly, за исключением классов для данных.
Как-то само собой стало так получатся, может поэтому нет проблем про которые пишет автор?
Если нужно организовать in-memory DB использую разделяемые списки, как я понимаю чистое ФП этого не может, а вот мне надо.
Так что ООП никуда не денется.
Нужно сочетать OOP и COP, не хочешь вникать в устройство класса и наследоваться, считай его компонентом.
Иногда лень писать шаблонные методы, пользуюсь копипастом, но я с этим борюсь, в случае с ФП копипаста было бы намного больше.
А меня WCF полностью устраивает, но в качестве сериализатора лучше использовать ProtoBuf (https://habrahabr.ru/post/119510/), тогда проигрыш перед Thrift будет меньше.
А чем это лучше стандартной реализации Authorization Code Flow - https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow ?
И где брать библиотеки, например, для React и Angular для работы с флоу в данной статье?
Для мобилы (Android/iOS) тоже есть ряд стандартных библиотек для Authorization Code Flow, т.е. вопрос тоже открытый как работать с мобилы с таким API Gateway.
Если подытожить, зачем что-то менять, если и так всё хорошо работает будь то API Gateway, BFF или просто API (для клиента это только детали реализации)?
Заметил такую особенность в своём коде — почти все поля классов readonly, за исключением классов для данных.
Как-то само собой стало так получатся, может поэтому нет проблем про которые пишет автор?
Если нужно организовать in-memory DB использую разделяемые списки, как я понимаю чистое ФП этого не может, а вот мне надо.
Так что ООП никуда не денется.
Иногда лень писать шаблонные методы, пользуюсь копипастом, но я с этим борюсь, в случае с ФП копипаста было бы намного больше.