Lập trình smart contract trên máy ảo Ethereum–EVM– cho phép lập trình viên sử dụng assembly để có thể can thiệp ở mức sâu hơn mà đôi khi sử dụng solidity đơn thuần không thực hiện được hoặc một số tính toán có thể tối ưu lượng gas cần sử dụng để giảm chi phí giao dịch. Và nó cũng là con dao hai lưỡi nếu chúng ta sử dụng mà không nắm rõ về nó.

Quay lại về việc gọi qua lại giữa các smart contract khác nhau, cả 3 cách gọi call, delegatecall và static call đều có thể thực hiện bằng solidity hoặc assembly; tuỳ vào tình huống mà chúng ta sử dụng cách thức hợp lý hơn. Mục đích của bài viết này là phân biệt sự khác nhau và giống nhau giữa 3 cách gọi đã kể ở trên.

call

Thông thường, nếu chúng ta import một contract này vào source code của contract khác thì việc call trờ nên rất tự nhiên như chúng ta vẫn làm trong các ngôn ngữ lập trình truyền thống khác.

Một vi dụ đơn giản như sau, chúng ta có một contract để lưu giữ thông tin

Chúng ta muốn deploy một contract Machine sẽ gọi đến contract Storage.

Dễ nhận thấy rằng, ở dòng số #3 import "./Storage.sol"; , contract Storage được import trực tiếp vào contract Machine và khi deploy contract Machine thì contract Storage cũng được deploy cùng luôn, contract Machine tham chiếu trực tiếp đến contract Storage nên việc call các method của contract Storage từ contract Machine được thực hiện đơn giản như ở dòng #14 s.setValue(x); và giá trị được thay đổi cho dù được truyền vào qua tham số và được thực thi ở contract Machine nhưng trạng thái thay đổi được phản ánh vào contract Storage.

Tuy nhiên, nếu trong trường hợp để tiết kiệm chi phí hoặc có thể do một số yêu cầu đặc biệt của dư án thì contract Storage có thể được deploy một cách độc lập với contract Machine. Tuỳ vào từng trường hợp thì chúng ta có thể lựa chọn 1 trong 2 cách sau đây:

1. Sử dụng interface
2. Sử dụng hàm call

Sử dụng interface

Interface của solidity không khác gì interface ở các ngôn ngữ lập trình phổ biến nên cũng không cần thiết phải gỉải thích lại ở bài viết này. Bằng cách sử dụng interface, chúng ta vẫn có thể call các method của contract Storage mà không cần import code của nó vào contract Machine. Cụ thể cách thức implement cho contract Machine có thể như sau:

Sử dụng hàm call

Không phải lúc nào chúng ta cũng có thể sử dụng interface vì trong nhiều trường hợp, chúng ta không biết trước được ABI của contract, chúng ta chỉ có thông tin này lúc runtime thì gần như bắt buộc chúng ta phải sử dụng đến hàm call để gọi đến method của một smart contract độc lập khác.

Thực chất thì EVM kích hoạt một lời gọi hàm của smart contract qua một chuỗi byte; trong đó, 4 byte đầu tiên của hash từ giá trị của method signature, tiếp sau đó mà các chuỗi có độ dài cố định là 32 bytes. Chúng ta có thể thấy rõ khi xem chi tiết giao dịch trên etherscan

MethodID: 0x2d2da806 chính là 4 bytes đầu tiên của giá trị hash keccak-256 của method signature depositETH(address). Nếu muốn bạn có thể kiểm tra bằng cách sử dụng công cụ hash keccak-256 online

[0]: 000000000000000000000000e105ba42b66d08ac7ca7fc48c583599044a6dab3 giá trị tiếp sau đó là input data của method dưới dạng chuỗi các số 32 bytes và được đánh số từ 0.

Chính vì vậy mà khi sử dụng hàm call chúng ta cũng phải tính toán MethodID theo đúng mô tả ở trên mà truyền vào tham số tương ứng của hàm call để có thể gọi được method mong muốn của smart contract nào đó. Quay lại ví dụ ở trên thì chúng ta có thể cài đặt contract Machine như sau

delegatecall

