feat: backthink
parent
1e954b702b
commit
14a3b56de6
|
|
@ -99,6 +99,131 @@
|
|||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
In ZaloPay, each team has its own responsibilites/domains, aka many
|
||||
different services.
|
||||
</p>
|
||||
<p>
|
||||
Ideally each team can choose custom backend techstack if they want, but
|
||||
mostly boils down to Java or Go. Some teams use Python for scripting, data
|
||||
processing, ...
|
||||
</p>
|
||||
<p>
|
||||
<em>Example</em>: UM (Team User Management Core) has 10+ Java services and
|
||||
30+ Go services.
|
||||
</p>
|
||||
<p>
|
||||
The question is for each new business requirements, what should we do:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Create new services with new APIs?</li>
|
||||
<li>Add new APIs to existing services?</li>
|
||||
<li>Update existing APIs?</li>
|
||||
<li>Change configs?</li>
|
||||
<li>Don't do anything?</li>
|
||||
</ul>
|
||||
<p>
|
||||
<em>Example</em>: Business requirements says: Must match/compare user EKYC
|
||||
data with Bank data (name, dob, id, ...). TODO
|
||||
</p>
|
||||
<p>TODO: How to split services?</p>
|
||||
<h2>
|
||||
<a
|
||||
id="user-content-technically-side"
|
||||
class="anchor"
|
||||
aria-hidden="true"
|
||||
tabindex="-1"
|
||||
href="#technically-side"
|
||||
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
||||
>Technically side
|
||||
</h2>
|
||||
<p>How do services communicate with each other?</p>
|
||||
<p>
|
||||
<strong>First</strong> is through API, this is the direct way, you send a
|
||||
request then you wait for response.
|
||||
</p>
|
||||
<p><strong>HTTP</strong>: GET/POST/...</p>
|
||||
<p><em>Example</em>: TODO use curl</p>
|
||||
<p><strong>GRPC</strong>: use proto file as constract.</p>
|
||||
<p><em>Example</em>: TODO: show sample proto file</p>
|
||||
<p>
|
||||
There are no hard rules on how to design APIs, only some best practices,
|
||||
like REST API, ...
|
||||
</p>
|
||||
<p>Correct answer will always be: "It depends". Depends on:</p>
|
||||
<ul>
|
||||
<li>
|
||||
Your audience (android, ios, web client or another internal service)
|
||||
</li>
|
||||
<li>Your purpose (allow to do what?)</li>
|
||||
<li>Your current techstack (technology limitation?)</li>
|
||||
<li>Your team (bias, prefer, ...?)</li>
|
||||
<li>...</li>
|
||||
</ul>
|
||||
<p>Why do we use HTTP for Client-Server and GRPC for Server-Server?</p>
|
||||
<ul>
|
||||
<li>
|
||||
HTTP for Client-Server is pretty standard. Easy for client to debug, ...
|
||||
</li>
|
||||
<li>
|
||||
Before ZaloPay switch to GRPC for Server-Server, we use HTTP. The reason
|
||||
for switch is mainly performance.
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
Take a look at
|
||||
<a href="https://stripe.com/docs/api" rel="nofollow">stripe API</a> to get
|
||||
quick grasp about real world API.
|
||||
</p>
|
||||
<p>My own experiences:</p>
|
||||
<ul>
|
||||
<li>
|
||||
Whatever you design, you stick with it consistently. Don't use different
|
||||
name for same object/value in your APIs.
|
||||
</li>
|
||||
<li>
|
||||
Don't trust client blindly, everything can be fake, everything must be
|
||||
validated. We can not know the request is actually from our client or
|
||||
some hacker computer. (Actually we can but this is out of scope, and
|
||||
require lots of advance work)
|
||||
</li>
|
||||
<li>
|
||||
Don't delete/rename/change old fields because you want and you can,
|
||||
please think it through before do it. Because back compability is very
|
||||
hard, old apps should continue to function if user don't upgrade. Even
|
||||
if we rollout new version, it takes time.
|
||||
</li>
|
||||
</ul>
|
||||
<h2>
|
||||
<a
|
||||
id="user-content-bonus"
|
||||
class="anchor"
|
||||
aria-hidden="true"
|
||||
tabindex="-1"
|
||||
href="#bonus"
|
||||
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
||||
>Bonus
|
||||
</h2>
|
||||
<p>TODO</p>
|
||||
<h2>
|
||||
<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
|
||||
</h2>
|
||||
<ul>
|
||||
<li>
|
||||
<a
|
||||
href="https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/"
|
||||
rel="nofollow"
|
||||
>Best practices for REST API design</a
|
||||
>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<div>
|
||||
Feel free to ask me via
|
||||
|
|
|
|||
|
|
@ -23,3 +23,82 @@ After successfully do all of that, next step is:
|
|||
- Log
|
||||
- Metrics
|
||||
- Tracing
|
||||
|
||||
In ZaloPay, each team has its own responsibilites/domains, aka many different
|
||||
services.
|
||||
|
||||
Ideally each team can choose custom backend techstack if they want, but mostly
|
||||
boils down to Java or Go. Some teams use Python for scripting, data processing,
|
||||
...
|
||||
|
||||
_Example_: UM (Team User Management Core) has 10+ Java services and 30+ Go
|
||||
services.
|
||||
|
||||
The question is for each new business requirements, what should we do:
|
||||
|
||||
- Create new services with new APIs?
|
||||
- Add new APIs to existing services?
|
||||
- Update existing APIs?
|
||||
- Change configs?
|
||||
- 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?
|
||||
|
||||
## Technically side
|
||||
|
||||
How do services communicate with each other?
|
||||
|
||||
**First** is through API, this is the direct way, you send a request then you
|
||||
wait for response.
|
||||
|
||||
**HTTP**: GET/POST/...
|
||||
|
||||
_Example_: TODO use curl
|
||||
|
||||
**GRPC**: use proto file as constract.
|
||||
|
||||
_Example_: TODO: show sample proto file
|
||||
|
||||
There are no hard rules on how to design APIs, only some best practices, like
|
||||
REST API, ...
|
||||
|
||||
Correct answer will always be: "It depends". Depends on:
|
||||
|
||||
- Your audience (android, ios, web client or another internal service)
|
||||
- Your purpose (allow to do what?)
|
||||
- Your current techstack (technology limitation?)
|
||||
- Your team (bias, prefer, ...?)
|
||||
- ...
|
||||
|
||||
Why do we use HTTP for Client-Server and GRPC for Server-Server?
|
||||
|
||||
- HTTP for Client-Server is pretty standard. Easy for client to debug, ...
|
||||
- Before ZaloPay switch to GRPC for Server-Server, we use HTTP. The reason for
|
||||
switch is mainly performance.
|
||||
|
||||
Take a look at [stripe API](https://stripe.com/docs/api) to get quick grasp
|
||||
about real world API.
|
||||
|
||||
My own experiences:
|
||||
|
||||
- Whatever you design, you stick with it consistently. Don't use different name
|
||||
for same object/value in your APIs.
|
||||
- Don't trust client blindly, everything can be fake, everything must be
|
||||
validated. We can not know the request is actually from our client or some
|
||||
hacker computer. (Actually we can but this is out of scope, and require lots
|
||||
of advance work)
|
||||
- Don't delete/rename/change old fields because you want and you can, please
|
||||
think it through before do it. Because back compability is very hard, old apps
|
||||
should continue to function if user don't upgrade. Even if we rollout new
|
||||
version, it takes time.
|
||||
|
||||
## Bonus
|
||||
|
||||
TODO
|
||||
|
||||
## References
|
||||
|
||||
- [Best practices for REST API design](https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue