อัพเดต Tech Stack ที่ใช้ที่ LINE Company (Thailand) OA Plus 2022

สวัสดีครับผมกอล์ฟ ตัวแทน Solution Engineer จาก LINE Company (Thailand) ตั้งใจเขียนบทความนี้เพื่อแชร์ tech stack ที่ทีม OA Plus ใช้อยู่ เพื่อเป็นคำตอบสำหรับคนที่สงสัยว่า LINE ประเทศไทยทำอะไรบ้าง แล้วใช้เทคโนโลยีอะไร และคนที่สนใจร่วมงานกับเรา

หากใครเคยฟัง Poomrat Boonyawong พูดเรื่อง 13 Lesson Learned from Building OA Plus Infrastructure มาก่อน ก็จะพอมองเห็นภาพรวม infrastructure ของทีมที่ใช้ว่า เรา run application อยู่บน private cloud ของ LINE เอง และ self-hosted nodes กระจายอยู่หลายๆที่บนโลก

การออกแบบระบบ OA Plus ได้ adopt แนวคิด micro-frontend และ micro-services ตั้งแต่วันแรกที่ออกแบบระบบ

ด้วยความที่ทีมมีความชัดเจนในทิศทางของโปรดัค กลุ่มลูกค้า และการวางตำแหน่งของโปรดัคในตลาด ทีมเล็งเห็นว่าเพื่อให้ตอบโจทย์ business requirement เราต้องเลือกเทคโนโลยีที่ตอบโจทย์เรื่อง scaling ตั้งแต่วันแรก และช่วยให้ทีมแบ่งขอบเขตความรับผิดชอบได้ง่าย ความคล่องตัว รวมไปถึงการดูแลระบบในระยะยาว

โจทย์ที่ทีมเจอเราค่อนข้างอิสระในการเลือกเครื่องมือในท้องตลาด แต่ต้องมองการรียูสเครื่องมือภายในที่มีให้ได้ประโยชน์มากที่สุดก่อน ส่วน infrastructure โดยมากจะเป็นลักษณะ self-hosted เพื่อรักษาความลับ และความปลอดภัยข้อมูลของผู้ใช้งาน

ดังนั้นก่อนการตัดสินใจเลือกเครื่องมือใดๆ เราต้องทำการบ้านมาพอสมควร ที่จะเข้าใจมันเป็นอย่างดีก่อน adopt มาใช้

Background

OA Plus คือ โปรดัคที่ LINE Engineer ประเทศไทยคิดค้นขึ้นมาตั้งแต่ปี 2018 เราวาง position ตัวเองเป็น platform สนับสนุนให้ผู้ดูแล Official Account มีเครื่องมือ engage กับ followers อย่างมีประสิทธิภาพ และให้ประสบการณ์การใช้งานที่ง่าย ตรงกับพฤติกรรมการใช้งานของคนไทย

ด้วยความที่เป็น platform ระบบที่ออกแบบนั้นมีโจทย์ว่าต้อง scaling ได้ 2 pillars ได้แก่ business x tech scaling ตอนนี้ทีมไม่ได้คิดแค่ประเทศไทย แต่ทุกการออกแบบ ทีมมองไปถึงระดับ global scale แล้ว

LINE Engineer Taiwan ได้เริ่ม integrate กับระบบ OA Plus เพื่อเอาเครื่องมือที่ทีมเราทำไว้ ไปมองหาตลาด และกลุ่มลูกค้าใหม่ๆในประเทศไต้หวันแล้ว

ความสามารถของ OA Plus ที่มีโครงสร้างพื้นฐานข้างใน มีจำนวน services ที่มากมาย ช่วยให้เกิด usecase ใหม่ๆต่อยอดจนเกิดโปรดัค เช่น

