uni-app中uni-admin跟项目之间不同一个云服务空间的问题
uni-app中uni-admin跟项目之间不同一个云服务空间的问题
如何实现uni-admin与项目间不同云服务空间的问题
请问如何实现uni-admin跟项目之间不同一个云服务空间的问题，比如我uni-admin添加了多个应用的升级，但是在A应用如何实现读取升级的通知。如果uni-admin跟项目也在同一个云空间会造成很多问题，而且在插件之间会有很多冲突，简直要疯掉。
建议新手或者正在入手uni-app的同学们，建议换地，这个框架不能说垃圾，但是问题很多，这个框架不够灵活，很死板，而且官方开发的插件，各种膈应人，完全就没有拿来即用的，从七月份到现在，一个完整的项目都没上线，每天除了踩坑，没有其他的办法，所有的坑都得踩一遍，看着整体的思路的是高效，但是开发中，除了浪费时间，不能用其他词形容。
| 开发环境 | 版本号 | 项目创建方式 |
|----------|--------|--------------|
| uni-app | 不详 | 不详 |
更多关于uni-app中uni-admin跟项目之间不同一个云服务空间的问题的实战教程也可以访问 https://www.itying.com/category-93-b0.html
你这个需求建议使用同一个服务空间，uni-id也是支持不同应用的用户隔离的。
更多关于uni-app中uni-admin跟项目之间不同一个云服务空间的问题的实战教程也可以访问 https://www.itying.com/category-93-b0.html
如果前端App和uni-admin绑定同一个服务空间，则前端App可以通过callFunction的方式读取升级中心。
如果前端App和uni-admin绑定不同服务空间，则前端App无法使用callFunction，但可以通过云函数url化的方式请求升级中心云函数，从而获取升级提示信息。
在uni-id的设计里，是应该使用同一个服务空间，uni-id也是支持不同应用的用户隔离的，uni-id-user表里有app字段，uni-admin的应用管理也是指这个。
如果你说放在同一个服务空间有什么其他问题，请提出来。
uni-app也好，uniCloud也好，都已经有非常多项目上线了。有问题好好问，欢迎客观交流
确实坑较多，很多新东西想法是好的但是要踩很多坑才能用上它的方便，建议官方学习一些优秀工具的设计思路，可不可以专门设一个开发用户体验栏目，把用户觉得好的不好的都公示收集起来，共同完善这个工具
有后端经验的，不建议使用uni现有的前端开源库，可以摸索熟悉后，自已写，很多东西看着复杂，其实也很简单，用他们写的前端，bug很多，思路也不符合自已，他们的前端开源库，实现起来的思路还是一个后端程序员思维，没有精益求精，细节没有面面俱到。