Khi sử dụng call thì msg.sender không phải là sender ban đầu mà khi đó sender được thay đổi thành caller contract. Như ở ví dụ trên thì sender là contract Machine và state được thay đổi nằm ở context của contract Storage. Nhưng khi sử dụng delegatecall thì msg.sender được giữ nguyên như ban đầu không thay đổi và state thay đổi ở context của Manchine, chỉ mượn code của Storage rồi thực thi trên context của contract Machine.

delegatecall hay được sử dụng trong proxy pattern, khi mà implement logic code chung ở một contract độc lập và contract để lưu state của mỗi người dùng thì được lưu riêng biệt ở contract proxy. Và có thể thay đổi hay upgrade logic code bằng cách thay đổi logic code của contract độc lập và trỏ lại implement contract ở contract proxy.

Ví dụ một proxy contract có thể được cài đặt sử dụng delegatecall ở dòng thứ 18 như sau

staticcall

staticcall thì cơ bản giống với callcall chỉ khác là staticcall không cho phép thay đổi state của smart contract.

call vs delegatecall vs staticcall was originally published in AgileB.it on Medium, where people are continuing the conversation by highlighting and responding to this story.

Git là công cụ quản lý mã nguồn tốt và đang được sử dụng miễn phí rộng rãi là điều không phải bàn cãi. Git cung cấp một bộ lệnh cực kỳ mạnh mẽ và tiện dụng để có thể đáp ứng nhu cầu phát triển phần mềm của các dự án từ nhỏ đến lớn.

Trong cuộc sống nói chung ai cũng có lúc mắc sai lầm; nhưng quan trọng là chúng ta sớm nhận ra được sai lầm đó, cố gắng hết sức để tìm cách khắc phục, sửa chữa và thay đổi để có được kết quả cuối cùng tốt nhất. Và trong việc xây dựng và phát triển phần mềm cũng vậy. Ngày qua ngày, chúng ta vẫn miệt mài tạo ra những thay đổi với mong muốn tạo ra thêm nhiều tính năng hay, tính năng mới và phù hợp hơn cho khách hàng. Những thay đổi đó đôi khi không phải là những thay đổi mà chúng ta cần nên việc có thể quay ngược lại thời gian để có thể nhanh chóng sửa chữa và lấy lại được phần chính xác nhất cho dự án là việc rất cần thiết. Git cho phép chúng ra làm điều đó một cách nhanh chóng và dễ dàng.

Theo thiển ý của tôi thì chúng ta thường có 3 cách để quay ngược thời gian với Git.

1. Sử dụng git commit --amend để thay đổi commit gần nhất
2. Sử dụng git revert để huỷ bỏ thay đổi của một commit cụ thể nào đó
3. Sử dụng git rebase -i để có thể thay đổi nhiều commit một lúc theo ý muốn.

Tuy nhiên, cả 3 câu lệnh ở trên chúng ta thường chỉ làm việc trên git logs của repository mà ít khi làm việc với toàn bộ lịch sử thao tác mà chúng ra đã thực hiện trên local repository. Để dễ hình dung hơn thì tôi sẽ đưa ra một tình huống sau đây.

Giả dụ trong một ngày bấn loạn, trải qua rất nhiều tranh luận và bàn bạc với các đội nhóm khác, bạn đã thực hiện git commit --amend 3 lần cho một commit quan trọng cần được release gấp lên production trong ngày hôm nay. Nhưng đến cuối ngày, sếp chốt một câu xanh rờn là nội dung commit lần thứ 2 là chính xác và cần deliver theo commit đó. Tất nhiên, nếu thay đổi của commit đó nhỏ, không đáng kể thì bạn có thể dễ dàng lấy lại. Nhưng nếu các lần amend code đều là những thay đổi lớn thì có cách nào để có thể nhanh chóng lấy lại commit đã amend ở lần thứ 2 hay không?

…

…

…

Câu trả lời là có, đó là sử dụng cỗ máy thời gian git reflog, git reflog ghi lại toàn bộ thao tác mà chúng ta đã thực hiện trên local repository nên sẽ có nhiều chi tiết và nhiều thời điểm hơn git log thông thường nên chúng ra dễ dàng quay lại được thời điểm mà chúng ta mong muốn.

Dưới đây là ví dụ minh hoạ cho sự khác biệt giữa git reflog và git log

git log chỉ có 2 commit như sau và chúng ra không biết được là commit cuối cùng cf5e6c0 là tổng hợp code của 3 lần amend commit.

