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