作者darrenlee1 (darrenleeleelee)
看板Python
标题[问题] IOS App前端想用Python写後端
时间Tue Oct 13 23:23:59 2020
不好意思，对於写app还处於一个菜鸟的阶段，想请问有没有一个比较明确的方向该如何
让iOS的前端（用Swift去写的）去连结Python的code来做一些後端的处理（要用到Django
或Flask都没问题）上网查都没什麽方向？
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.71.35.160 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Python/M.1602602641.A.702.html
1F：→ jackjenny: API 後端10/13 23:37
2F：→ darrenlee1: 是要自己写api吗10/13 23:42
3F：→ mirror0227: 是啊，後端开API（一般来说是一个server，用URI沟通10/14 00:28
4F：→ mirror0227: ）给前端去call，送资料回前端，前端再做呈现10/14 00:28
5F：→ darrenlee1: 所以不管是用什麽後端都能自己写api连到吗10/14 01:56
6F：→ hongyan: 框架的话，fastapi可以去尝试看看，很快速就能建立一个10/14 09:20
7F：→ hongyan: API10/14 09:20
8F：→ hongyan: 前端call api，後端do somthings後再回传资料到前端呈现10/14 09:22
9F：→ darrenlee1: 用框架会比较好吗，还是是看习惯10/14 11:02
10F：→ Hsins: 看规模跟用途，小规模用 fastapk 或 flask 就可以，至於 dj10/14 14:38
11F：→ Hsins: ango 有点太庞大了10/14 14:38
12F：推 aidansky0989: Django会自带ORM、自动生成路由，大型项目中你会爱10/14 15:14
13F：→ aidansky0989: 死这项功能，但是构建简易API你会需要Fastapi和SQLA10/14 15:14
14F：→ aidansky0989: lchemy，你会很常用它内建的神器，爱上它接近Go的10/14 15:14
15F：→ aidansky0989: 高效能，至於Flask就是时代眼泪别花太多时间10/14 15:14
16F：推 single4565: 那Flask还适合建构小型网站吗？最近想学 10/14 20:26
17F：推 yangs0618: 想知道为什麽flask不行了 10/14 22:02
18F：推 ToastBen: 推10楼，看规模和需求决定，Flask也是有适合的用途10/14 22:54
19F：→ darrenlee1: 谢谢大家我去研究一下fastapi10/15 08:12
20F：推 TakiDog: falcon / hug 我也觉得不错10/15 09:11
21F：推 TuCH: 推fastapi 最近发现fastapi 直接舍弃flask10/15 13:44
22F：推 laputaflutin: 除非你有很大流量的需求，不然那些说flask不行的看10/16 04:27
23F：→ laputaflutin: 看就好，效能是良好的架构与良好的code撑起来的，10/16 04:27
24F：→ laputaflutin: 不是跑分好高好棒棒来的10/16 04:27
25F：→ laputaflutin: flask从0.x到1.0历经八年，django也十多年才到2.010/16 04:41
26F：→ laputaflutin: 能遇到的坑几乎都遇到过了，也都有庞大社群、书籍10/16 04:41
27F：→ laputaflutin: 与线上资料，学来没什麽不好的10/16 04:41
28F：推 TuCH: 如果要做网页 flask django 是没什麽问题 但他们原本设计的10/16 13:05
29F：→ TuCH: 初衷就不是for 设计api 导致要用很多模组 还需要整合10/16 13:06
30F：→ TuCH: fastapi 实现了大部分api需要整合的东西 可以提昇开发效率10/16 13:08
31F：→ Hsins: flask 很适合拿来做微服务10/16 13:41
32F：→ laputaflutin: DRF: 原来我还整合的不够...10/16 21:02
33F：推 Hsins: DRF 就杀鸡焉用牛刀的概念啊…10/16 21:47
34F：推 laputaflutin: 楼上，我回覆的是tuch关於整合的说法10/16 21:53
35F：推 laputaflutin: fastapi最大的特点在於基於asyncio稳定的基础上10/16 21:57
36F：→ laputaflutin: 能达到以往做不到的high concurrency10/16 22:04
37F：→ laputaflutin: 然後orelly有出版一本轻量化django, 它也可以很轻10/16 22:09
38F：推 froce: DRF光看文件的时间，fastapi搞不好已经写完了还更快。XD 10/17 08:02
39F：推 froce: 我个人的经验是觉得，如果你是初学者，用django或flask打底 10/17 08:29
40F：→ froce: 都很好，尤其是flask因为简单，可以帮助你很快理解web fram10/17 08:29
41F：→ froce: ework怎麽用。10/17 08:29
42F：→ froce: 但实际生产上面，如果你的专案是标准的前後端MTV项目，djan10/17 08:29
43F：→ froce: go的整合可以带给你很好的开发体验，好用的ORM和完整的功能10/17 08:29
44F：→ froce: ，自带帐号後台很方便。10/17 08:29
45F：→ froce: 可是到了api时代和微服务时代，你用django+DRF已经略显疲态10/17 08:29
46F：→ froce: 了，首先DRF你要弄到会用就是个问题，那个文件就算是中文版10/17 08:29
47F：→ froce: 还是没有fastapi简单明快，fastapi基本上是你看到范例code10/17 08:29
48F：→ froce: 你就会了。第二，有些时候你得深挖DRF去覆写他的功能，但是10/17 08:29
49F：→ froce: 这得去自己看原始码。像我之前写了用ad去做认证，就得自己10/17 08:29
50F：→ froce: 想办法，第三，有些时候你还是会觉得不如直接用django的jso10/17 08:29
51F：→ froce: nresponse去吐资料比较方便，反而DRF你只需要他的序列化资10/17 08:29
52F：→ froce: 料而已。10/17 08:29
53F：→ laputaflutin: 基本上大而全跟小而美本来就侧重面向就不同，我同意10/17 14:13
54F：→ laputaflutin: 楼上讲的大部分观点，提DRF纯粹是针对先前hs提到整10/17 14:13
55F：→ laputaflutin: 合的观点，要快要简单本来就是找轻量级框架10/17 14:14
56F：→ laputaflutin: 要用fastapi也没什麽不好，然而如果同时要用async10/17 14:16
57F：→ laputaflutin: 跟 sqlalchemy, 要注意後者的asyncio支援还不稳定10/17 14:17
58F：→ laputaflutin: py 跟 js 不同，整体生态系对於async的支援并没有10/17 14:18
59F：→ laputaflutin: 那麽成熟，使用async api要注意第三方函式是否支援10/17 14:21
60F：→ laputaflutin: 你可能以为你在写非同步，其实程式还是同步跑 10/17 14:32
61F：推 Sunal: 同意楼上，所有IO都要换成非同步版本 file, logging 都有 10/18 21:29
62F：→ Sunal: 对应的aio版本，ORM好像还没有吧？10/18 21:29
63F：→ Sunal: 就连django3也都说目前ORM还无法做到全面aio10/18 21:31
64F：→ darrenlee1: 不好意思问一下 有人知道如何用fastapi的uploadfile10/19 22:42
65F：→ darrenlee1: 从post拿到照片吗10/19 22:42
66F：→ Hsins: 你要说一下卡在哪吧？文件范例满清楚的…10/21 06:40
67F：推 single4565: 感谢各位回覆，我先去学flask了10/23 13:32
68F：推 converse: 先学会把iOS打正确吧10/29 15:12
※ 编辑: darrenlee1 (223.137.163.161 台湾), 10/29/2020 21:21:18