title | marp | theme | paginate | footer |
---|---|---|---|---|
Back to front |
true |
tech-training |
false |
![w:20px](./images/mastodon.png) @[email protected] |
<iframe src="inlines/word-cloud-android.html" height="80%" width="100%" frameBorder="0"></iframe>
<iframe src="inlines/word-cloud-backend.html" height="80%" width="100%" frameBorder="0"></iframe>
There are only two hard things in Computer Science: cache invalidation and naming things.
Phil Karlton
<iframe src="inlines/caching-expiry-1.svg" height="80%" width="100%" frameBorder="0"></iframe>
<iframe src="inlines/caching-expiry-2.svg" height="80%" width="100%" frameBorder="0"></iframe>
Example
Expires: Wed, 21 Oct 2015 07:28:00 GMT
Example
Cache-Control: max-age=604800
The following table lists the standard Cache-Control directives:
Request | Response |
---|---|
max-age | max-age |
max-stale | - |
min-fresh | - |
- | s-maxage |
no-cache | no-cache |
no-store | no-store |
no-transform | no-transform |
only-if-cached | - |
Request | Response |
---|---|
- | must-revalidate |
- | proxy-revalidate |
- | must-understand |
- | private |
- | public |
- | immutable |
- | stale-while-revalidate |
stale-if-error | stale-if-error |
The ETag (or entity tag) HTTP response header is an identifier for a specific version of a resource. It lets caches be more efficient and save bandwidth, as a web server does not need to resend a full response if the content was not changed.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag
Example
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
<iframe src="inlines/caching-expiry-3.svg" height="80%" width="100%" frameBorder="0"></iframe>
Example
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
<iframe src="inlines/caching-etag-1.svg" height="80%" width="100%" frameBorder="0"></iframe>
<iframe src="inlines/caching-etag-2.svg" height="80%" width="100%" frameBorder="0"></iframe>
Example:
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
<iframe src="inlines/caching-cdn-1.svg" height="80%" width="100%" frameBorder="0"></iframe>
<iframe src="inlines/caching-multilayered.svg" height="90%" width="100%" frameBorder="0"></iframe>
Give it a REST
REST is a set of architectural constraints, not a protocol or a standard. API developers can implement REST in a variety of ways.
Oh CRUD
https://my.awesome/api/people/1/addAddress
https://my.awesome/api/people/1/getAddress
https://my.awesome/api/people/1/changeAddress
https://my.awesome/api/people/1/deleteAddress
https://my.awesome/api/people/1/
add
Address
https://my.awesome/api/people/1/
get
Address
https://my.awesome/api/people/1/
change
Address
https://my.awesome/api/people/1/
delete
Address
POST
https://my.awesome/api/people/1/
address
GET
https://my.awesome/api/people/1/
address
PUT
https://my.awesome/api/people/1/
address
DELETE
https://my.awesome/api/people/1/
address
If you ever see this in your api:
https://something.or.other/login?username=rick&password=pickle
😱 from the mountaintops
wtj?
oh oh ffff...
Remember this?
https://something.or.other/login?username=rick&password=pickle
<iframe src="inlines/web-api-design-oauth-1.svg" height="90%" width="100%" frameBorder="0"></iframe>
<iframe src="inlines/web-api-design-oauth-2.svg" height="90%" width="100%" frameBorder="0"></iframe>
<iframe src="inlines/web-api-design-oauth-3.svg" height="90%" width="100%" frameBorder="0"></iframe>
If we follow the REST principles in designing our APIs, we will have automatically idempotent REST APIs for GET, PUT, DELETE, HEAD, OPTIONS, and TRACE methods. Only POST APIs will not be idempotent.
POST
is NOT idempotent.
GET
, PUT
, DELETE
, HEAD
, OPTIONS
and TRACE
are idempotent.
<iframe src="inlines/service-topology-microservices-monolith.svg" height="80%" width="100%" frameBorder="0"></iframe>
<iframe src="inlines/service-topology-microservices-micro.svg" height="80%" width="100%" frameBorder="0"></iframe>
<iframe src="inlines/service-topology-microservices-micro-regions.svg" height="40%" width="100%" frameBorder="0"></iframe>
https://my.awesome.service/home
https://my.awesome.service/product/123
https://my.awesome.service/search?q=jeans
Image by Peggy und Marco Lachmann-Anke from Pixabay
- Edge workers
- Functions
- Message queues - Event Driven Architecture
- Optimistic Locking
- Eventual Consistency
- NoSQL
- Non blocking sysIO
- Round Robin
- Encryption at rest/In transit - End to End Encryption
- Salting
- Eventual Consistency