移动应用网站和服务器API和Cognito [英] Mobile App Website amd server API and cognito
问题描述
相对于通过自己的服务器，建议直接从移动设备向Cognito进行身份验证吗？我认为服务器最好使用cognito进行身份验证，以允许由服务器团队处理的单个端点处理来自android，ios版本的app的身份验证，而不是单独处理它，然后必须处理潜在的更改-以cognito作为身份验证终点。
为什么要在移动应用程序上添加额外的逻辑，而不是将其保留在服务器API中的某个位置？
Is it recommended to authenticate with Cognito directly from mobile device vs going through your own server? I was thinking that it would be preferable for server to authenticate with cognito allowing single end point that is handled by server team to handle authentications from android, ios version of the app vs handling it separately and then have to deal with potential changes-replacement of the cognito as authentication end point. Why add the extra logic on the mobile app vs keeping it in one place in the server API?
推荐答案
在我的公司，我们已经在服务器端编写了所有Cognito内容。
In my company, we have written all cognito stuff at server side. It has following benefits
- 我们不需要阅读android和iOS的sdk文档。
- 我们不需要为每个API（例如API 27、28）版本的兼容性而更新android和iOS sdk。
- 我们将通过避免每个平台的集成sdk来减少开发人员的时间
- 将来，我们可以在AWS Congnito之上创建托管服务来邀请外部服务。就像一种微服务将与另一种微服务通信；
- We do not need to read the sdk document for android and iOS.
- We do not need to update android and iOS sdk for compatibilities of every API (ex API 27, 28 ) release.
- We will reduce developer's time by avoiding integration sdk for each platform
- In future, we can create managed service on top of aws congnito to invite external service. Like one microservice will communicate with another; just consuming API.
我强烈建议您使用该后端。时间就是金钱。没有必要学习每2个月更改一次sdk。是的，软件开发中的变化是不变的。如果是这样，我们必须优先选择不经常更改的框架。
I highly recommend you to do that backend. Time is money. There is no point to learn an sdk will change every 2 months. Ya, change is constant in software development. If so, we have to prefer which framework change in less frequent.
这篇关于移动应用网站和服务器API和Cognito的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
