laravel

A collection of 6 posts
透過 Swoole 加速 Laravel 效能
swoole

透過 Swoole 加速 Laravel 效能

Laravel 的速度瓶頸 雖然 Laravel 非常的強大與優美,但是對於 PHP 這種直譯式腳本語言來說,像 Laravel 這種複雜及龐大的框架會使得速度比起原生的 PHP 還要慢上許多,常見的優化方式有以下幾種: * 使用 Laravel 提供的指令來做快取優化 php artisan optimize php artisan config:cache php artisan route:cache php artisan optimize 在 Laravel 5.5 中已經列為 deprecated,無實際作用(不需要了)。 * 使用 Opcahce 加速 PHP 在每次執行時都會由 Zend 引擎先編譯成 OpCode。最後 Zend 虛擬機再執行
4 min read
在Laravel/Lumen中快速整合Invisible reCPATCHA
laravel

在Laravel/Lumen中快速整合Invisible reCPATCHA

前言 在上一篇的文章中,我們提到了今年Google宣佈推出最新版的機器人識別技術-Invisible reCPATCHA,而在這片文章中將教你如何快速的在你的Laravel專案中應用這項技術。 前端驗證指南 根據Google官方的文件指南看來,其實Invisible reCPATCHA的背後驗證的技術與前一代的no captcha應該不會相差太多,使用與前一代的API相同的引入位置: https://www.google.com/recaptcha/api.js,但既然Invisible reCPATCHA是完全隱形的,那該如何觸發進行驗證動作的時機呢? 其實很簡單,API只需要和你的submit button的送出事件綁定在一起,API即可在你正式送出表單資料前與Google的驗證伺服器完成驗證,以下為Google官方文件所提供的前端範例: <html> <head> <title>reCAPTCHA demo: Simple page</title> <script src="https://www.google.com/
4 min read
使用Hashids取代increment ID
hashid

使用Hashids取代increment ID

一直以來該使用increment ID或uuid當作是資料庫主鍵一直是兩派爭論不休的議題。 increment ID的優點相當的顯而易見,使用上簡易方便並具有佔用空間小及順序性等優點,個人覺得比較容易注意到的缺點大概就是id容易被外人進行猜測,雖然說這個部分應該是系統開發者應注意的事,但總覺得increment ID這種顯示方式醜醜的(或應該說太漂亮?) 此外increment ID還有一個缺點就是當你有資料轉移或合併的需求時,increment ID會讓你很容易發生id重複的問題。 反觀uuid他最大的特點就是你光從id上來看無法看出任何資訊(例如:順序),他就長得像這樣: 05177f3c-bdf7-4b96-927d-f6f636175a27,通常他是128bit長的數字,並且用16進制表示。缺點是在很多情形下作為主鍵建立索引查詢效率低。 因此在我最近的一個專案中,我嘗試使用Hashids當作是我的替代方案,我資料表的主鍵依然是使用increment ID,但是在id暴露給外部時,他會經由Hashids幫你算成像GlaHquq0的結果,他是可以解密的,所以名字上雖
3 min read