% git log --oneline
cf5e6c0 (HEAD -> master) first commit of phase0
eb3a695 Initial commit

Chúng ta chỉ biết được điều đó nếu chúng ra sử dụng cỗ máy thời gian git reflog mà thôi.

% git reflog
cf5e6c0 (HEAD -> master) HEAD@{0}: commit (amend): first commit of phase0
ef31eda HEAD@{1}: commit (amend): first commit of phase0
e0570a6 HEAD@{2}: commit (amend): first commit of phase0
a651857 HEAD@{3}: commit: first commit of phase0
eb3a695 HEAD@{4}: clone: from git@github.com:git/specs.git

Các bạn có thể thấy là git reflog có nhiều và đầy đủ thông tin hơn rất nhiều git log.

Mong rằng kiến thức nho nhỏ này sẽ giúp các bạn có thể dễ dàng hơn trong việc xử lý những thay đổi code bất thường và gấp gáp.

Happy git, happy code!

Ngược dòng lịch sử cùng cỗ máy thời gian git reflog was originally published in AgileB.it on Medium, where people are continuing the conversation by highlighting and responding to this story.

Gần đây do đặc thù công việc nên thường xuyên phải kiểm tra dữ liệu trong postgesql db. Bản thân tôi rất ngại cài đặt các công cụ GUI nên vẫn ưu tiên dùng CLI hơn. Mặc định khi cài đặt postgresql thì đã có sẵn psql để kết nối đến database rồi. Để kết nối đến một db đã có sẵn trong postgresql thì bạn chỉ cần chạy lệnh sau trên console

$ psql --dbname furbar

Nếu không chỉ định --dbname thì psql sẽ kết nối đến db có name trùng với tên đang truy cập, nên nếu db đó không tồn tại thì psql sẽ báo lỗi kiểu kiểu như sau

psql: error: could not connect to server: FATAL:  database "guest" does not exist

Sau khi kết nối db thành công console sẽ chuyển sang prompt của psql và sẵn sàng nhận các lệnh làm việc với db.

Tất nhiên, bạn hoàn toàn có thể dùng lệnh \? để xem hướng dẫn sử dụng các lệnh làm việc của psql. Tuy nhiên, khi mới sử dụng thì cũng khá bối rối nên các bạn có thể xem qua các lệnh, mà tôi nghĩ là hay được sử dụng, sau đây để làm việc với postgresql được nhanh hơn.

1. \l hoặc \l+ Hiển thị các database đang có trong postgresql db
2. \c dbname Kết nối hoặc thay đổi db cần làm việc
3. \dn Liệt kê toàn bộ schema có trong db hiện tại
4. set search_path to schema_name chỉ định schema làm việc
5. \dt Liệt kê toàn bộ tên bảng có trong schema hiện tại
6. \d table_name hoặc \d+ table_name Xem chi tiết table definition
7. \q hoặc ctrl + d thoát khỏi phiên làm việc cùa psql

Sau khi đã chỉ định chính xác schema cần làm việc rồi thì chúng ta có thể sử dụng các câu lệnh query để truy vấn và xem dữ liệu ở các table như ý muốn. Nếu dữ liệu dài và khó xem thì bạn có thể sử dụng thêm \x on hoặc \x auto thì dữ liệu sẽ được hiển thị dễ nhìn hơn rất nhiều.

Hy vọng là các câu lệnh psql trên sẽ giúp các bạn làm quen và làm việc với postgresql được dễ dàng hơn.

Một số lệnh hay dùng khi làm việc với postgresql was originally published in AgileB.it on Medium, where people are continuing the conversation by highlighting and responding to this story.

Một thách thức thú vị cho các HLV và các nhà khoa học thể thao phải đối mặt là làm sao có thể giải thích được cho các VĐV một cách ngắn gọn và dễ hiểu về mục đích và lợi ích của mỗi bài tập. Các đơn giản và phổ biến nhất là chỉ đưa ra những thông tin hữu ích để tối ưu các bài tập cho các VĐV. Tuy nhiên, nếu chúng ta giải thích quá đơn giản thì thường dẫn đến hiểu sai hoặc hiểu nhầm. Và đáng tiếc là rất nhiều VĐV đã hiểu nhầm về lactate.

