Back to front Backend technologies for the frontend developer @geeky_android@androiddev.social
A presentation at Droidcon London in October 2022 in London, UK by Savvas Dalkitsis
Back to front Backend technologies for the frontend developer @geeky_android@androiddev.social
Who am I? Savvas Dalkitsis (he/him) Principal Software Engineer @ASOS @geeky_android@androiddev.social
ASOS
Why am I here? @geeky_android@androiddev.social
ad b An dro id @geeky_android@androiddev.social MVVMR Retrofit xJa v t a P MV er UI Pla l i H Da gg m o y Ro ose mp Co C te se Ma eba Fir le d gra Jet pa ck I MV ogle nes Go uti oro rial ite sql Studio
ng eri nd ~re de ~si ver ser n ind sql no co nta i ne rs jwt g kin loc ic~ ist tim op s dn ch ao s~m on key cd sal t uth oa ep ote nc y ingress~controller u ion q ~ ct e g un a s f s e m @geeky_android@androiddev.social es oki co ed non~blo ge cking ~ ~io g sw r e a t s ork eRt clu ers oun s e s d~ eu rob in
So what? @geeky_android@androiddev.social
Language barriers are real in tech too. Progressing your career means being able to have meaningful discussions with people outside your domain and comfort zone. A basic understanding of their language is paramount. Source: cartoonresource/Adobe Stock @geeky_android@androiddev.social
Let’s start @geeky_android@androiddev.social
Caching There are only two hard things in Computer Science: cache invalidation and naming things. Phil Karlton @geeky_android@androiddev.social
Caching Expiry headers @geeky_android@androiddev.social
@geeky_android@androiddev.social
@geeky_android@androiddev.social
Caching Server side controlled expiry @geeky_android@androiddev.social
Caching Server side controlled expiry Expires header Example Expires: Wed, 21 Oct 2015 07:28:00 GMT @geeky_android@androiddev.social
Caching Server side controlled expiry Cache-Control header Example Cache-Control: max-age=604800 @geeky_android@androiddev.social
stale-if-error stale-if-error _ https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control @geeky_android@androiddev.social
Caching ETags @geeky_android@androiddev.social
What is an ETag? 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 @geeky_android@androiddev.social
ETag = Unique Resource ID Example ETag: “33a64df551425fcc55e4d42a148795d9f25f89d4” @geeky_android@androiddev.social
Example If-None-Match: “33a64df551425fcc55e4d42a148795d9f25f89d4” @geeky_android@androiddev.social
ETag Mid air conflicts @geeky_android@androiddev.social
@geeky_android@androiddev.social
Example: If-Match: “33a64df551425fcc55e4d42a148795d9f25f89d4” @geeky_android@androiddev.social
Caching CD-eh? @geeky_android@androiddev.social
@geeky_android@androiddev.social
Caching Server side rendered pages @geeky_android@androiddev.social
@geeky_android@androiddev.social
Caching Multilayered caching @geeky_android@androiddev.social
@geeky_android@androiddev.social
Web Application/API Design @geeky_android@androiddev.social
Web Application/API Design REST Give it a REST @geeky_android@androiddev.social
REST is a set of architectural constraints, not a protocol or a standard. API developers can implement REST in a variety of ways. https://www.redhat.com/en/topics/api/what-is-a-rest-api @geeky_android@androiddev.social
Web Application/API Design HTTP Verbs Oh CRUD @geeky_android@androiddev.social
Does this look familiar? 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 @geeky_android@androiddev.social
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 @geeky_android@androiddev.social
HTTP verbs, REST resources nouns 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/ @geeky_android@androiddev.social address
Web Application/API Design Query parameters http://i.already/know?about=those @geeky_android@androiddev.social
TL;DR; If you ever see this in your api: https://something.or.other/login?username=rick&password=pickle from the mountaintops @geeky_android@androiddev.social
Web Application/API Design JWT wtj? @geeky_android@androiddev.social
@geeky_android@androiddev.social
Web Application/API Design OAuth oh oh ffff… @geeky_android@androiddev.social
Why OAuth? Remember this? https://something.or.other/login?username=rick&password=pickle @geeky_android@androiddev.social
@geeky_android@androiddev.social
@geeky_android@androiddev.social
@geeky_android@androiddev.social
Web Application/API Design Idempotency @geeky_android@androiddev.social
@geeky_android@androiddev.social
ETags 2 - Return of the UUID? @geeky_android@androiddev.social
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. https://restfulapi.net/idempotent-rest-apis/ @geeky_android@androiddev.social
Service topology @geeky_android@androiddev.social
Containers! Photo by Ian Taylor on Unsplash
@geeky_android@androiddev.social
Service topology Microservices @geeky_android@androiddev.social
@geeky_android@androiddev.social
@geeky_android@androiddev.social
@geeky_android@androiddev.social
Service topology DNS @geeky_android@androiddev.social
Service topology Clusters @geeky_android@androiddev.social
Service topology Traffic Managers / Ingress controllers @geeky_android@androiddev.social
https://my.awesome.service/home https://my.awesome.service/product/123 https://my.awesome.service/search?q=jeans @geeky_android@androiddev.social
Load balancers Image by Peggy und Marco Lachmann-Anke from Pixabay @geeky_android@androiddev.social
Service topology Multi-primary replication @geeky_android@androiddev.social
Chaos @geeky_android@androiddev.social
Honorable mentions @geeky_android@androiddev.social
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 @geeky_android@androiddev.social
Q&A Raffle @geeky_android@androiddev.social Slides https://github.com/ASOS/presentation-back-to-front