• MyShop โซลูชันด้านการซื้อขาย เปลี่ยนโลกของอีคอมเมิร์ซแบบเดิม มาสู่สิ่งที่เรียกว่า social commerce
• MyRestaurant โซลูชันสำหรับผู้ประกอบการด้านอาหาร ช่วยให้การจัดการร้าน การสร้าง user engagement ด้าน food service เปลี่ยนไป
• OA Plus Open API ที่ทีมเราเปิดให้ 3rd party ต่อยอด OA Plus APIs ไปกับ usecase ใหม่ๆ

โซลูชันตัวอย่างเหล่านี้ใช้เครื่องมือ OA Plus นำไปต่อยอด และเชื่อมต่อกันอย่าง seamless นั่นหมายความว่า OA Plus ไม่ได้วางตำแหน่งตัวเอง แค่โฟกัสปัญหาใด ปัญหานึง หากแต่เราสเกลไปสู่ธุรกิจใหม่ๆในอนาคตได้

หมายเหตุ: บทความนี้ไม่ได้กล่าวถึง internal tools ที่ทาง LINE Global สร้างไว้ และ ไม่ได้รวมเทคโนโลยีฝั่ง mobile และ data ทีม จะโฟกัสเทคโนโลยี web อย่างเดียว

Client Side

client side tech stack

Micro Frontend Architecture

• Tailor — เป็น engine ตัวหลักที่ทีม adopt มาใช้ และพัฒนาต่อ สำหรับการวางโครงสร้างทั้งหมดในฝั่ง client ช่วยให้นักพัฒนาในทีมเราเอง และนอกทีม สามารถทำงานกันได้อย่างอิสระ แต่ละ fragment ไม่จำเป็นต้องผูกติดกับ framework, language เดียว หากผู้อ่านอยากรู้เพิ่มเติมเกี่ยวกับแนวคิดของ micro frontend สามารถฟังเพิ่มเติมได้ที่นี่ LINE Thailand Developer Conference 2019 — Micro Frontend: The New Era of Frontend Edge Technology และ Inside LINE OA Plus #2 Micro Frontends คืออิหยังหว่า? | LINE Developers Podcast EP.38
• Jasson — ทีมเราช่วยกันสร้าง design system ขึ้นมาเพื่อให้รูปแบบการแสดงผล การความคุม standard components ไปในทิศทางเดียวกัน ช่วยให้ UI/UX สอดคล้องกัน หลักๆ จะเป็น Vue และใน React ที่ถูกพัฒนาต่อโดยทาง LMWN
• OAP Cli — เป็น command line tools ให้กับนักพัฒนาฝั่ง client สามารถขึ้นโปรเจคได้ง่าย ทำ remote development ได้สะดวกยิ่งขึ้น เช่น การ serve static content จาก local ขึ้นส่วนใดส่วนนึงในเวปไซต์ โดยที่ไม่ต้องมานั่งเซ็ตเองทั้งหมด
• Nginx — ใช้ serve static content ที่ผ่านการ build มาแล้ว

User Facing

• Vue — ใช้ vue framework เป็นหลักในการพัฒนา fragment ถ้าเป็น service ใหม่ๆใช้ vue3 ไปเลย และใช้ vuex สำหรับ manage state
• React — เรากำลัง adopt react กับงานเล็กๆก่อน ซึ่งสัดส่วนยังไม่เยอะมากในระบบหลัก
• Nuxt—ใช้กับโปรเจคไม่ใหญ่มาก ที่ต้องการขึ้นโปรเจคไวๆ
• LINE — ส่วนสุดท้าย ก็ คือ ตัว LINE App เอง ที่เราพัฒนา LIFF App, Rich Menu, Text, รวมไปถึง interaction ที่สร้าง input ส่งเข้ามาในระบบเรา

Edge Network / Gateway

• Akamai /cloudfront— ใช้สำหรับทำ CDN
• Ambassador — ใช้ทำ API Gateway ส่วนของ Public Zone เราทำ LINE Login และ oAuth gateway ตัวนี้เปิดช่องให้เราเขียนโค๊ดเอง และเชื่อมต่อกับ core ambassador ได้อย่างง่าย