Lactate hay axit lactic được cho là nhân tố gây ra cảm giác mệt mỏi cho các cơ vận động là cách giải thích nghe có vẻ khá hợp lý và dễ hiểu cho các quá trình phức tạp xảy ra bên trong cơ thể. Bởi vì lactate sẽ tăng lên khi các bài tập cường độ cao tăng, và khi hoạt động ở cường độ cao thì cảm giác mệt mỏi cũng sẽ xuất hiện thường xuyên hơn nên một vài người đã cho rằng lactate gây ra cảm giác mệt mỏi cho cơ thể. Nếu như chúng ta không hiểu rõ về nhịp tim thì chúng ta cũng sẽ nghĩ rằng có một sư liên quan tương tự giữa nhịp tim và cảm giác mệt mỏi. Cả nhịp tim lẫn sự mệt mỏi đều tăng lên khi chúng ra hoạt động ở cường độ cao, nhưng chúng ta đều biết rằng nhịp tim không hề gây ra mệt mỏi. Và sự thật là lactate cũng vậy, nó không phải là nguyên nhân gây ra cảm giác mệt mỏi.

Để hiểu thêm về lactate thì chúng ta cần tìm hiểu sơ qua về sinh hoá và sinh lý học. Tuy nhiên, cũng có khá nhiều cuốn sách giáo khoa về sinh lý học cung cấp kiến thức về lactate đã lỗi thời. Nhưng có một thông tin thú vị là các nghiên cứu gần đây đã giúp chúng ta có thể hiểu rõ hơn và sự trao đổi chất của lactate bên trong cơ thể.

Cơ thể con người sử dụng một vài quá trình trao đổi chất khác nhau để cung cấp năng lượng cho các cơ hoạt động. Mỗi một quá trình trao đổi chất lại chuyển hoá các dạng năng lượng khác nhau sang phân tử ATP (Adenosine triphosphate), một dạng phân tử năng lượng cao giúp các sợi cơ có thể co dãn.

Có ba cách thức trao đổi chất chính trong cơ thể con người là aerobic (hiếu khí), anaerobic (hiếm khí) và phosphocreatine (CP-ATP). Trong đó, phosphocreatine là cách thức trao đổi chất diễn ra nhanh nhất, có thể cung cấp năng lượng cho cơ thể rất nhanh chỉ trong vòng vài giây đồng hồ.

Trao đổi chất aerobic thì lại là quá trình phức tạp nhất và cung cấp cho cơ thể nhiều năng lượng nhất. Và quá trình này sử dụng gần như toàn bộ các nguồn cung cấp năng lượng có trong cơ thể con người (chất béo, chất đạm, đường glucoza và đặc biệt là có cả lactate). Chính về thế mà ai muốn giảm béo thì tập môn aerobic nhé. Sự chuyển đổi các nguồn năng lượng này sang ATP trải qua rất nhiều bước bên trong các tế bào cơ. Khí ôxy và năng lượng được truyền đến các ty thể (mitochondria) trong quá trình tổng hợp ATP hiếu khí. Trao đổi chất aerobic tuy là quá trình chậm nhất nhưng lại là quá trình trao đổi chất mang lại năng lượng hiệu quá nhất cho cơ thể.

Mặt khác, quá trình trao đổi chất anaerobic lại diễn ra khá nhanh, cung cấp ATP cho các cơ hoạt động mà không cần phải trải qua nhiều bước. Hơn nữa, nguồn năng lượng chính của nó là glycogen được lưu trữ bên trong và xung quanh ngay chính tại các cơ đó làm cho quá trình chuyển đổi sang ATP trở lên nhanh hơn. Quá trình này còn được gọi là quá trình bẻ gẫy đường glucoza (glycolysis).

Quá trình bẻ gãy đường glucoza tạo ra lactate và hydrogen. Nếu như lactate và hydrogen kết hợp với nhau thì tạo thành axit lactic. Tuy nhiên, chúng ta hiếm khi tìm thấy axit lactic trong máu, bởi vì lactate thường được giữ lại trong các tế bào hoặc được vận chuyển đến nhóm cơ và được sử dụng như một nguồn năng lượng tại các nhóm cơ đó. Khả năng sử dụng lactate như là một nguồn cung cấp năng lượng cho cơ thể được tối ưu thông qua các bài tập hiếu khí (aerobic), đặc biệt là các bài tập bền (endurance training).

