我希望将Meteor作为服务器，将Ionic2作为客户端。我目前对认证有头疼。似乎有两种不同的方法：
ionic-angular库的Meteor服务器和Meteor客户端。这种方法在这里描述https://angular-meteor.com/tutorials/socially/angular2/ionic2
我猜这种方法的优点是使用Meteor本机架构，另一方面我猜我们正在使用Ionic2就像子帧一样，可能会从本机Ionic2中丢失一些东西。
https://angular-meteor.com/tutorials/whatsapp2/ionic/authentication
此选项反之亦然：使用原生Ionic2，但它必须使用meteor-client-side，accounts-base-client-side，accounts-password-client-side等库，我不确定它们是Meteor的原生
第一种方法看起来更好，因为有一个即用型UI组件可用于身份验证。但我想知道当我完成不同类型设备的应用程序的步骤时，我会遇到什么问题。
提前感谢您的帮助。
答案 0 :(得分：1)
这些方法对于身份验证本身基本相同。 您所指出的更多是关于选择开发和运行移动项目的移动平台。
在第一种情况下，您使用Meteor的内置Cordova平台来运行应用程序和Meteor的编译器和捆绑器插件（如TypeScript包或Babel和UglifyJS的Meteor核心包等）来开发应用程序。在第二种情况下，您只能在Ionic 2 CLI上开发和运行应用程序。
但是从应用程序逻辑的角度来看，这些方法是完全相同的：你导入相同的Ionic 2组件并使用相同的Meteor软件包，唯一的区别在于第二种情况是这些软件包现在是NPM而不是大气层（基本上）虽然它们包含相同的脚本，因为这些NPM是从Atmosphere包构建的。）
之所以使用与Socially不同的方式构建What'sApp克隆的原因，只需在README中自述 What'sApp仓库（见https://github.com/Urigo/Ionic2CLI-Meteor-WhatsApp）。如果重复：由于Ionic是专门用于构建移动应用程序的最佳Web框架之一，因此可以合理地猜测它构建它们（并且可能是）比Meteor本身更强大。从这个角度来看，第二种方法似乎更具有前瞻性，我想说。您甚至可以考虑以某种方式构建项目，如果您决定在将来某个时候使用它，可以轻松地将Meteor替换为另一个框架。
如果您担心使用第二种情况中提到的NPM（例如，如果构建它们的过程对您来说看起来不透明），您可以尝试使用此项目https://github.com/Urigo/meteor-client-bundler来捆绑Atmosphere包需要进入单独的脚本并在之后使用它们。