Languges

• TypeScript/Javascript — ใช้เป็นภาษาหลักในการพัฒนาส่วนนี้
• HTML, CSS, SASS — พื้นฐานของ frontend development
• BEM — เอาแนวคิดการ define selector สำหรับ Blocks, Elements and Modifiers มาใช้เพื่อช่วยในการรีวิวโค๊ด การจัดการ standard ได้ง่ายขึ้น
• NodeJS — ใช้ทำ layout service, cli tools จนไปถึงทำ backend for frontend

Practice

• CDD — component driven development ทุกๆการออกแบบ component เรา adopt สิ่งนี้มาใช้ เพื่อให้โฟลการทำงานไหลลื่น แบ่งการทำงานได้ง่าย และ testable ซึ่งใช้ร่วมกับ storybook

Testing

• Jest — ใช้ทำ unit test

CI & Build

• Webpack — build client side project (กำลังพิจารณา adopt Vite อยู่สำหรับ Vue)
• Jenkins — หลักๆใช้ Jenkins สำหรับการ build & deploy fragment
• eslint — ใช้เป็น linter ตัวหลัก และมี custom rules เพิ่มเติม
• prettier — ทำ code formatter และแน่นอน LINE ช่วยวงการ OSS อยู่เสมอ
• Dependabot — ใช้ automate เช็คพวก lib, dependencies ต่างๆ รวมไปถึง vulneability

Miscellaneous

• figma — collaborate prototype ไว้ทำงานร่วมกันกับ UX/UI Designer
• zeplin — UI design, user jouney ที่ผ่านการตกลงกันเราจะใช้เครื่องมือนี้ไว้ไว้สื่อสารกัน พวก images, assets, ui spec ที่ละเอียดๆจะลงไว้ที่นี่
• storybook — visualize components และ design system
• lottie — ทำพวก animate object บนเว็ป

อื่นๆที่ไม่ได้อยู่ในภาพ