Ngoài ra, lactate còn được vận chuyển đến não bộ, cung cấp năng lượng cho cơ tim, hoặc đến gan để chuyển đổi thành đường glucoza. Khi chúng ta hoạt động, cơ thể cần duy trì một lượng đường glucoza nhất định cho não bộ. Quá trình tổng hợp glucoza (gọi là gluconeogenesis) là một chức năng quan trọng của gan khi chúng ta hoạt động, và lactate có vai trò quan trọng nhất trong quá trình tổng hợp glucoza.

Trong khi đó thì sự tích tụ hyrogen (H+) từ quá trình bẻ gẫy glucoza làm giảm nồng độ pH, tức là tăng tính axit, phần lớn H+ được giữ tạm ở hệ thống đệm bicarbonate (H+ + HCO3- H2CO3 CO2 + H2O), và được chuyển thành H2O và CO2, CO2 thì được đào thải ra khỏi cơ thể thông qua phổi. Nếu tích tụ quá nhiều thì có một vài dấu hiệu chứng tỏ nó gây trở ngại cho các hoạt động co dãn của cơ. Tuy nhiên, các nghiên cứu gần đây thì lại cho thấy điều ngược lại. Quá trình bẻ gãy glucoza không phải là quá trình duy nhất làm tăng nồng độ axit trong cơ thể và sự tích tụ hydrogen cũng không phải là nhân tố tiềm năng duy nhất gây ra cảm giác mệt mỏi. Sự mệt mỏi khi cơ thể hoạt động quá tải là do các quá trình trao đổi chất khác như phốt phát vô cơ, và khả năng các cơ không thể bắt kịp được với tốc độ và áp lực co dãn mạnh do sự thiếu hụt Kali bên trong các tế bào cơ.

Lược dịch từ bài báo Lactate and lactic acid — dispelling the myths của tác giả Dario Fredrick.

Xua tan đi những hiểu lầm về lactate và axit lactic was originally published in AgileB.it on Medium, where people are continuing the conversation by highlighting and responding to this story.

Đầu năm 2016, tôi và các cộng sự ở Innovatube đã rất hứng khởi và thích thú với tìm hiểu và ứng dụng Golang cho các dự án mới. Các lập trình viên khi tiếp cận với Golang thì đều cảm giác rất thân quen và dễ dàng có thể code nhoay nhoáy trong vòng 2–3 ngày hay đến 1 tuần là cùng. Bởi Golang được thừa kế từ ngôn ngữ lập trình C mà ngôn ngữ lập trình Cthì chắc lập trình viên nào cũng được học và sử dụng trong trường đại học cả rồi. Đây cũng là ý kiến chủ quan của một lập trình viên tay ngang và thuộc thế hệ 8x như tôi. Ngôn ngữ C/C++ thì bản thân tôi cũng chưa được học bao giờ. Chẳng là hồi học đại học năm thứ nhất đại học, tôi vẫn tiếp tục hì hục ngồi code các bài toán trên ngôn ngữ lập trình Pascal, ngôn ngữ lập trình mà tôi đã được học từ năm lớp 10 ở trường PTTH, thằng bạn cùng lớp thấy thế nên nó bảo tôi: “Nếu mày muốn thành lập trình viên chuyên nghiệp thì kiểu gì mày cũng phải học C/C++”. Nên tôi và nó có mò lên hiệu sách trên phố sách đình đám nhất Hà Thành, phố Tràng Tiền, lê la khắp các hiệu sách để tìm mua 1 quyển lập trình C++ và sau đó có mua thêm một quyển lập trình Assembly của Peter Norton khá nổi tiếng và phổ biến những năm đó thì phải. Tôi vẫn nhớ như in là tôi đã rất ấn tượng với bìa sách hình chân dung ở tư thế đang khoanh tay trước ngực của Peter Norton. Một phong thái tự tin và rất thông minh.

Thời của tôi là vậy, các thế hệ Y sau này chắc sẽ không còn học C nữa, mà có thể là Haskell hay một ngôn ngữ nào mới mẻ khác mà chúng ta chưa biết. Các ngôn ngữ lập trình hiện đại thì ngày càng dễ dàng cho lập trình viên hơn. Các lập trình viên ở Google cho ra đời Golang chắc cũng nhằm mục đích đơn giản hoá việc lập trình trên ngôn ngữ C mà vẫn đạt được hiệu năng cao.

