这是一个创建于 2464 天前的主题，其中的信息可能已经有所发展或是发生改变。
我現在用的比較多的框架就是 laravel，各位大佬有用 laravel 寫 APP 接口的麽，性能怎麽樣，
第 1 条附言 · 2018-03-25 13:00:11 +08:00
我也想过用 lumen，可以想到后面可能有管理后台的功能，，，
 |
1
dilu 2018-03-25 10:36:17 +08:00
如果只是单纯的写接口 推荐你使用 lemen
laravel 家族出品 专门为 api 而生 文档也全 还有中文的 |
|
2
dilu 2018-03-25 10:37:32 +08:00
不好意思打错了是 lumen
https://lumen.laravel-china.org/docs/5.3 这是中文文档 |
 |
3
mokeyjay 2018-03-25 10:41:41 +08:00
还是那句老话，绝大部分应用的都轮不到需要拼框架性能的时候
单纯轮框架性能的话，Laravel 虽然不敢说倒数第一，但一定也是倒数前几了 |
 |
4
Vogan 2018-03-25 11:00:32 +08:00
我用的。。。
目前业务量确实还没到达框架的瓶颈。 |
 |
5
MeteorCat 2018-03-25 11:05:05 +08:00 via Android
性能很不行，特别后期业务量大量引入大量第三方包带来的负担不适合做 API 接口，如果并发量极大的话推荐要么就 Phalcon 要么 Yaf，如果并发不大就随便哪个都可以
|
 |
6
carlclone 2018-03-25 11:19:18 +08:00
lumen+dingo+jwt-auth , 完美的搭配了
|
 |
9
master 2018-03-25 13:31:04 +08:00
你都写 API 了 管理后台也全做成接口 前端项目独立出来弄 根本用不着 Laravel 的 blade 吧
而且管理后台又不涉及什么 SEO 前端做连 SSR 都不涉及 |
 |
10
l57t7q 2018-03-25 15:37:33 +08:00  1
性能确实不好，但是等你发现不好的时候，DB 可能先跪
|
 |
11
akira 2018-03-25 16:12:18 +08:00
这种已经大量实施的框架，性能就算差也不会差到一个量级去。而且正常来说，大部分情况下，最早出现性能的点一般是数据库 /带宽 /IO 这些，和框架并没有太大关系的。
我们选框架的时候，性能是最后看的 甚至根本不会太关心框架性能。。 |
 |
12
vacker 2018-03-25 16:42:55 +08:00
我的小程序 API 就是用 laravel 写的。
|
 |
13
linxl 2018-03-25 17:27:34 +08:00
后台管理也用 api 啊...
|
 |
14
sobigfish 2018-03-25 17:28:18 +08:00
你可以后台用 laravel，API 用同样的 db migration / model 在 lumen 里(复制 粘贴)重新实现下
|
 |
15
ibegyourpardon 2018-03-25 18:51:44 +08:00 8
在这里跑个题，讲性能这件事，虽然也是老生常谈。
有一句话我们可能听的比较多了，也就是绝大多数情况下，我们这些写 CRUD 做点东西的，很难触碰到一个框架本身的性能瓶颈，更多问题出现在类似数据库啊 I/O 这些地方。上面 10# 和 11# 的大佬也提到了这个观点。 这话也没错，大多数情况下确实是这样。 而且很多时候我们提出这样的说法，是因为有人会问出这种性能问题之类，比如楼主这样，在一个项目上手开始之前，先关心起性能问题来了。其实真没必要。 but 在我这一年的一些业务实践里，确实在数据库等通常我们认为先出问题的地方之外，先出现了 Laravel 这个框架的性能问题。 我也没搞错，xhprof 等工具明明白白的告诉着你呢，就是 Laravel 慢。 一段时间内，甚至严重影响到了我这业务的运行。 理由和 #5 楼说的差不多，大量第三方包的引入，写起来是爽了，是快了，跑起来，并发稍微上来点，就卡了。 而且是比数据库还先挂。我们的数据库那个机器那个性能烂的哟……没事，前面高配的机器上跑的 Laravel 还挂的更快。 考虑过 Lumen 这回事，最后还是放弃，没意义。 目前解决方案是在已有的框架能满足业务的基础上，做一些拆分，有点类似微服务的性质，把某些重度业务用原生或者其他框架重写，既不会有非常大的工作量，又能给原先的 Laravel 减负。 但回到楼主的问题里，我仍然坚持那个观点，只管上，没到你操心性能的时候。真的到了操心性能的时候，那是公司业务欣欣向荣你开心都来不及的时候。 像我这边 Laravel 崩到不行的时候，就是赶上了 2017 年底公司最大型的一个活动，流量远远超出我们预期，才变成那样。但给我重来一次，我仍然会在最开始选择 Laravel，写起来简单粗暴，能应付各种多变的需求，部署容易，为啥不用。。 虽然以前说 DB 往往比 Laravel 先挂，现在我这里有个 Laravel 比 DB 先挂的反例，但还没到挂的时候，就先别操那么多心。 真的。踩坑一年的过来人告诉你，放心踩，再来一次，我还会选择 Laravel。 |
 |
16
lzhd24 2018-03-25 22:28:14 +08:00 via Android
@ibegyourpardon 学习了，老哥，实在！谢谢分享经验
|
 |
17
tktk 2018-03-25 23:14:03 +08:00
lumen+dingo+jwt 值得你拥有。如果你非要用 laravel 写访问量不是很大的话也没问题。不过 session 这种用不到的服务就不要注册了。
|
 |
18
onlineismy 2018-03-26 08:43:23 +08:00
管理后台不关 APP 接口啥事啊。。
|
 |
19
hzw94 2018-03-26 10:05:29 +08:00
学习了学写了，最近准备用 laravel 写个接口
|
 |
20
mandex 2018-03-26 10:12:43 +08:00
建议不要用 Lumen，直接上 Laravel。
之前一个项目用的 Lumen，少了很多东西，最后你还是要自己手动引入进来。 而且 Lumen 跟 Laravel 相比并没有显著的性能优势。 |
 |
21
nicoljiang 2018-03-26 11:19:28 +08:00
@mokeyjay 你说的是什么性能？我就知道，一个简单的 Hello World 就得上百毫秒，我作为代码狗的强迫症真心受不了。
|
|
22
mokeyjay 2018-03-26 11:26:47 +08:00 1
@nicoljiang #21 曾经我也跟你一样。直到我后面意识到：人的生命的有限的，但机器的性能是无限的、可恢复的。
很多时候开发速度比运行速度重要得多，慢就加配置加机器 |
 |
23
uoddsa OP @ibegyourpardon 谢谢大佬～～
|
Select Language