前提 大家好我是 LINE 台灣的 Technical Evangelist - Evan Lin 。「開發社群計畫」是今年一個開發者關係與技術推廣部門一個重點,將在今年一整年中,在台灣舉辦對內的技術交流、教育訓練,對外的社群聚會、校園演講、開發者徵才日與開發者大會等各式各樣超過30場的活動。我們希望創造更多技術分享與跨國串連的機會,同時,持續招募優秀的人才加入LINE台灣的開發工程團隊。 四月的第二場社群邀請到 Golang Taipei Gathering 社群的朋友來到 LINE 台北辦公室,並且一起來分享與討論 LINE 內部開發流程上針對 Golang 使用上的心得分享。這次的相關資訊可以在 meetup Golang Taipei #40 找到所有的內容介紹, Go GraphQL in LINE SPOT/ LINE - Denny Tsai 投影片 首先上場的是來自 LINE Spot 的工程師 Denny Tsai 。他也介紹了即將在 LINE 2019 下半年上限的全新服務 – LINE Spot 。提供消費者輕鬆搜尋所在地鄰近的店家資訊,以及店家進行中的特惠活動,消費者想要的資訊、店家想曝光的資訊都可以在 LINE SPOT 一站完成。這樣的服務將在 2019 年的第三季上線,敬請大家期待。 接下來講者開始分享如何透過 Go 跟 GraphQL 來當作微服務( Microservices ) 的 API Gateway 的經驗分享。由於產品的微服務漸漸增加,各個微服務都會提供個別的 API 供前端使用。除了 HTTP 的 API 之外還會多出了其他溝通的介面 (gRPC, Thrift…) ,如此一來造成前端與微服務間的串接複雜度提升。這時候會使用 API Gateway 當作統一進入點 ,進而使用 GraphQL 提供前端更好更有彈性的查詢方式,希望能夠 GraphQL 解決聽眾們經常遇到的問題。 GraphQL 是一個 Query Language 並且具有以下的優點: 單一進入點 (Single Endpoint): 不論是各種的不同的 API 需求,通通透過單一的進入點。 由客戶端來定義需要的資料型態 (Response shape defined by the client): 客戶端(通常指的就是前端)可以修改自己需要的資料型態,順序與排列方式。不需要修改任何的後端代碼。 Transport Agnostic: GraphQL 並不是一種語言而是一種標準,可是其實他並沒有限制所使用的傳輸層,因此可以使用任何適合的方式作為 GraphQL 的傳輸層。 此外講者也介紹了許多關於 GraphQL 有用的開發工具: GraphiQL: 一個在瀏覽器上的 IDE 可以讓你查詢與瀏覽 GraphQL 的工具。 GraphQL Playground: 開發 GraphQL 的 IDE 與測試工具,提供許多良好的介面與具有互動式的文件。 除了這些工具之外,由於本場分享關於 Golang 的開發者。講者也分享了市面上比較熱門的 GraphQL in Go 的開發套件: https://github.com/graphql-go/graphql https://github.com/graph-gophers/graphql-go https://github.com/99designs/gqlgen 這三套大概是搜尋 Golang 與 GraphQL 最容易被人找到的三個套件(因為 star 數也最高),但是講者最推薦 gqlgen 原因如下: Schema first Type safe Less boilerplate 而使用上也相當直覺,建立...
前提 大家好我是 LINE 台灣的 Technical Evangelist - Evan Lin 。「開發社群計畫」是今年一個開發者關係與技術推廣部門一個重點,將在今年一整年中,在台灣舉辦對內的技術交流、教育訓練,對外的社群聚會、校園演講、開發者徵才日與開發者大會等各式各樣超過30場的活動。我們希望創造更多技術分享與跨國串連的機會,同時,持續招募優秀的人才加入LINE台灣的開發工程團隊。 四月第一場社群活動邀請到 TWJUG (Taiwan Javsa User Group) 社群到 LINE 來舉辦。也請到 LINE Pay 的 Webber Su 來分享,除了讓更多人能夠了解 LINE Pay 工作經常用到的工具外,也希望能夠引發一些討論甚至可以互相交流。 Where is the ghost in the ghost island? Explore by Java and Mongo/ LINE Pay - Webber Su 投影片 首先上場的是 LINE Pay 的同仁 Webber Su 所帶來的透過開放資料集的一個案例分享。在 LINE Pay 的開發經驗上其實會遇到大量資料的處理與分析,但是由於許多的客戶資料都是屬於機密資料無法公開,所以透過開放資料集的案例來分享 LINE Pay 團隊日常遇到的相關問題。 透過開發資料將全台灣的事故資料匯入資料庫中,並且透過 LINE Pay Merchant Map 的部分的相關技術可以幫我們找出比較容易發生事故的問題區段。 在開始處理資料的之前,講者也分享了他會用到的相關開發工具如下: 以下稍微介紹每個工具的功能與相關作用: 資料的分析: Spring Web , Spark 與 MongoDB 。 資料批次處理: Spring batch 與 MongoDB 。 網站的後台系統: Node.js , Loopback 與 MongoDB 。 前台顯示部份: Vue.js 與 D3.js 。 這些開發工具也是 LINE Pay 團隊在開發上經常使用。除了開源專案工具之外, LINE Pay 也首次分享了 LINE Pay Merchant Map 的功能: LINE Pay Merchant Map 提供了地圖話資訊的條列與搜尋。包括了: List: 條列式的列表。 Nearby: 透過地圖是覺化的列出。 Search: 甚至透過關鍵字的搜尋方式。 在文字資料的搜尋上,究竟要使用 Elasticsearch 或是 MongoDB 作為文字搜尋呢?這裡講者也分享了當初在內部開發系統上,是透過哪些的評量方式來決定的。 由於許多效能的測試與評量上最後決定是 Elasticsearch 。而在地點鄰近搜尋 (Nearby) 上最後則是決定使用 MongoDB。 這個 Ghost Island 的架構其實也將 LINE Pay 開發團隊許多用到的工具分享給大家。裡面包括了資料該如何處理,該如何有效地處理與資料的讀取跟儲存? 這邊講者也分享了一些經驗談,就像是這個案例一樣,對於資料的處理上要有許多小地方要好好處理。如果是開放資料的時候,對於資料的處理要更加小心。資料可能有誤,資料可能有缺甚至資料可能是空的。所以可能將資料多儲存在其他地方也是一個可以變通的方式。這樣可以避免在資料清洗的時候造成程序的錯誤。後端針對文字搜尋與鄰近地圖搜尋則是透過兩個不同的儲存工具( Mongo 與 Elasticsearch )來處理資料。 而且講者也分享了在各個階段可能會踩到的雷(指的是遇到的問題)。不論是剛剛 Batch Spring process ,Spark 資料的處理上還是 Cargo 的部分。 整個主題雖然是使用開放資料的事故來做講解,但是不論是整個流程用到的相關開發工具還是可能會遇到的問題。講者也都分享出來 LINE...