Hôm nay, tôi làm một code mẫu tạo REST API đơn giản bằng Golang để thấy được việc lập trình concurrency bằng Go nó trở nên đơn giản đến mức nào nếu so sánh với việc làm tương tự trên ngôn ngữ lập trình C/C++ hồi xưa. Tôi xin nhấn mạnh là C/C++ của thời ông bà anh nhé vì bản thân C/C++ vẫn đang phát triển và mới cho ra phiên bản năm 2017 có nhiều điểm mới mà tôi cũng không biết cụ thể nó là cái gì? Và ở một cách tiếp cận khác, gần đây các ngôn ngữ lập trình đều có thư viện reactive programming cũng khá thuận tiện cho việc xử lý các yêu cầu asynchronous nhằm tăng độ response của các ứng dụng. Tuy nhiên, tuỳ vào yêu cầu bài toán và cách thiết kế hệ thống mà chúng ta cần lựa chọn sử dụng cách tiếp cận nào cho phù hợp và thuận tiện hơn.

Yêu cầu của bài toán là viết một API trả về nhiệt độ trung bình từ nhiều nguồn số liệu của một thành phố. Thông thường, nếu sử dụng cách lập trình tuần tự thì chúng ra phải lấy nhiệt độ của thành phố của từng nguồn cung cấp rồi tính ra được nhiệt độ trung bình. Giả dụ chúng ta có 10 nguồn cung cấp số liệu và để lấy nhiệt độ của mỗi nguồn mất 1 giây thì tổng thời gian cho việc lấy nhiệt độ trung bình của API sẽ là 10 giây. Opsss, 10 giây, một thời gian khó có thể chấp nhận cho một API trả về kết quả.

Giải pháp để tăng hiệu năng cho API ở đây là sử dụng lập trình go concurrnecy kết hợp với channel để có thể cùng một lúc lấy được nhiệt độ của các nguồn cung cấp trong cùng một thời điểm. Kết quả là chúng ra chỉ cần, tương đối, 1 giây để có thể lấy được kết quả từ 10 hay nhiều nguồn số liệu khác nhau. Một sự khác biệt đáng kinh ngạc?

Cụ thể các bước tiến hành cài đặt như sau.

Trước tiên thì chúng ta định nghĩa một interface chung để lấy nhiệt độ của một thành phố từ các nguồn số liệu khác nhau

Vì mỗi nguồn số liệu có cách lấy số liệu khác nhau nên chúng ta cần khai báo các struct tương ứng để cài đặt. Ở đây để đơn giản thì tôi lấy từ 2 nguồn số liệu là OpenWeatherMap và apixu

Sau khi, đã có thể lấy được số liệu từ các nguồn cụ thể thì chúng ta sẽ sử dụng go concurrency và channel để cài đặt cách thức để lấy số liệu của các nguồn được diễn ra cùng một lúc để giảm thiểu thời gian chờ đợi.

Ở đây, các bạn có thể thấy việc gọi một method concurrency bằng Golang khá đơn giản, chỉ cần dùng từ khoá go trước lời gọi hàm mà thôi.

go func(p weatherProvider) {...}(provider)

Mỗi lời gọi này thì Go sẽ tạo riêng một goroutine chạy độc lập nhau nên việc lấy số liệu ở từng nguồn được thực hiện gần như đồng thời. Và các goroutine này sẽ giao tiếp với nhau thông qua channel nên chúng ta cũng định nghĩa một channel chung để có thể lưu trữ số liệu của các nguồn khác nhau ở cùng một channel.

temps := make(chan float64, len(w)) 
... 
... 
...  
temps <- k

Cuối cùng, thì tổng hợp lại chúng ta có thể expose thành một REST API thông qua hàm main() như sau

Như vậy, chúng ta có thể dễ dàng cài đặt một REST API hiệu quả bằng cách sử dụng go concurrency và channel. Source code mẫu các bạn có thể xem trên github: https://github.com/hadv/go-concurrency-rest-api

Đăng ký email tại đây để nhận được bài viết về công nghệ và khởi nghiệp của Innovatube hàng tuần.