• sentry — เมื่อมี stacktrace error บน fragment ใดๆ เราจะส่ง exception ขึ้น self hosted sentry รวมไปถึง integration alert เข้า slack เพื่อให้เรารู้ปัญหาได้เร็ว และแก้ไขปัญหาได้ตรงจุด
• Google Analytic
• Torimochi — เป็น global internal tool ของ LINE เอง ใช้ทำ tracking & analyze users ที่ใช้งานบนเว็ปไซต์เรา
• XLT (Cross language translate) — internal translation service ของเราที่ช่วยในเรื่องของการแปลภาษาต่างๆ ที่เรา support ในระดับ global ส่วนเรื่องการ implement เราใช้ library พวก i18n ของแต่ละ front-end framework เลยมาช่วยในการ mapping language config อีกที (ตัวอย่างเช่น https://kazupon.github.io/vue-i18n/)
• lighthouse — ใช้วัดคะแนน quality ของ web pages

Server Side

server side technology stack

หมายเหตุ: Solution Engineer งานฝั่ง backend นอกจากจะจับงาน web development แล้ว ยังมีงานฝั่ง data engineering เข้ามาด้วย แต่ความเข้มข้นไม่ได้เยอะมาก 😛

Langauges

• go — เรา adopt golang เป็นหลักสำหรับทำ APIs, backend development ที่ต้องการ high scale workload และ reduce memory footprint ภาษานี้จึงเป็นตัวเลือกที่เหมาะกับงานของเรา
• gin เป็น framework แรกที่เราเลือกใช้ หลังๆเราเลือกไปทาง echo และ fiber
• เรามี micro-services จำนวนมาก ดังนั้นเราจึงต้องทำ reusable library ใช้กันเองภายในบริษัท เช่น logger, tracing, mongodb, kafka client … เป็นต้น

LINE Company (Thailand) ติดลิสบริษัทที่ adopt go ด้วยนะ

ในด้าน community golang บริษัทเราให้การสนับสนุน go get th community อยู่เสมอ

GO GET TH

• nodejs—ใช้เป็น supporting tools สำหรับ development pipeline เช่น pre-commit และสร้าง internal tools ที่อยากขึ้นโปรเจคไวๆ
• python — ใช้กับงาน data pipeline เป็นหลัก คร่าวๆ เราเขียน pyspark กับงานที่ต้องการ process data บน spark cluster และส่งผลลัพธ์กลับมาที่ application storage zone เพื่อให้ go เอาไปใช้งานต่อ รวมไปถึงเราทำพวก approximate number ใช้ทำพวก theta sketch
• graphql — บางระบบต้องการ dynamic query / responseโดย client
• gRPC — ระหว่าง service-to-service ภายใน เรากำลัง adopt ใช้การสื่อสารแบบนี้ให้ได้มากที่สุด รวมไปถึง egress เราใช้ gRPC-Gateway ให้ support REST request (Stragler Application)

จริงๆยังมีพวก lua script ที่เราเขียน function on redis cluster และ เขียน KONG plugin ด้วย แต่ไม่ได้บ่อยมาก

Testing

• ginkgo — ใช้เป็น test runner และ รูปแบบการเขียน unit test ให้เป็นแบบ BDD
• gomock — ใช้ generate mock file (เราไม่ซีเรียสนะ testify ก็ไม่แย่)
• cobertura — ใช้ generate xml report เอาพวก code coverage แต่ละ services มาจัดฟอร์แมตให้ Jenkins เข้าใจ (codecov.io ก็มีแต่เราใช้กับ public git repo พวก SDK)

Databases (Cluster manner)

• HBase — เราใช้เก็บ message เข้ามาในบอท ในระบบ เรามองหา column base architecture และจัดการกับ traffic ขนาดใหญ่ได้ดี รวมไปถึงจัดการ data retention ได้ (เราใช้ HBase กันยังไงสามารถดูได้ที่นี่ LINE Thailand Developer Conference 2019 — Handle a Huge Traffic of Messages with HBase)
• Hive — เราใช้เก็บ data ขนาดใหญ่ๆ ที่เอาไปพักไว้ รองานที่เกี่ยวข้องกับ data segmentation เอาไปใช้งานต่อ (ซึ่งจะพูดถึงในหัวข้อ PySpark)
• MongoDB — เราใช้กับ real-time application งานของเราทำเกี่ยวกับ heavy read/write เราใช้ mongodb cluster ซึ่ง dev ออกต้องออกแบบ schema, shards key strategy, index เป็นและเข้าใจ ก่อนจะสร้าง database, collection ใหม่
• MySQL — ใช้กับงานที่ต้องการทำ relational db และแน่นอนเราใช้ gorm
• PostgreSQL — ใช้กับ KONG ในการเก็บ configurations และเป็น application database สำหรับบางโปรเจค
• Redis — ใช้กันค่อนข้างโหดที่นี่ กับงาน billions traffic user หลักๆเราใช้กับ usecase cache content เหมือนกับหลายๆที่ และ data structure ที่ใช้มีตั้งแต่ basic จนถึง advance
• Elasticsearch — มีงานที่ต้องทำพวก searching engine

Presenting on RedisConf18 - LINE ENGINEERING

เราทำงานกับ clustering system ดังนั้น concept distributed design ใช้คำว่าจำเป็นต้องรู้โดยเป็นเรื่องปกติของที่นี่

Gateway / Service Mesh

• Ambassador — เหมือนกันกับ client side เราใช้ตัวนี้เป็น gateway หลัก ทำ custom authentication, and authorization กัน ซึ่งมี gateway หลายประเภท ที่เราสร้างขึ้นมา ข้อดีตัวนี้ คือ YAML based ช่วยให้ DEV, QA, SRE สื่อสารกันด้วย keyword ที่ตรงกัน provision gateway ใหม่ๆ ได้สะดวกมาก
• Kong — เอามาใช้กับ Open API Project ความสามารถของ kong ช่วยลด developer effort ลงไปได้มาก เพราะมี standard plugins ที่เจ๋งมาก และ community ก็ดู active อยู่เสมอ เราใช้ Deck ทำ declarative configs เราใช้ Konga และ King Kong สำหรับ ui investigate configs ส่วนพวก manage consumers นั้น เราสร้าง UI ครอบอีกทีใน OA Plus Application คล้ายกับหน้า issue api key ในระบบอื่นๆนั่นแหละ
• Istio — ใช้เป็น sidecar คู่กับทุกๆ application container ทำพวก AuthorizationPolicy, Chaos-Engineering (Fault Injection), observation เป็นต้น
• Envoy — จริงๆ ambassador ขี่บน envoy proxy ดังนั้น เราก็ต้องมีความรู้ envoy configs บ้าง

Messaging System / Streaming Platform

• RabbitMQ — ใช้ทำพวก queuing system จัดการ exchange, queue, routing ที่มีความซับซ้อนได้ดี ตอนแรกเราใช้ classic queue แต่หลังเราพบว่า durability นั้นสำคัญ พอๆกันกับ high traffic เราเลยมาใช้ quorum queue แทน
• Apache Kafka — ที่นี่ใช้กันโหดมาก โหดที่สุด ที่ LINE มีทีมดูแล kafka broker โดยเฉพาะ มีทีม Platform Engineer ที่เทพมาก การ provision topic ใหม่ๆ process เปะมาก หากเราไม่ทำการบ้านมา ไม่คำนวน usage / prediction trend มา คุณไม่มีทางขอ topic ได้เลย เราใช้กับงาน choreography เป็นหลัก ในฝั่ง microservice เช่น event driven architecture จนไปถึง data streaming/ingestion ในฝั่ง data-pipeline

https://kafka.apache.org/powered-by

Containerized

• docker — ใช้ทำ aplication container เรา ship ของด้วย docker image อยู่เสมอ
• kubernetes — deployment เราใช้ k8s จัดการทั้งหมด ตั้งแต่ alpha environment จนไปถึง production คนเขียน yaml declaration คือ dev team เอง (IAAC) เราใช้ service, deployment, configmap, job, cronjob เป็นต้น
• rancher — ใช้จัดการ container orchestration ผ่านทาง UI (ใครชอบ cli ก็ไม่ว่ากัน)
• habor — self hosted docker artifact เราใช้สิ่งนี้เก็บ docker image ที่เรา build และดึงไปใช้ เมื่อต้องการ deploy

นอกจากนี้ เราใช้ helm chart, ansible และ terraform ด้วยในการขึ้น infra-as-a-code นานทีๆ ที่อยากลง tools ใหม่ๆใน kube cluster

Data Tools

• Dagster — เรากำลัง adopt manage data pipe ด้วย dev team เอง เป็น data culture เราทำเอง เรารู้ดีที่สุด โดยที่ data engineer เป็นที่ปรึกษา
• Airflow — มีบ้างที่ dev team ไปดู data stage ตอนนี้เป็นไงบ้างแล้ว

dev team ไม่ได้ provision เอง เรามี platform engineering ที่ทีม SRE เตรียมไว้ให้ ดังนั้น แค่เปิด pull request, submitted flow ไปยังทีม SRE ก็ได้ของมาใช้แล้ว

Data Applications

• Apache Spark — ไม่รู้ที่อื่นต้องทำแบบเราไหม แต่ dev team ที่นี่ prefer ที่จะเรียนรู้ และเขียน data pipeline เองนะ เราเขียน pyspark ทำงานกับ dataframe, rdd ขนาดใหญ่ แล้ว submit YARN เข้า driver/executor nodes จำนวนมาก เพื่อเอา data นั้นมาใช้งานต่อใน application layer
• Apache Druid — มองเป็น real-time database ที่ออกแบบในคอนเซพ column-oriented เราใช้ประมวลผล data ขนาดใหญ่ เพื่อทำ approximate number ให้ application query เพื่อไปแสดงผล ข้อดีของตัวนี้ คือ ingestion มาจากหลายทางได้ เช่น kafka stream, batch และ hive table
• Apache Superset — modern data exploration and visualization platform เราเอาไปต่อ druid เพื่อเอา data มา visualize และงานที่ต้อง investigate data ด้วย ว่าถูกต้องไหม

ที่นี่ใช้ Apache Software ค่อนข้างเยอะ เพื่อให้ community ไปต่อได้ เราก็สนับสนุนเป็น sponsors ให้กับทาง Apache ด้วย

https://www.apache.org/foundation/thanks.html#silver-sponsors

CI/CD

• Jenkins — build, deploy แอพพลิเคชัน ทำ pipeline รัน jobs ต่างๆที่เราทำไว้
• Argo — เอามาทำ gitops

Observations

• opensearch — เป็นตัวที่ fork มาจาก kibana + elasticsearch อีกที หลักๆเราเอาไว้ดู application logs ที่ส่งจากทุกๆ containers โดยเราเอา fluentd ทำเป็น daemonset แล้ว ingest log เข้า datalake อีกที
• fluentd — log shipper เราใช้ทำ log streaming กับ Apache Kafka และทำงานกับข้างบน
• sentry — ใช้เก็บ exception และ alert เข้า slack
• grafana — visualize graph, metric เหมือนกับหลายๆที่
• prometheus — เราเก็บ application metrics ที่นี่ จริงๆใช้ Thanos จัดการอีกที
• influxdb — ตอนนี้ใช้กับงาน K6 เป็นหลักในการเก็บ test result metrics
• opentelemetry — ทำเรื่องของ tracaibility

SAAS/PAAS/IAAS

อย่างที่เกริ่นไปตอนต้นบทความที่นี่เราลงทุน infrastructure เอง เราไม่ได้ใช้ public cloud ดังนั้นเรามีสิ่งที่เรียกว่า Verda

https://lineverda.com/

ความสามารถก็ใกล้เคียงกับ AWS, GCP และ Cloud Provider หลายๆเจ้าครับ

Tools

Load Testing

• K6 — ทำ load test เป็นหลัก แต่ก่อนเราเคยลองใช้ gatling แต่พบว่า productivity นั้นยังไม่ตอบโจทย์ เพราะ learning curve ยังเยอะอยู่
• Vegeta — เขียนด้วย go เพื่อ ยิงโหลดหนักๆ
• Wrk — เอาไว้ validate ผลกับ vegeta อีกที

End-to-End Testing

• cypress — ใช้ทำ e2e เป็นตัวหลักในทีม

Test Management

• testrails — เอาไว้จัดการ test suite, test case
• allure report — ดู report ของ automation test

Sourcecode Management

• GitHub Enterprises — เหมือนกับหลายๆที่ เราใช้ git enterprises ในการ manage source code และทำพวก webhook เวลาเปิด pull request ยิงเข้า slack เรา adopt monorepo และ poly repo ตามความเหมาะสมในแต่ละโปรเจค
• sonarqube — static analytic
• bots — เราใช้ bots หลายตัวในการเช็ค security, dependencies

API Doc

• openapi — ใช้ standard นี้ในการ define schema เพื่อ generate api document ข้อดีสำหรับคนเขียน go คือมี library auto generated ให้ เพียงแค่ define annotation บน routing code
• redoc — ใช้เป็น api doc render engine เอา json, yaml ที่ได้จากข้างบนมา render เรา custom redoc ซึ่งข้างหลัง เป็น react ใน style ที่เราต้องการ

เบื้องหลังเราสร้าง api doc pipelineโดยการยิงไปทุก micro-services เพื่อรวบรวม schema และ validate มา generate single yaml file เพื่อให้ redoc เอาไปใช้งานต่อ

Communication

• slack — เป็นช่องทางหลักที่ใช้คุยกับ LINE Engineer ทั่วโลก มี slack bot translation ที่เราสามารถคุยกับ native japan people อย่าง seamless และ slack bot หลายๆตัวที่เทพมาก
• discord
• zoom

Business Visualization

• tableau
• redash

หลักๆ product owner ใช้เพื่อทำ dashboard ให้มองเห็นภาพรวมของ product ที่นี่เราเน้นเรื่องของ transparency คือ ทุกๆ sprint review เราจะแชร์ dashboard ตรงนี้ให้กับทีมจากทาง po เพื่อให้ทุกคนเห็น output/outcome แล้ว user adoption ว่าเป็นยังไงแล้ว

Collaboration

• miro — online collaboration board ความเจ๋ง คือ ทีมวาดพร้อมกันโดยไม่เกิด disruptive จากตัวระบบ ไม่รวมแกล้งลบของกันนะ 😂 เราใช้ตอน brain writing, system design กันแบบหยาบๆ ก่อนเอาลง wiki
• draw.io — หลังจากที่ architecture design เราค่อนข้าง polish แล้ว ถึงเวลาวาดให้ดีๆ และ embed digram ลง wiki (เรากำลัง adop diagram-as-a-code กันอยู่นะ)

Project Management

น่าจะเหมือนกับหลายๆที่ หลายคนคงเคยได้ยิน Jira และ Confluent มาแล้ว ไม่ขอลงรายละเอียดมากนะครับ

Bot

• uptimerobot — เป็น bot health check ที่ยิงจาก public network เข้ามา ไว้เช็คความ healthy ของ public service เรา
• kuma — open source ตัวนี้เจ๋งดี เราใช้เป็น self-hosted ตัวเช็คความ service healthy เช่นเดียวกัน

บทความนี้น่าจะทำให้เห็น tech stack ของทาง LINE Company (Thailand) มากขึ้นนะครับ จริงๆแล้วภายในบริษัท เรายังมีโปรเจค และมีอีกหลายทีม ที่อาจจะใช้เทคโนโลยีที่ไม่ได้กล่าวถึงในบทความ แต่โดยรวมเราใช้เครื่องมือหลักๆที่เหมือนกันครับ เช่น ภาษา Java, Elixir และ Rust ที่ผมไม่ได้หยิบยกมา

สิ่งสำคัญคือเราใช้ทั้งหมด และช่วยกันทำการบ้านก่อนเอามาใช้งานจริงทุกชิ้น

สุดท้ายทาง LINE Company (Thailand) ยังเปิดรับเพื่อนร่วมทีมที่สนใจอยากพัฒนา global scale product ร่วมกันอยู่ตลอด หากสนใจสามารถติดตามรายละเอียดได้ที่นี่

LINE CAREERS

เนื้อหาที่เกี่ยวข้อง

เนื่องจากบทความนี้ไม่ได้มีการนำเอา high-level software architecture มาให้ดู เพื่อให้ผู้อ่านเข้าใจสิ่งที่เราทำมากขึ้น สามารถรับชมวีดีโอจากทางทีมพัฒนา LINE ประเทศไทยได้ที่ลิงค์วีดีโอข้างล่างได้เลยครับ

• Golang ใน LINE กับโค้ชบอล วีระ เกษตรสิน Head of Common Engineering | LINE Developers Podcast EP.3
• Integration Test in Event Driven Architecture
• The NEXT GENERATION of micro frontends with remote development
• Inside LINE OA Plus #4 Architecture, Tech stack และวิธีการออกแบบระบบ | LINE DEV Podcast EP.40