feat: draft
parent
1be05f3a1f
commit
565c2ce314
|
@ -124,9 +124,8 @@
|
||||||
</ul>
|
</ul>
|
||||||
<p>
|
<p>
|
||||||
<em>Example</em>: Business requirements says: Must match/compare user EKYC
|
<em>Example</em>: Business requirements says: Must match/compare user EKYC
|
||||||
data with Bank data (name, dob, id, ...). TODO
|
data with Bank data (name, dob, id, ...).
|
||||||
</p>
|
</p>
|
||||||
<p>TODO: How to split services?</p>
|
|
||||||
<h2>
|
<h2>
|
||||||
<a
|
<a
|
||||||
id="user-content-technical-side"
|
id="user-content-technical-side"
|
||||||
|
@ -153,9 +152,9 @@
|
||||||
request then you wait for response.
|
request then you wait for response.
|
||||||
</p>
|
</p>
|
||||||
<p><strong>HTTP</strong>: GET/POST/...</p>
|
<p><strong>HTTP</strong>: GET/POST/...</p>
|
||||||
<p><em>Example</em>: TODO use curl</p>
|
<p><em>Example</em>: TODO: show API image</p>
|
||||||
<p><strong>GRPC</strong>: use proto file as constract.</p>
|
<p><strong>GRPC</strong>: use proto file as constract.</p>
|
||||||
<p><em>Example</em>: TODO: show sample proto file</p>
|
<p><em>Example</em>: TODO: show proto file image</p>
|
||||||
<p>
|
<p>
|
||||||
There are no hard rules on how to design APIs, only some best practices,
|
There are no hard rules on how to design APIs, only some best practices,
|
||||||
like REST API, ...
|
like REST API, ...
|
||||||
|
@ -180,16 +179,6 @@
|
||||||
for switch is mainly performance.
|
for switch is mainly performance.
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</ul>
|
||||||
<h4>
|
|
||||||
<a
|
|
||||||
id="user-content-references"
|
|
||||||
class="anchor"
|
|
||||||
aria-hidden="true"
|
|
||||||
tabindex="-1"
|
|
||||||
href="#references"
|
|
||||||
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
|
||||||
>References
|
|
||||||
</h4>
|
|
||||||
<h3>
|
<h3>
|
||||||
<a
|
<a
|
||||||
id="user-content-message-broker"
|
id="user-content-message-broker"
|
||||||
|
@ -252,11 +241,11 @@
|
||||||
</p>
|
</p>
|
||||||
<h3>
|
<h3>
|
||||||
<a
|
<a
|
||||||
id="user-content-references-1"
|
id="user-content-references"
|
||||||
class="anchor"
|
class="anchor"
|
||||||
aria-hidden="true"
|
aria-hidden="true"
|
||||||
tabindex="-1"
|
tabindex="-1"
|
||||||
href="#references-1"
|
href="#references"
|
||||||
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
||||||
>References
|
>References
|
||||||
</h3>
|
</h3>
|
||||||
|
@ -354,11 +343,11 @@
|
||||||
</p>
|
</p>
|
||||||
<h3>
|
<h3>
|
||||||
<a
|
<a
|
||||||
id="user-content-references-2"
|
id="user-content-references-1"
|
||||||
class="anchor"
|
class="anchor"
|
||||||
aria-hidden="true"
|
aria-hidden="true"
|
||||||
tabindex="-1"
|
tabindex="-1"
|
||||||
href="#references-2"
|
href="#references-1"
|
||||||
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
||||||
>References
|
>References
|
||||||
</h3>
|
</h3>
|
||||||
|
|
|
@ -43,9 +43,7 @@ The question is for each new business requirements, what should we do:
|
||||||
- Don't do anything?
|
- Don't do anything?
|
||||||
|
|
||||||
_Example_: Business requirements says: Must match/compare user EKYC data with
|
_Example_: Business requirements says: Must match/compare user EKYC data with
|
||||||
Bank data (name, dob, id, ...). TODO
|
Bank data (name, dob, id, ...).
|
||||||
|
|
||||||
TODO: How to split services?
|
|
||||||
|
|
||||||
## Technical side
|
## Technical side
|
||||||
|
|
||||||
|
@ -58,11 +56,11 @@ wait for response.
|
||||||
|
|
||||||
**HTTP**: GET/POST/...
|
**HTTP**: GET/POST/...
|
||||||
|
|
||||||
_Example_: TODO use curl
|
_Example_: TODO: show API image
|
||||||
|
|
||||||
**GRPC**: use proto file as constract.
|
**GRPC**: use proto file as constract.
|
||||||
|
|
||||||
_Example_: TODO: show sample proto file
|
_Example_: TODO: show proto file image
|
||||||
|
|
||||||
There are no hard rules on how to design APIs, only some best practices, like
|
There are no hard rules on how to design APIs, only some best practices, like
|
||||||
REST API, ...
|
REST API, ...
|
||||||
|
@ -81,8 +79,6 @@ Why do we use HTTP for Client-Server and GRPC for Server-Server?
|
||||||
- Before ZaloPay switch to GRPC for Server-Server, we use HTTP. The reason for
|
- Before ZaloPay switch to GRPC for Server-Server, we use HTTP. The reason for
|
||||||
switch is mainly performance.
|
switch is mainly performance.
|
||||||
|
|
||||||
#### References
|
|
||||||
|
|
||||||
### Message Broker
|
### Message Broker
|
||||||
|
|
||||||
**Second** way is by Message Broker, the most well known is Kafka.
|
**Second** way is by Message Broker, the most well known is Kafka.
|
||||||
|
|
Loading…
Reference in New Issue