Go concurrency rest api was originally published in AgileB.it on Medium, where people are continuing the conversation by highlighting and responding to this story.

Trong thời điểm hiện tại thì JSON REST API vẫn đang rất phổ biến và phổ thông nhất bởi tính dễ sử dụng của nó. Tuy nhiên, các hãng công nghệ lớn luôn luôn tìm kiếm những phương pháp mới để nâng cao hiệu năng cho sản phẩm của họ. Trong bài viết này, chúng ta sẽ tìm hiểu và khám phá về một framework RPC mới dựa trên protobufs và HTTP/2 của Google có tên là gRPC.

Một tính năng ưu việt của gRPC là sử dụng HTTP/2, cho phép chúng ta có thể đồng thời phát triển cả HTTP/1.1 REST+JSON API như thông thường và cả giao tiếp hiệu năng cao thông qua gRPC trên cùng một TCP port. Phiên bản Go1.6 thì đã kèm theo thư viện net/http2.

Chúng ra sẽ bắt đầu bằng việc sử dụng gRPC để xây dựng một ứng dụng lấy tên là EchoService bằng Golang. Ứng dụng này chỉ đơn giản là trả về chính nội dung message mà nó nhận được.

Cài đặt

Cài đặt ProtoBuffers 3.0

$ brew install — devel protobuf

Sau đó chạy `go get -u` để cài đặt một số thư viện `Golang` cần thiết khác

go get -u github.com/gengo/grpc-gateway/protoc-gen-grpc-gateway
go get -u github.com/gengo/grpc-gateway/protoc-gen-swagger
go get -u github.com/golang/protobuf/protoc-gen-go

Tạo một dịch vụ gRPC

Trước tiên, chúng ta mô tả ứng dụng trong file `service.proto` theo chuẩn proto3 như sau:

Trước khi cài đặt tính năng cho dịch vụ EchoService thì chúng ta cần chạy lệnh sau để tự động sinh ra các stub class cần thiết trong file `service.pb.go`

$ protoc -I/usr/local/include -I. \
 -I$GOPATH/src \
 -I$GOPATH/src/github.com/gengo/grpc-gateway/third_party/googleapis \
 — go_out=Mgoogle/api/annotations.proto=github.com/gengo/grpc-gateway/third_party/googleapis/google/api,plugins=grpc:. \
 service.proto

Sau đó, chúng ta có thể cài đặt EchoService như trong file `echo.go` sau.

Để kết nối đến với echo server trên thì chúng ra có thể cài đặt `EchoServiceClient` kết nối đến. Tuy nhiên, ở đây tôi bỏ qua bước này và chuyển sang tạo reverse-proxy cho kết nối thông qua REST JSON API. Để tạo ra reverse-proxy `service.pb.gw.go`, chúng ra chạy lệnh sau.

$ protoc -I/usr/local/include -I. \
 -I$GOPATH/src \
 -I$GOPATH/src/github.com/gengo/grpc-gateway/third_party/googleapis \
 — grpc-gateway_out=logtostderr=true:. \
 ./service.proto

Để tạo entry-point và khởi động server cho REST JSON API thì chúng ta tạo ra file `main.go` như sau

Sau khi build và khởi động server thì chúng ta có thể gọi REST API bằng lệnh `curl -X POST “http://localhost:8080/v1/example/echo/grpc"` và nhận được kết quả như sau

{“id”:”grpc”}

Ngoài ra, chúng ra có thể chạy lệnh sau để generate ra file service.swagger.json mô tả API theo chuẩn của Swagger.

$ protoc -I/usr/local/include -I. \
> -I$GOPATH/src \
> -I$GOPATH/src/github.com/gengo/grpc-gateway/third_party/googleapis \
> — swagger_out=logtostderr=true:. \
> ./service.proto

Chúng ta có thể xem mô tả API bằng cách mở file service.swagger.json trên Swagger Editor như hình sau.

Như vậy, cùng với protobuf và gRPC chúng ta có thể nhanh chóng tạo ra các API đồng thời cho HTTP/1.1 REST+JSON API và RPC dựa trên protobuf và HTTP/2.

Chi tiết về source code các bạn có thể xem trên github.

Sử dụng Protobuf và gRPC để phát triển API hiệu năng cao was originally published in AgileB.it on Medium, where people are continuing the conversation by highlighting and responding to this story.