Header image

Giới Thiệu Về API Là Gì?

22/04/2022

1.18k

Giới Thiệu Về API

Xin chào các bạn, mình là Thắng, thành viên team QC của SupremeTech. Trong bài viết này, mình sẽ giải thích cho các bạn về một khái niệm rất quen thuộc trong kiểm thử nói riêng mà còn trong ngành IT nói chung, đó là API.

Mình nhớ khoảng thời gian đầu tiên khi mình bắt đầu nhận việc trong một dự án với yêu cầu chỉ có API; lúc đó mình còn chưa có đủ kiến thức và kinh nghiệm cùng với sự tự tin về mảng này. Có rất nhiều câu hỏi trong đầu mình như phải tìm hiểu thế nào? Kiểm thử ra sao? Và sau đó mình đã cố gắng học hỏi và thực hành rất nhiều, sau cùng mình nhận ra API không quá khó như lúc đầu mình nghĩ, ít nhất mình đã có được kinh nghiệm và kiến thức để tự tin áp dụng vào trong dự án.

Ở đây, mình sẽ chia sẻ lại cho các bạn những gì mình đã tìm hiểu, đã áp dụng vào thực tế, để mọi người có góc nhìn khác khi một tester nhìn vào API thì sẽ như thế nào nhé.

API là gì?

API là viết tắt của cụm từ Giao diện lập trình ứng dụng (Application Programming Interface). API cung cấp khả năng truy xuất đến một tập các hàm hay dùng. Và từ đó có thể trao đổi dữ liệu giữa các ứng dụng. Một cách dễ hiểu thì API là một trung gian phần mềm cho phép hai ứng dụng giao tiếp với nhau.

Ví dụ về API trong thực tế

Tưởng tượng bạn bước vào một nhà hàng, bạn đặt món, nhân viên phục vụ sẽ tiếp nhận yêu cầu của bạn và đưa vào nhà bếp, sau đó sẽ mang ra món ăn đúng với yêu cầu của bạn. Trong ví dụ trên, API là nhân viên phục vụ, đã giúp bạn và đầu bếp giao tiếp với nhau.

Bây giờ hãy nghĩ về một trường hợp ứng dụng API trong thực tế nhé. Giả sử bạn đi du lịch, bạn sẽ vào trang web của các hãng hàng không nhằm kiểm tra chuyến bay, giá cả, số ghế,… Nhưng vấn đề ở đây là có quá nhiều hãng hàng không và bạn lại không muốn mất thời gian cho những việc thế này, thay vào đó, bạn có thể sử dụng các dịch vụ trực tuyến trung gian nhiều tiện ích như Traveloka hay Expedia. Những dịch vụ đó sẽ tương tác với API của các hãng hàng không để hiển thị cho bạn các thông tin liên quan không chỉ của một mà còn của nhiều hãng bay khác nhau, từ đó giúp cho bạn tiết kiệm được rất nhiều gian và công sức. API thật tuyệt vời đúng không!

what is an API

HTML là gì?

Khoảng thời gian sau khi World Wide Web (WWW) được ra đời vào cuối những năm 1980, nhu cầu trao đổi dữ liệu giữa các thiết bị điện tử trở nên phát triển hơn bao giờ hết. Vào thời điểm đó, các tập tin siêu văn bản HTML được đưa lên web và người sử dụng có thể đọc được nội dung một cách dễ dàng.

HTML là viết tắt của từ HyperText Markup Language – Ngôn ngữ Đánh dấu Siêu văn bản. Đây là một loại ngôn ngữ nhằm định dạng trang web thông qua các thẻ (tag) nhằm giúp cho máy tính hiểu được bố cục và cấu trúc của trang web và hiển thị trang web đó. Tuy nhiên lập trình viên chỉ có thể sử dụng những tag được quy định sẵn trong HTML khiến cho việc mở rộng hay tạo ra những nội dung mới trên website khá khó khăn.

Một vấn đề khác nữa là HTML chỉ đơn thuần là ngôn ngữ trình bày nội dung, nó không có chức năng lưu trữ hay trao đổi dữ liệu giữa các máy tính với nhau, nghĩa là các hệ thống không thể tương tác với nhau như cập nhật giá cả hàng ngày chẳng hạn.

XML là gì?

Do đó XML – Extensible Markup Language được ra đời với sứ mệnh tạo ra các tài liệu web cho cả người và máy tính đều có thể dễ dàng đọc được, khiến Internet thực sự trở thành một mạng lưới liên kết đúng nghĩa thật sự. XML được phát triển bởi mười một người đóng góp tại W3C vào năm 1997.

XML, đúng như tên gọi của nó (Extensible – mở rộng), đã giải quyết được một vài vấn đề của HTML như thay vì sử dụng các tag có sẵn thì XML cho phép các lập trình viên tự tạo ra các tag của chính mình, từ đó cho phép họ thể hiện được nhiều nội dung hơn trên website, và đặc biệt là XML cho phép gói dữ liệu vào trong nội dung văn bản và trao đổi giữa các hệ thống với nhau.

Trước khi XML ra đời thì các hệ thống vẫn có thể trao đổi dữ liệu với nhau nhưng đó là một quy trình rất phức tạp và phải thống nhất rất nhiều quy tắc, dẫn tới việc nếu trao đổi dữ liệu lớn thì sẽ xảy ra tình trạng bị mất dữ liệu trong lúc chuyển đổi. Với XML, lập trình viên có thể khai báo trước các tag của mình và các hệ thống đều có thể đọc được và tương tác với nhau dễ dàng hơn.

Mình sẽ lấy một ví dụ đơn giản cho bạn dễ hiểu nhé. Trong HTML có một thẻ tag là <title> nhằm khai báo tiêu đề trang web. Cấu trúc sẽ như thế này:

