Back to front – Backend technologies for the frontend developer

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

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

The following table lists the standard Cache-Control directives: Request Response Request Response max-age max-age

must-revalidate max-stale

proxy-revalidate min-fresh

must-understand

s-maxage

private no-cache no-cache

public no-store no-store

immutable no-transform no-transform

stale-while-revalidate only-if-cached

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

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

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