Most-Loved Sketech Notes: API Architecture (163 โค๏ธ), Web App Architecture (65 ๐ฅ) and JWT (42 โญ) - Sketech #21
If you missed them, hereโs your chance to catch up.
Welcome to Sketech Free Edition #21!
Here are 3 of the most-loved Sketech notes on Substack:
API Architecture and Communication Styles โ A deep dive into API communication styles. ( 163 โค๏ธ)
Web App Architecture โ Key insights into building web application architecture. (65 ๐ฅ)
JWT: What They Are and How to Use Them โ The essentials of JSON Web Tokens and their implementation. ( 42 โญ)
If you missed them, hereโs your chance to catch up.
If you believe tech is exciting, challenging and epic, your like is what keeps this movement alive. Your heart โฅ๏ธ keeps this energy growing!
API Architecture and Communication Styles
When I first started working with APIs, I struggled to understand why there were so many ways to design them. Over time, I learned that both architectural styles and communication protocols can make a big difference in how systems interact and evolve.
Hereโs a look at six of the most common ones:
1/ RESTful
Standard HTTP methods, stateless communication.
Simple, scalable, widely supported.
Integrates with caching and HTTP tools.
2/ SOAP
XML-based, built-in error handling and security.
Enterprise-grade, reliable, robust.
Ideal for complex transactions.
3/ GraphQL
Query language, fetches only required data.
Flexible, reduces over/under-fetching.
Single endpoint, clear schema.
4/ gRPC
High-performance, Protocol Buffers serialization.
Lightweight, efficient, real-time communication.
Multi-language support.
5/ WebSockets
Persistent, bidirectional communication.
Ideal for real-time updates (e.g., chats).
Low latency, reduces server load.
6/ MQTT
Lightweight messaging protocol.
Designed for low-bandwidth, IoT devices.
Minimal bandwidth, reliable message delivery.
These six styles are among the most common, but there are others out there as well.
Would you add any that you think are important to the Visual? Let me know here
Web App Architecture
Back when I built my first web app, I thought, "How hard could it be? Frontend talks to backend, backend talks to a databaseโdone."
Days later, I was buried in failing requests and tangled components.
It quickly became clear: without understanding architecture, everything falls apart.
When I finally sat down to untangle that mess, I realized web app architecture isnโt just about connecting dots, itโs about creating a system that doesnโt crumble under real-world pressure. It all comes down to 3 foundational pillars:
Flow of Requests (DNS & Load Balancers)
Where does every user request start, and how do we ensure it reaches the right place without overwhelming the system?
Brains of the App (Backend Logic & Databases)
Where decisions are made, data is validated, and everything starts to make senseโor fall apart.
Keeping the System Healthy (Observability & Security)
Can you spot a problem before your users do? And can you stop threats before they become crises?
Every web app architecture lives or dies by these pillars. Nail these, and everything else becomes easier. Looking back, that tangled mess of requests and components was one of my best teachers.
If this breakdown made your mental diagram clearer, tap the โค โ it means a lot.
Is that heart yours ๐? Take a look here
How JWT Works
Iโve always been fascinated by the balance between ๐บ๐๐๐๐๐๐๐๐๐ ๐๐๐ ๐ท๐๐๐๐ ๐๐ ๐ป๐๐๐๐๐๐๐๐๐. Some tools, like JSON Web Tokens, manage to do so much with so little: compact, elegant and quietly essential ๐ค
Letโs unravel what makes JWTs so indispensable.
โ What is JWT?
JWT is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object.
Structure: Composed of three parts separated by dots (.) - Header, Payload, and Signature.
โ Components of JWT
Header: Contains metadata about the token, typically the type of token and the signing algorithm.json
{ "alg": "HS256", "typ": "JWT" }
Payload (Claims): Contains the actual data. This includes registered claims (like iss, exp, sub), public claims, or private claims.json
{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }
Signature: Ensures the token hasn't been tampered with. It's created by encoding the header and payload, then signing with a secret or private key.
โ How JWT Works
Token Creation: The server generates a JWT when the user logs in.
Token Transmission: This token is sent to the client (e.g., browser).
Token Usage: For subsequent requests, the client sends the JWT, which the server verifies before granting access.
โ Advantages
Stateless: Servers don't need to store session information.
Scalability: Ideal for distributed systems and microservices.
Flexibility: Can be used across different domains.
โ Security Considerations
Encryption vs Signing: JWTs are signed, not encrypted by default. Use JWE (JSON Web Encryption) for end-to-end encryption.
Token Expiry: Always set an expiration time to limit token lifetime.
Secure Transmission: Use HTTPS to prevent token interception.
โ Implementing JWT
Backend: Use libraries like jsonwebtoken in Node.js or PyJWT in Python.
Frontend: Store tokens in HTTP-only cookies or local storage with caution.
And this one ? Take a look here
A big thank you to everyone!
Enjoy your weekend, and Iโll catch you in the next edition!
Nina