<!DOCTYPE html>
<html>
  <head>
    <title>Supremetech blog</title>
  </head>
  <body>
  </body>
</html>

Trong khi đó, với XML bạn có thể tự khai báo thẻ tag <title> với nhiều mục đích khác nhau như tiêu đề trang web và tiêu đề một quyển sách hiển thị trên trang web đó mà không lo bị lỗi:

<?xml version="1.0" encoding="UTF-8"?>
<page>
  <head>
     <title>Book store</title>
  </head>
  <body>
    <library>
      <book>
        <title>Harry Potter</title>
        <author>J.K Rowling</author>
      </book>
      <book>
        <title>Sherlock Holmes</title>
        <author>Conan Doyle</author>
      </book>
    </library>
  </body>
</page>

Các bạn có thể thấy thẻ tag <title> nằm trong thẻ <head> sẽ được máy tính hiểu là tiêu đề của trang, còn thẻ <title> nằm trong thẻ <book> sẽ được hiểu là tiêu đề của quyển sách.

SOAP và RESTful

Sau khi hiểu được API là gì, các bạn sẽ thấy API vô cùng quan trọng trong thời đại số như hiện nay. Và như một điều hiển nhiên, mọi thứ sau khi phát triển một thời gian sẽ hình thành những quy tắc chung. Sau đây mình sẽ giới thiệu 2 chuẩn phổ biến là SOAP là RESTful.

SOAP

Sau khi XML ra đời, một vài kỹ sư tại Microsoft đã phát triển SOAP. SOAP là một tiêu chuẩn dựa hoàn toàn vào XML để chuẩn hóa việc giao tiếp giữa server và thiết bị (client), từ đó giúp cho việc phát triển API tốt hơn. Sau khi SOAP xuất hiện, đặc biệt vào năm 2000, SOAP đã được Microsoft và IBM thúc đẩy và trở nên phổ biến. Một số công ty và các tập đoàn lớn đã sử dụng SOAP như HP hay Oracle cho các chương trình của họ.

Một vấn đề khá lớn của SOAP là có quá nhiều quy tắc phải tuân thủ khiến cho lập trình viên thấy nó quá khó để sử dụng. Mặc dù việc có nhiều quy tắc cũng là một ưu điểm của SOAP bởi vì nhờ đó các lập trình viên có thể tạo ra các hệ thống độc lập nhưng vẫn giao tiếp tốt với nhau. Từ khả năng giao tiếp tốt đó, các hệ thống lớn gồm nhiều hệ thống liên quan sẽ được quản lý và phát triển một cách dễ dàng hơn.

RESTful

Một nhà khoa học máy tính tên Roy Fielding đã nhìn ra vấn đề đó và giới thiệu tiêu chuẩn REST trong luận văn tiến sĩ của mình với mục đích duy nhất: tạo ra tiêu chuẩn giúp cho các server đều có thể giao tiếp được với nhau. Nếu như SOAP sử dụng XML để tạo request và response thì RESTful có thể tạo request với một URL đơn giản đi cùng với các phương thức (method) như GET, POST, PUT, DELETE và response trả về cũng được viết ở nhiều dạng như JSON hay CSV. Bạn hãy nhìn vào ví dụ dưới đây về request và response của API dùng để xem giá cả nếu được viết dưới dạng XML theo tiêu chuẩn SOAP:

  • Request
<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Body>
  <m:GetPrice xmlns:m="https://www.w3schools.com/prices">
    <m:Item>Apples</m:Item>
  </m:GetPrice>
</soap:Body>

</soap:Envelope>
  • Response:
<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Body>
  <m:GetPriceResponse xmlns:m="https://www.w3schools.com/prices">
    <m:Price>1.90</m:Price>
  </m:GetPriceResponse>
</soap:Body>

</soap:Envelope>

Source: W3C

