Sketech #5 Code Smarter, not Harder: SOLID principles + API scaling hacks!

Get up to speed fast with a visual guide that breaks down complex code and API tricks— quick, simple and easy to follow.

Welcome back to Sketᵉch — Your Visual Guide to Software Mastery

Got a curious mind and love seeing how things work? You’re in the perfect place.

Not part of the journey yet? Now’s your chance to join our community—subscribe below!

This week, we’re zooming in on some core concepts you don’t want to miss. With sharp visuals to make them stick:

• OAuth 2.0 in 10 Seconds

• Why Every Dev is Talking about SOLID: The 5 Rules You Can’t Ignore

• Stop Overloading Your API: Optimize with Scalable Pagination

• Mastering JWT: Expiry, Refresh and Revocation – The Token Lifecycle

Let’s dive in!

---

OAuth 2.0 in 10 Seconds

OAuth 2.0 is a straightforward way to grant apps access to your data without exposing your password.

Here’s how it works in three simple steps:

1. The App Requests Permission

   The app asks the user for permission to access specific data (like emails or profile info).

2. Authorization Granted

   Once the user approves, the app receives an authorization grant, which it exchanges with the authorization server for an access token.

3. Using the Access Token

   The app uses the access token to securely retrieve the requested data from the resource server without handling passwords.

How OAuth Works in Practice

OAuth powers the "Login with Google" or "Login with Facebook" buttons you use every day. Instead of sharing your password, the app gets a token to access the exact data it needs—nothing more. This keeps your credentials safe while still allowing the app to function.

Why Use OAuth?

• No Passwords Shared: Apps never see your password, only the temporary token.

• Controlled Access: You decide which data the app can access, and it can be revoked at any time.

• Industry Standard: Trusted by companies like Google, Facebook, and GitHub for secure authorization.

If OAuth manages authorization, how do you handle authentication in the apps?

---

Why Every Dev is Talking about SOLID: The 5 Rules You Can’t Ignore

Software architecture is more than just writing code. It’s about building systems that scale, are easy to maintain, and adaptable to change. That’s where the SOLID principles come into play.

What does SOLID mean for your projects?

1. Single Responsibility Principle (SRP)

   A class should have one and only one reason to change. For example, avoid mixing user authentication and logging in the same class—each should have its own job.

2. Open/Closed Principle (OCP)

   Code should be open for extension but closed for modification. When adding new features, extend existing code without changing what already works, reducing the risk of breaking things.

3. Liskov Substitution Principle (LSP)

   Subclasses should be replaceable with their parent classes without affecting the program. If a subclass alters expected behavior, it violates this principle.

4. Interface Segregation Principle (ISP)

   Don’t force a class to implement methods it doesn’t use. Break down large interfaces into smaller, specific ones so classes only implement what they need.

5. Dependency Inversion Principle (DIP)

   High-level modules shouldn’t depend on low-level modules. Both should depend on abstractions, allowing for more flexibility and reducing tight coupling.

What’s your go-to strategy for teaching SOLID principles to your team?

---

Stop Overloading your API: Optimize with Scalable Pagination

APIs often handle large datasets, but when the volume of data skyrockets, performance can take a significant hit.

Without proper pagination, users will face long load times, high latency or even request timeouts.

Pagination divides large datasets into smaller, manageable chunks called "pages."

Three Common Pagination Methods: Which is Right for You?

• Offset-based pagination: Relies on limit and offset parameters to paginate. Limit specifies how many items to return and offset defines where to start in the dataset.

• Cursor-based pagination: Instead of relying on numerical offsets, the server generates a cursor to identify the starting point for the next page. Ideal for datasets where new entries are frequently added or removed.

• Keyset-based pagination: Uses a stable key (e.g., ID, timestamp) to paginate efficiently in large datasets. This method bypasses row counting, improving speed and scalability.

How to Implement Pagination in Your API

• Offset-based Pagination: GET /items?limit=10&offset=20

  This request returns 10 items starting from the 21st record.

• Cursor-based Pagination: GET /items?cursor=abc123

  The server provides a cursor like abc123 for the next page, allowing precise control over the data flow.

• Keyset-based Pagination: GET /items?after_id=100

  This request retrieves items where the ID is greater than 100, efficiently leveraging indexed fields.

Avoid These Common Pagination Mistakes

• Neglecting the last page: Ensure your API returns a clear response when users reach the final page of data.

• Failing to account for real-time data: Use cursor-based or keyset-based pagination to avoid issues with missing or duplicated records in dynamic datasets.

• Ignoring documentation: Clearly explain your pagination parameters (limit, offset, cursor) in your API documentation to avoid confusion.

Best Practices for Scalable Pagination

• Optimize database queries: Use indexes on fields you paginate (e.g., ID, timestamp).

• Set a maximum page size: Protect your system by capping the number of items per page.

• Validate pagination parameters: Ensure limit and offset values are valid to prevent errors.

• Consistency across endpoints: Keep pagination formats uniform to maintain ease of use and prevent confusion.

---

Mastering JWT: Expiry, Refresh and Revocation – The Token Lifecycle

If you think managing tokens is as simple as setting them to expire, you're in for a surprise.

Let’s break down each step of the JWT lifecycle and why it matters:

Access Token: Your JWT is created with a short lifespan e.g., 15 minutes. Every time a user accesses protected resources, the access token is sent for validation.

Token Expiry: Once the access token expires, it’s no longer valid. This limits the exposure window in case the token is compromised.

Refresh Token: It’s stored securely and used to request a new access token without forcing the user to re-authenticate. The refresh token typically has a much longer expiration, days or weeks.

Token Exchange: The server verifies the refresh token and if valid, issues a fresh access token. This maintains session continuity, enhancing both security and user experience.

Token Revocation: If any suspicious activity is detected or the user logs out, the refresh token can be revoked. By keeping a blacklist, the server ensures that compromised tokens can’t be reused.

The result? Seamless authentication, robust security and full control over token lifecycles.

The Risks of Poor Token Management

1. No Expiration: Tokens that don’t expire quickly expose the system to prolonged risk if they are stolen or compromised. Attackers could use them for extended periods.

2. Improper Refresh Token Management: If refresh tokens are not securely stored or handled, they could be intercepted, giving attackers access to generate new tokens and hijack user sessions indefinitely.

3. No Blacklist or Revocation: Without them, compromised tokens cannot be invalidated, allowing attackers to continue using them even after suspicious activity is detected.

80% of security breaches happen because tokens aren't managed properly. Think about it

---

And that wraps up this week! I hope these insights sparked some new ideas for you

---

See you next week! Until then, keep pushing boundaries and leveling up your dev game.

– Nina