Rất là rắc rối và phức tạp đúng không nào. Trong khi đó nếu ta cũng dùng API gọi thông tin về giá sản phẩm theo RESTful thì chỉ cần gửi request tới URL (https://www.w3schools.com/prices), chọn method là GET thì sẽ có response dưới dạng JSON như sau:

{
    "Apple": "1.90"
}

Nhìn vào API theo tiêu chuẩn RESTful bạn cũng nhận ra nó đơn giản và dễ dùng hơn SOAP đúng không? Đó là lí do mà vì sao RESTful được sử dụng rất nhiều vào ngày nay.

Một lí do khác là vào thời điểm những năm 2000, Internet phát triển cực kì mạnh mẽ, đặc biệt là mảng thương mại điện tử. Rất nhiều tập đoàn lớn lúc đó đã phát triển API của mình để nhiều bên có thể truy cập vào dữ liệu sản phẩm của họ. Lúc đó Salesforce là một trong những người tiên phong cung cấp API của mình dưới tiêu chuẩn SOAP nhưng lại không được nhiều lập trình viên ưa chuộng vì tài liệu hướng dẫn sử dụng hơn 400 trang.

Trong khi đó, Ebay, mặt khác lại cung cấp API theo chuẩn RESTful và đã đạt được sự thành công đáng kể so với đối thủ là Salesforce lúc bấy giờ khi mà nhiều bên cảm thấy API theo chuẩn RESTful dễ truy cập và dễ sử dụng. Kể từ đó là thời kì phát triển mạnh mẽ của RESTful API, nhiều ông lớn đã đi theo Ebay như Amazon, Flickr,… Dưới đây là sơ đồ thống kê mức độ phổ biến các chuẩn API vào năm 2014:

API

Source

Dưới góc độ kiểm thử và sự phổ biến của RESTful nên mình sẽ nói kỹ hơn về chuẩn này nhé.

RESTful API

Hình ví dụ ở trên minh họa một cách đơn giản về nguyên lý hoạt động của API theo tiêu chuẩn RESTful. Hãy lấy lại ví dụ ở phần trước đó về việc bạn sử dụng Traveloka để xem thông tin về chuyến bay nhé. Bạn vào mục tra cứu chuyến bay trên web Traveloka, sau bước này thì website – client sẽ gửi request theo giao thức HTTP tới server của hãng bay. Tùy thuộc vào phương thức – method bạn gửi thì server sẽ có những xử lý tương ứng. Trong RESTful sẽ có 4 phương thức cơ bản sau đây:

  • GET (SELECT): Trả về một Resource hoặc một danh sách Resource.
  • POST (CREATE): Tạo mới một Resource.
  • PUT (UPDATE): Cập nhật thông tin cho Resource.
  • DELETE (DELETE): Xoá một Resource.

Những phương thức hay hoạt động này thường được gọi là CRUD tương ứng với Create – Tạo, Read – Đọc, Update – Sửa, Delete – Xóa.

Ví dụ ở đây bạn muốn xem thông tin về chuyến bay thì method client dùng sẽ là GET nhằm lấy về danh sách các chuyến bay theo yêu cầu của bạn. Sau khi server nhận được request của Client sẽ tiến hành trả về dữ liệu phù hợp response. Dữ liệu trả về thường được viết dưới dạng JSON hoặc XML tùy thuộc vào tính chất của dự án. Dữ liệu trả về gồm có cấu trúc như sau (mình sẽ để dưới dạng JSON nhé):

{
    "status_code": 200,
    "data": [
        {
            "name": "LH370",
            "Time": "Mar 29, 2022",
            "City": "DNG"
        },
        {
            "name": "LH370",
            "Time": "Mar 29, 2022",
            "City": "HCM"
        }
    ],
}

Các bạn có thể thấy ở response có dòng “status_code”, biến này sẽ cho chúng ta biết được trạng thái của response trả về. Các mã sẽ được phân thành các nhóm như sau:

  • 2xx: Successful responses / Phản hồi thành công:
  • 200 OK – Trả về thành công cho những phương thức GET, PUT, PATCH hoặc DELETE.
  • 201 Created – Trả về khi một Resource vừa được tạo thành công.
  • 204 No Content – Trả về khi Resource xoá thành công.
  • 3xx: Redirects / Điều hướng
  • 304 Not Modified – Client có thể sử dụng dữ liệu cache.
  • 4xx: Client errors / Lỗi phía client
  • 400 Bad Request – Request không hợp lệ
  • 401 Unauthorized – Request cần có auth.
  • 403 Forbidden – bị từ chối không cho phép.
  • 404 Not Found – Không tìm thấy resource từ URL
  • 5xx: Server errors / Lỗi phía máy chủ
  • 500 Server Error: domain, hosting hết hạn, hoặc dừng server đột ngột để test
  • 502 Bad Gateway
  • 503 Service Unavailable

Web services là gì? Phân biệt API và web services

Và lúc này khái niệm web services trở nên phổ biến. Giờ chúng ta tìm hiểu thêm một khái niệm mới nhé.

Nói một cách khái quát, web services là những tài nguyên có sẵn trên internet, là dịch vụ cung cấp một số chức năng mà các ứng dụng khác có thể sử dụng. Chức năng này có thể bao gồm xử lý thanh toán, đăng nhập và lưu trữ cơ sở dữ liệu. Cả API và web services đều đóng vai trò giúp cho các ứng dụng giao tiếp được với nhau. Điểm khác biệt cơ bản giữa API và web services đó là web services giúp các ứng dụng giao tiếp với nhau trên Internet nhưng API có thể giúp các ứng dụng giao tiếp với nhau mà không cần Internet. Chúng ta có thể nói tất cả web services là API nhưng không phải API nào cũng là web services.

Hơi rắc rối đúng không nào, mình sẽ lấy một ví dụ cho bạn dễ hình dung nhé:

Hầu như trong cuộc sống ngày nay chúng ta luôn có sẵn ứng dụng Facebook trên điện thoại của mình. Khi bạn bắt gặp một khoảnh khắc nào đó và muốn chụp một bức hình để chia sẻ cho bạn bè cũng xem, bạn sẽ bấm vào biểu tượng máy ảnh trên Facebook và nó sẽ mở màn hình chụp ảnh cho bạn. Lúc này Facebook sẽ gọi API máy ảnh của điện thoại để sử dụng máy ảnh ngay trên ứng dụng mà không cần phải mở app chụp ảnh mặc định của điện thoại, và việc gọi API này thì không cần mạng. Ở một trường hợp khác, khi bạn vào xem thông tin một địa điểm nào đó trên Facebook thì sẽ thấy bản đồ chỉ đường tới địa điểm đó đúng không? Lúc đó Facebook sẽ gọi API (web services) từ Google Map để lấy thông tin bản đồ về và thao tác này chắc chắn cần mạng mới có thể làm được.

Cho tới hiện tại, việc tranh cãi SOAP hay RESTful tốt hơn vẫn chưa hề kết thúc. Tùy thuộc vào tính chất của dự án và sở thích của lập trình viên mà chúng ta sẽ lựa chọn chuẩn phù hợp. SOAP có thể phức tạp, phải tuân thủ nhiều quy tắc nhưng đôi khi nó lại dễ sử dụng trong một số trường hợp, còn đàn em của nó là RESTful nổi lên như một giải pháp thay thế mới mẻ song vẫn có những vấn đề của riêng nó.

Bài viết giới thiệu về API của mình đến đây là hết, mình rất vui vì một phần nào đó đã giúp các bạn có thêm những kiến thức mới. API theo chuẩn RESTful rất phổ biến, do đó kĩ năng kiểm thử API theo chuẩn này rất cần thiết với tester. Những bài viết tiếp theo mình sẽ giới thiệu cho các bạn về những công cụ thường được sử dụng trong việc test API như Postman, Charles,… Hẹn gặp lại các bạn lần sau!

Reference

  • W3schools (no date) W3schools.com, W3Schools Online Web Tutorials. Available at: https://www.w3schools.com/xml/xml_soap.asp (Accessed: 04 October 2024).
  • Jay (2023) Soap and rest at odds, The History of the Web. Available at: https://thehistoryoftheweb.com/soap-rest-odds/ (Accessed: 04 October 2024).
  • Harrington, D. (2024) The history of rest apis – readme: Resource library, ReadMe. Available at: https://readme.com/resources/the-history-of-rest-apis (Accessed: 04 October 2024).

Author: Thang Tran

Related Blog

Anh Hoàng - “Người truyền lửa” trên hành trình vươn mình của SupremeTech

Our culture

+0

    Anh Hoàng – “Người truyền lửa” trên hành trình vươn mình của SupremeTech

    “Khởi nghiệp với rất nhiều “không”. Không bệ phóng. Không mối quan hệ. Không đội ngũ. Tất cả những gì anh có là bản thân mình với một tinh thần lạc quan và ý chí không bao giờ bỏ cuộc.”Anh Hoàng, Chủ tịch SupremeTech. Gặp anh Hoàng lần đầu sau khi bắt đầu làm việc tại văn phòng chừng 1 tuần, ấn tượng của tôi đúng với những gì mường tượng về anh sau buổi phỏng vấn online trước đó 2 tháng. Là một người anh lớn với phong thái giản dị, điềm tĩnh từ cử chỉ tới cách nói chuyện, nhưng mỗi lời nói của anh đều toát lên nhiệt huyết của người dẫn đường. Còn nhớ trong buổi trò chuyện hôm đó, không có khi nào anh đề cập tới mục tiêu, kế hoạch hay KPI. Bắt đầu từ câu chuyện trở về Việt Nam của anh, rồi hành trình đặt những viên gạch đầu tiên ở thị trường IT, Tech còn rất hoang sơ ở Đà Nẵng năm 2014 và cuối cùng là điểm dừng chân hiện tại - SupremeTech - ngôi nhà của 200 nhân sự tài năng, tất cả những gì đọng lại trong một nhân viên mới khi đó là sự hứng khởi khi được đồng hành trên chặng đường phía trước, có thể sẽ gập ghềnh nhưng chắc chắn vô cùng đáng nhớ. Sự hứng khởi, và có phần an tâm ấy, được nhen nhóm từ chính những chia sẻ rất đời thường của anh Hoàng.  Có lẽ sẽ hẹn một dịp khác để kể lại từng dấu mốc trong 11 năm khởi nghiệp của anh Hoàng. Còn trong buổi trò chuyện đặc biệt nhân dịp kỉ niệm 5 năm thành lập SupremeTech này, khi ngồi cùng với nhóm các nhân viên, cả những người đã gắn bó với công ty từ ngày đầu, chúng tôi muốn nghe và kể nhiều hơn về quá trình xây dựng và phát triển công ty từ con số 0. Dưới góc nhìn của anh Hoàng - người đã mở đường và vẫn đang dẫn đường, câu chuyện ấy sẽ thêm phần thú vị. Hành trình vạn dặm bắt đầu từ một bước chân Năm 2014, Đà Nẵng đã nổi tiếng là một thành phố du lịch hút khách bậc nhất miền Trung. Nhưng nhắc tới công nghệ thì cái tên Đà Nẵng còn rất xa lạ. Giáo dục các ngành IT, Tech cũng chưa được chú trọng và phần lớn nhân tài ngành này chọn lập nghiệp ở những thành phố nhiều cơ hội như Hà Nội và Hồ Chí Minh. Nhân sự IT chất lượng ở Đà Nẵng khi đó có lẽ chỉ đếm trên đầu ngón tay. Khó khăn vậy mà khi được hỏi tại sao anh lại chọn trở về Việt Nam khi đã có sự nghiệp vững chắc tại Nhật, anh Hoàng chia sẻ: “Thời anh đi học ở Nhật, khoảng cách phát triển giữa hai nước còn rất xa về mọi mặt. Anh nung nấu ý định trở về để làm đất nước mình lớn mạnh hơn. Anh nghĩ người Nhật làm được thì người Việt chúng ta cũng làm được. Bắt đầu từ việc phát triển bản thân mình để trở thành một người có ích cho xã hội, mang lại giá trị cho những người xung quanh mình, rồi tiến tới đóng góp vào sự phát triển của đất nước. Nhưng mong muốn thôi là chưa đủ để biến ước mơ thành hiện thực, nhất là khi mình chưa tích lũy nội lực cho bản thân. Quãng thời gian ở Nhật cho anh tiếp cận với rất nhiều góc nhìn mới. Cả tính kỷ luật và tư duy tốt lên mỗi ngày cũng được rèn giũa trong những năm tháng anh học và làm việc ở đó. Có thể nói khi đủ đam mê, đủ nhiệt huyết và đủ năng lực theo đuổi đam mê thì cơ duyên về Việt Nam cũng xuất hiện để anh trở về khởi nghiệp và đạt tới những thành công nhất định như ngày hôm nay.” Sự thật là hành trình vạn dặm nào cũng bắt đầu từ một bước chân. Mà trong câu chuyện này, đó là bước chân trở về. Chặng đường đáng nhớ cùng SupremeTech Không khó để hình dung những khó khăn của một công ty được thành lập ngay giữa đại dịch Covid-19 rúng động thế giới. Những ngày đầu, công ty chỉ có vài chục nhân sự là những người em mà anh Hoàng từng dẫn dắt. Vào đúng giai đoạn cần nhiều kết nối con người làm nền tảng phát triển đội ngũ mới, cả công ty phải làm việc ở nhà để đảm bảo an toàn. “Cái khó ló cái khôn”, khoảng cách địa lý lại là động lực thúc đẩy những ý tưởng sáng tạo để gắn kết nhân sự, điển hình như cuộc thi “Capture WFH moments” hay hoạt động viết blog. Đúng như mindset tự chủ, trưởng thành từ hành động, không ngại thử thách mà anh Hoàng vẫn lan tỏa: “Chưa bao giờ anh có cảm giác chùn bước vì anh luôn sẵn sàng đối diện với khó khăn. Càng khó khăn thì anh càng muốn chinh phục và nâng cao nội lực bản thân mình. Anh luôn giữ trong đầu câu hỏi “Vì sao người khác làm được?” làm kim chỉ nam để tiến về phía trước. Ban đầu cần luyện tập để nâng cao khả năng chịu stress cả về tinh thần và tính cách. Lâu dần nó “ngấm” vào con người mình lúc nào không hay (cười).”  Ý tưởng sản phẩm MiaHire cũng thành hình trong chính giai đoạn này. Làm sao để tuyển dụng gần 100 nhân sự/năm với nguồn lực có hạn và hạn chế về địa lý trong đại dịch? Khi những “pain points” phát sinh từ câu hỏi này được giải quyết cũng là lúc sản phẩm MiaHire - Nền tảng phỏng vấn video ra đời và có những khách hàng đầu tiên.  Rồi tới biến động kinh tế, khủng hoảng thị trường, sự rớt giá của đồng Yên…lần lượt từng thử thách đi qua khiến cho đội ngũ SupremeTech thêm vững vàng hơn, trưởng thành hơn. Khi được hỏi khoảnh khắc nào đáng nhớ nhất với anh Hoàng trong 5 năm thăng trầm vừa qua, câu trả lời không phải là những con số doanh thu, những dự án mới, sản phẩm mới, khách hàng mới hay thị trường mới. Đối với anh Hoàng, di sản của 5 năm gieo mầm chính là những con người đang trưởng thành trong môi trường SupremeTech.  “Khi anh thấy những người đã đồng hành từ những ngày đầu giờ đây đang trưởng thành lên từng bước một, đó là khoảnh khắc làm anh xúc động nhất. Giờ đây anh không cần phải có mặt trong từng sự kiện hay hoạt động để dẫn dắt mọi người nữa, mà mọi người đã tự tin tổ chức, tự mình dẫn dắt, làm mọi thứ bằng nhiệt huyết và tinh thần của chính các bạn.  Anh mong muốn tất cả những người đến với anh, đi cùng anh, đều có thể từng bước trưởng thành hơn. Anh luôn tâm niệm rằng sống một đời thì không quá dài, nên anh muốn sống cho thật có ích. Anh muốn mình trở thành hình mẫu mà mình thích trước tiên, và tạo nên SupremeTech là nơi mà không chỉ cho riêng anh, mà còn cho tất cả các bạn đi cùng anh được sống đúng với giá trị của mình, được phát triển, và rồi một ngày nào đó, chính họ lại trở thành người truyền lửa cho người khác và đem đến sự phát triển của đất nước, xã hội.” Có lẽ chính triết lý phát triển con người đó của anh Hoàng là xương sống cho sự phát triển bền bỉ của công ty. Một khi đồng hành cùng những người có chung tầm nhìn, khó khăn hay thử thách chỉ là chất xúc tác làm cho tinh thần đồng đội thêm bền chặt. Tự chủ trong mỗi bước đi Từ khi thành lập tới nay, một trong những hoạt động nổi bật được giới thiệu tới mọi nhân viên mới đó là học và thi lấy chứng chỉ chuyên môn. Mọi người đều được khuyến khích nâng cao năng lực trong lĩnh vực của mình và học thêm kiến thức mới. SupremeTech coi đây là một khoản đầu tư chiến lược cho nội lực của công ty.  Ngoài chuyên môn, định hướng trao quyền tự chủ về nhiều mặt cho mỗi thành viên là một trong những động lực lớn cho sự phát triển văn hóa công ty và kết quả kinh doanh tích cực. Anh Hoàng giải thích: “Tự chủ không chỉ là khi công ty có thể tự vận hành, tự đưa ra định hướng, mà còn là khi mỗi cá nhân trong tập thể biết cách chịu trách nhiệm với công việc của mình, biết cách đóng góp giá trị một cách độc lập và chủ động. Đó là lý do năm 2025, SupremeTech tổ chức rất nhiều hoạt động nội bộ để tôn vinh tinh thần tự chủ: từ sinh hoạt ST, nơi các bạn có thể tự điều hành và chia sẻ suy nghĩ của mình, đến các hoạt động nội bộ, các hội thi thể thao…”   Một cột mốc rực rỡ khép lại là lúc mở ra những chương mới hứng khởi hơn. Ở vị trí của người cầm đuốc, anh Hoàng giúp chúng tôi hình dung rõ ràng về SupremeTech của 5 năm tiếp theo. “Nếu giai đoạn 5 năm đầu là lúc chúng ta gieo mầm từ văn hoá, con người đến nội lực công ty thì 5 năm tới, anh mong được thấy sự tự chủ thật sự của SupremeTech. Mục tiêu của chúng ta là vững vàng đứng trên đôi chân mình. Các sản phẩm product của chúng ta sẽ lớn mạnh và gặt hái được nhiều thành công hơn, và SupremeTech sẽ ngày càng trưởng thành và vững mạnh, dù là trong vận hành hay trong việc tìm kiếm cơ hội.” Ngày mai tốt hơn hôm nay, một centimet là đủ  Buổi nói chuyện cùng anh Hoàng như thước phim tua lại những khoảnh khắc đáng nhớ trong suốt hành trình 5 năm. Mỗi người đều có dịp ôn lại góc nhỏ của mình trong bức tranh chung của SupremeTech. Vì thời lượng có hạn nên dù còn nhiều điều muốn chia sẻ, cả team đành phải hẹn anh Hoàng ở một dịp khác. Như muốn giữ lại chút dư âm sau cuộc trò chuyện, chúng tôi đồng lòng:  “Còn điều gì anh muốn gửi gắm tới tập thể SupremeTech trong dịp đặc biệt này không?” Anh Hoàng: “Hãy enjoy với mọi trải nghiệm dù là tốt hay xấu. Hành trình nào cũng đáng quý kể cả khi nó gập ghềnh, khó khăn. Miễn là ta không bỏ cuộc, vẫn còn đi tiếp, và giữ được sự tích cực trong mỗi bước đi. Người thành công không phải là người may mắn nhất, mà là người không bỏ cuộc. Người dám đi tới cùng với đam mê lớn mạnh của mình sớm muộn cũng sẽ đến được đích. Các bạn hãy nhớ rằng không ngừng trau dồi và rèn luyện bản thân mỗi ngày, ngày mai tốt hơn hôm nay một centimet là đủ.” Hành trình tiếp theo vẫn là những bước chân bền bỉ 5 năm không phải một chặng đường quá dài, nhưng đủ để một hạt mầm vươn mình trở thành cây vững gốc. SupremeTech đã và đang lớn lên như thế bằng sự bền bỉ, bằng nội lực, và bằng tinh thần "tốt hơn hôm qua một centimet". Cảm ơn anh Hoàng vì cuộc trò chuyện đầy cảm hứng và ý nghĩa! >>> Đọc thêm: From Seeking The Path to Leading The Way: Phuoc’s Journey at SupremeTechAnh Duong – A Journey of Rising Above to Shine Bright

    18/07/2025

    124

    Our culture

    +0

      Anh Hoàng – “Người truyền lửa” trên hành trình vươn mình của SupremeTech

      18/07/2025

      124

      Sparking the Fire, Spreading the Passion

      Our culture

      +0

        Sparking the Fire, Spreading the Passion

        At SupremeTech, we believe growth isn’t something that happens in isolation. True success lies in helping others rise and evolve alongside you. That's why we call it "Sparking the Fire, Spreading the Passion". When Quang Hai joined SupremeTech five years ago, he was a young professional just beginning his career. He brought with him a curious mind and an eagerness to learn, though like many new hires, he faced a steep learning curve. d. Like many beginners, he faced challenges and had a lot to learn. Luckily, he had a mentor to supported him, gave honest feedback, solved problems together, and always believed in his potential. This journey was not just about learning new skills. It was about growing, building confidence, and sharing that growth with others. We talked with Mr. Duc Tai, the mentor who supported Hai from the beginning, and with Quang Hai, who is now ready to guide the next generation. Their stories show how one person’s support can help light a spark that keeps on spreading. Sharing From the Mentor - Mr. Duc Tai What made you believe Hai had the potential to go far? Mr. Tai: Right from the start, Hai showed that he could think clearly and always tried to understand problems deeply. He didn’t just fix things on the surface. He wanted to solve the real issue so that everything could work better in the long run. He was calm, listened well, and focused on finding solutions instead of complaining. He was also very responsible. I never had to worry about the tasks I gave him. When assigning roles, do you prioritize short-term results or long-term development? Mr. Tai: I always lean toward long-term growth. If someone is in a role where they feel both challenged and supported, the results will naturally follow, and they’ll last longer. It's not just about getting things done today but building a foundation that sustains growth in the future. What do you find to be the most challenging part of being a manager? Mr. Tai: It’s finding the right place for each person. I spend a lot of time watching and thinking about how people work. When someone is in a role that suits them, they can grow at their own pace, and the entire team becomes stronger. From the Mentee Turned Mentor - Quang Hai When you first became a leader, what were you afraid of? Hai: When I was first given a leadership position, I felt nervous and unsure of myself. I wondered if I was ready and if I could earn my teammates’ trust while I still had so much to learn. Later, I realized that being a leader doesn’t mean you have to be perfect. What matters is being there for your team, being willing to listen, taking responsibility, and continuing to learn. What is the most valuable lesson you’ve learned from Mr. Tai? Hai: I learned always to be ready to take on responsibility. Mr. Tai never says no to a task, whether it comes from the company or the team. He always takes action and faces problems directly. That attitude showed me that if you want to grow, you have to step out of your comfort zone and keep moving forward. Now that you're guiding others, when do you feel you’ve truly grown? Hai: I see it in the way I listen and ask questions. I used to think a mentor had to provide all the answers. But now I know that helping someone means guiding them to find their own answers. I often ask, “What do you think?” or “What’s making this hard for you?” To me, growth isn’t about being the most knowledgeable person in the room. It’s about walking alongside others and helping them grow in their own unique way. Final thought Quang Hai’s journey is more than a story of personal development. It reflects the broader spirit at SupremeTech—a place where everyone is given the opportunity to learn, face challenges, and eventually pass on their knowledge to the next wave of talent. His transformation from mentee to mentor is living proof that when someone is nurtured with care and trust, they can grow strong enough to lift others as well. Because at SupremeTech, growth is never just about one person. And as long as we continue to support and inspire each other, the fire will never go out. >>> Read more: From Seeking The Path to Leading The Way: Phuoc’s Journey at SupremeTechAnh Duong – A Journey of Rising Above to Shine Bright

        09/07/2025

        161

        Our culture

        +0

          Sparking the Fire, Spreading the Passion

          09/07/2025

          161

          How-to

          Knowledge

          +0

            Level Up Your Code: Transitioning to Validated Environment Variables

            Validated Environment variables play a critical role in software projects of all sizes. As projects grow, so does the number of environment variables—API keys, custom configurations, feature flags, and more. Managing these variables effectively becomes increasingly complex. If mismanaged, they can lead to severe bugs, server crashes, and even security vulnerabilities.  While there’s no one-size-fits-all solution, having some structure in how we manage environment variables can really help reduce mistakes and confusion down the road. In this article, I’ll share how I’ve been handling them in my own projects and what’s worked well for me so far. My Personal Story When I first started programming, environment variables were a constant source of headaches. I often ran into problems like: Misspelled variable names.Failure to retrieve variable values, even though I was sure they were set.Forgetting to define variables entirely, leading to runtime errors. These issues were tricky to detect. Typically, I wouldn’t notice anything was wrong until the application misbehaved or crashed. Debugging these errors was tedious—tracing back through the code to find that the root cause was a missing or misconfigured environment variable. For a long time, I struggled with managing environment variables. Eventually, I discovered a more effective approach: validating all required variables before running the application. This process has saved me countless hours of debugging and has become a core part of my workflow. Today, I want to share this approach with you. A Common Trap in Real Projects Beyond personal hiccups, I’ve also seen issues arise in real-world projects due to manual environment handling. One particular pitfall involves relying on if/else conditions to set or interpret environment variables like NODE_ENV. For example: if (process.env.NODE_ENV === "production") { // do something } else { // assume development } This type of conditional logic can seem harmless during development, but it often leads to incomplete coverage during testing. Developers typically test in development mode and may forget or assume things will "just work" in production. As a result, issues are only discovered after the application is deployed — when it's too late. In one of our team’s past projects, this exact scenario caused a production bug that slipped through all local tests. The root cause? A missing environment variable that was only required in production, and the conditional logic silently skipped it in development. This highlights the importance of failing fast and loudly—ideally before the application even starts. And that’s exactly what environment variable validation helps with. The Solution: Validating Environment Variables The secret to managing environment variables efficiently lies in validation. Instead of assuming all necessary variables are correctly set, validate them at the application’s startup. This prevents the application from running in an incomplete or misconfigured state, minimizing runtime errors and improving overall reliability. Benefits of Validating Environment Variables Error Prevention: Catch missing or misconfigured variables early.Improved Debugging: Clear error messages make it easier to trace issues.Security: Ensures sensitive variables like API keys are set correctly.Consistency: Establishes a standard for how environment variables are managed across your team. Implementation Here’s a simple and structured way to validate environment variables in a TypeScript project. Step 1: Define an Interface Define the expected environment variables using a TypeScript interface to enforce type safety. export interface Config { NODE_ENV: "development" | "production" | "test"; SLACK_SIGNING_SECRET: string; SLACK_BOT_TOKEN: string; SLACK_APP_TOKEN: string; PORT: number; } Step 2: Create a Config Loader Write a function to load and validate environment variables. This loader ensures that each variable is present and meets the expected type or format. Step 3: Export the Configuration Use the config loader to create a centralized configuration object that can be imported throughout your project. import { loadConfig } from "./loader"; export const config = loadConfig(); Conclusion Transitioning to validated environment variables is a straightforward yet powerful step toward building more reliable and secure applications. By validating variables during startup, you can catch misconfigurations early, save hours of debugging, and ensure your application is always running with the correct settings.

            09/07/2025

            120

            Bao Dang D. Q.

            How-to

            +1

            • Knowledge

            Level Up Your Code: Transitioning to Validated Environment Variables

            09/07/2025

            120

            Bao Dang D. Q.

            How-to

            Knowledge

            +0

              Build Smarter: Best Practices for Creating Optimized Dockerfile

              If you’ve been using Docker in your projects, you probably know how powerful it is for shipping consistent environments across teams and systems. It's time to learn how to optimize dockerfile. But here’s the thing: a poorly written Dockerfile can quickly become a hidden performance bottleneck. Making your images unnecessarily large, your build time painfully slow, or even causing unexpected behavior in production. I’ve seen this firsthand—from early projects where we just “made it work” with whatever Dockerfile we had, to larger systems where the cost of a bad image multiplied across services. My name is Bao. After working on several real-world projects and going through lots of trial and error. I’ve gathered a handful of practical best practices to optimize Dockerfile that I’d love to share with you. Whether you’re refining a production-grade image or just curious about what you might be missing. Let me walk you through how I approach Docker optimization. Hopefully it’ll save you time, headaches, and a few docker build rage moments 😅. Identifying Inefficiencies in Dockerfile: A Case Study Below is the Dockerfile we’ll analyze: Key Observations: 1. Base Image: The Dockerfile uses ubuntu:latest, which is a general-purpose image. While versatile, it is significantly larger compared to minimal images like ubuntu:slim or Node.js-specific images like node:20-slim, node:20-alpine. 2. Redundant Package Installation: Tools like vim, wget, and git are installed but may not be necessary for building or running the application. 3. Global npm Packages: Pages like nodemon, ESLint, and prettier are installed globally. These are typically used for development and are not required in a production image. 4. Caching Issues: COPY . . is placed before npm install, invalidating the cache whenever any application file changes, even if the dependencies remain the same. 5. Shell Customization: Setting up a custom shell prompt (PS1) is irrelevant for production environments, adding unnecessary steps. 6. Development Tool in Production: The CMD uses nodemon, which is a development tool, to run the application Optimized your Docker Image Here’s how we can optimize the Dockerfile step by step. Showing the before and after for each section with the result to clearly distinguish the improvements. 1. Change the Base Image Before: FROM ubuntu:latest RUN apt-get update && apt-get install -y curl && curl -fsSL https://deb.nodesource.com/setup_20.x | bash - && \ apt-get install -y nodejs Use ubuntu:latest, a general-purpose image that is large and includes many unnecessary tools. After: FROM node:20-alpine Switches to node:20-alpine, a lightweight image specifically tailored for Node.js applications. Result: With the first change being applied, the image size is drastically reduced by about ~200MB.  2. Simplify Installed Packages Before: RUN apt-get update && apt-get install -y \ curl \ wget \ git \ vim \ python3 \ make \ g++ && \ curl -fsSL https://deb.nodesource.com/setup_20.x | bash - && \ apt-get install -y nodejs Installs multiple tools (curl, wget, vim, git) and Node.js manually, increasing the image size and complexity. After: RUN apk add --no-cache python3 make g++ Uses apk (Alpine’s package manager) to install only essential build tools (python3, make, g++). Result: The image should be cleaner and smaller after removing the unnecessary tools, packages. (~250MB vs ~400MB with the older version) 3. Leverage Dependency Caching Before: COPY . . RUN npm install Copies all files before installing dependencies, causing cache invalidation whenever any file changes, even if dependencies remain unchanged. After: COPY package*.json ./ RUN npm install --only=production COPY . . Copies only package.json and package-lock.json first, ensuring that dependency installation is only re-run when these files change.Installs only production dependencies (--only=production) to exclude devDependencies. Result: Faster rebuilds and a smaller image by excluding unnecessary files and dependencies. 4. Remove Global npm Installations Before: RUN npm install -g nodemon eslint pm2 typescript prettier Installs global npm packages (nodemon, eslint, pm2, ect.) that are not needed in production, increasing image size. After: Remove Entirely: Global tools are omitted because they are unnecessary in production. Result: Reduced image size and eliminated unnecessary layers. 5. Use a Production-Ready CMD Before: CMD ["nodemon", "/app/bin/www"] Uses nodemon, which is meant for development, not production. Result: A streamlined and efficient startup command. 6. Remove Unnecessary Shell Customization Before: ENV PS1A="💻\[\e[33m\]\u\[\e[m\]@ubuntu-node\[\e[36m\][\[\e[m\]\[\e[36m\]\w\[\e[m\]\[\e[36m\]]\[\e[m\]: " RUN echo 'PS1=$PS1A' >> ~/.bashrc Sets and applies a custom shell prompt that has no practical use in production After: Remove Entirely: Shell customization is unnecessary and is removed. Result: Cleaner image with no redundant configurations or layers. Final Optimized Dockerfile FROM node:20-alpine WORKDIR /app RUN apk add --no-cache python3 make g++ COPY package*.json ./ RUN npm install --only=production COPY . . EXPOSE 3000 CMD ["node", "/app/bin/www"] 7. Leverage Multi-Stage Builds to Separate Build and Runtime In many Node.js projects, you might need tools like TypeScript or linters during the build phase—but they’re unnecessary in the final production image. That’s where multi-stage builds come in handy. Before: Everything—from installation to build to running—happens in a single image, meaning all build-time tools get carried into production. After: You separate the "build" and "run" stages, keeping only what’s strictly needed at runtime. Result: Smaller, cleaner production imageBuild-time dependencies are excludedFaster and safer deployments Final Optimized Dockerfile # Stage 1 - Builder FROM node:20-alpine AS builder WORKDIR /app RUN apk add --no-cache python3 make g++ COPY package*.json ./ RUN npm install --only=production COPY . . # Stage 2 - Production FROM node:20-alpine WORKDIR /app COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app ./ EXPOSE 3000 CMD ["node", "/app/bin/www"] Bonus. Don’t Forget .dockerignore Just like .gitignore, the .dockerignore file excludes unnecessary files and folders from the Docker build context (like node_modules, .git, logs, environment files, etc.). Recommended .dockerignore: node_modules .git *.log .env Dockerfile.dev tests/ Why it matters: Faster builds (Docker doesn’t copy irrelevant files)Smaller and cleaner imagesLower risk of leaking sensitive or unnecessary files Results of Optimization 1. Smaller Image Size: The switch to node:20-alpine and removal of unnecessary packages reduced the image size from 1.36GB, down to 862MB. 2. Faster Build Times: Leveraging caching for dependency installation speeds up rebuilds significantly.Build No Cache:Ubuntu (Old Dockerfile): ~126.2sNode 20 Alpine (New Dockerfile): 78.4sRebuild With Cache (After file changes):Ubuntu: 37.1s (Re-run: npm install)Node 20 Alpine: 8.7s (All Cached) 3. Production-Ready Setup: The image now includes only essential build tools and runtime dependencies, making it secure and efficient for production. By following these changes, your Dockerfile is now lighter, faster, and better suited for production environments. Let me know if you’d like further refinements! Conclusion Optimizing your Dockerfile is a crucial step in building smarter, faster, and more efficient containers. By adopting best practices: such as choosing the right base image, simplifying installed packages, leveraging caching, and using production-ready configurations, you can significantly enhance your build process and runtime performance. In this article, we explored how small, deliberate changes—like switching to node:20-alpine, removing unnecessary tools, and refining dependency management—can lead to.

              08/07/2025

              105

              Bao Dang D. Q.

              How-to

              +1

              • Knowledge

              Build Smarter: Best Practices for Creating Optimized Dockerfile

              08/07/2025

              105

              Bao Dang D. Q.

              Customize software background

              Want to customize a software for your business?

              Meet with us! Schedule a meeting with us!