Atharv Ketkar

Learn to code #1

After learning about database design, the next steps are

  • API Design & Contracts
  • Frontend State Management
  • Frontend Component Structure
  • Integration Testing

This is in pursuit of solving my problem of creating shitty code with AI. The application I last created had a really shit database because it had a lot of duplicates. It was storing things it shouldn’t. Like basically a mess, I remember making a dashboard and the same metric had two different numbers showing up for it. So I did learn enough about database design to not let that happen again.

Now is the time to fix my problem of back-end and front-end integration. The code that AI on its own creates is trash. The backend will be feature-rich, and the frontend will be just naked. The front-end will be full of dummy data making calls to non-existent endpoints. And during its attempts of integration of backend and frontend, it will spawn bullshit endpoints that do not fetch the data at all. If some the process had 5 steps. It will just integrate 2, and the rest of the 3 will be just not there. And whatever API endpoints it did spawn out of nowhere. Most won’t work, some will pull some data, and if you ignore that, your application will be full of endpoints that are duplicates but still work. You can’t figure out what to do with this jumble mesh. So, that’s why my next goal is to learn those 4 things.

From claude the genius

Backend-Frontend Integration Guide: Preventing Code Chaos

The Problem You Experienced

Your AI created:

  • Feature-rich backend with 20 endpoints
  • Frontend with dummy data, calling non-existent endpoints
  • 5-step process with only 2 steps integrated, 3 missing
  • Duplicate endpoints doing similar things but inconsistently
  • Impossible to debug because you don’t know which endpoint is “real”

Why this happened:

AI generated the backend and frontend separately. No contract between them. Backend didn’t know what frontend needed. Frontend didn’t know what backend provided. They were built in different rooms and never introduced.

How to fix it:

Create the contract FIRST. Backend and frontend are built against that contract, not against each other. The contract is the source of truth.

YT meal

Layer 0: Database Design

Search for:

  • “Database normalization explained” – Look for videos that cover 1NF, 2NF, 3NF (even though we’re doing practical design, understanding the theory helps)
  • “Database design best practices” – Find someone explaining designing schemas, foreign keys, avoiding duplicates
  • “Relational database design tutorial” – This will teach you how to think about entities and relationships
  • Look for channels like: Hussein Nasser, Fireship, or Web Dev Simplified

Layer 1: API Design & Contracts

Search for:

  • “REST API design best practices” – Learn how to design endpoints properly
  • “API contract driven development” – Find videos on designing APIs before building
  • “OpenAPI specification tutorial” – This is about documenting APIs (similar to your contract)
  • “HTTP status codes explained” – Understanding 200, 201, 400, 401, 404, 409 etc
  • Channels: Fireship, Hussein Nasser, WebCrunchTV

Layer 2: Frontend State Management

Search for:

  • If using React: “React state management” or “React Context API” or “Zustand tutorial”
  • If using Vue: “Vue state management” or “Pinia tutorial”
  • If using Svelte: “Svelte stores tutorial”
  • General: “Frontend state management patterns” – Learn the pattern, not just the tool
  • “Single source of truth in frontend” – This is the core concept
  • Channels: Fireship, Web Dev Simplified, Traversy Media, Jack Herrington

Layer 3: Frontend Component Structure

Search for:

  • “React component composition” – How to structure components
  • “Container vs presentational components” – This is the exact pattern
  • “React component best practices” – Keep components small, one responsibility
  • “Component architecture patterns” – How to organize as your app grows
  • Channels: Web Dev Simplified, Fireship, JSConf talks (search YouTube)

Layer 4: Integration Testing

Search for:

  • “Integration testing tutorial” – Learn the difference between unit, integration, e2e
  • “Testing a React application” – If using React
  • “API testing with Jest” or “API testing with Postman”
  • “Frontend integration tests” – Testing components + API together
  • “Test-driven development” – Understanding why you test
  • Channels: Academind, Web Dev Simplified, Testing Library docs (they have videos)

I watched a database design video, and I will boil it down here.

Define the idea in interactions and write down all the features and requirements of your application.Then make mock tables. Always have a unique key and timestamp.Once you are done creating those tables, it is time to create relationships between them. Relationships can be of at least four types:

Many-to-one

One-to-many

Many-to-many

One-to-one

First, you should establish appropriate relationships between two tables. Then, go on into the tables and add the foreign keys in them. This way, you are going in a sequence where you include everything as a relation and as the key also.

Design Interactions & Features
         ↓
Create Mock Tables (ID + Timestamps)
         ↓
Identify Relationships between tables. 
         ↓
Add Foreign Keys
         ↓
Final Schema
         ↓
Now write API Contract (Layer 1)
When you reference a table, you reference its primary key, not its foreign keys.

Every table has ONE primary key (unique identifier)
Every table can have MULTIPLE foreign keys (references to other tables)

When you reference a table, ALWAYS use the primary key
Never reference a foreign key (it’s not unique, ambiguous)

Example:
posts:

  • post_id (PK)
  • user_id (FK) ← Can have many posts per user (not unique)

comments:

  • comment_id (PK)
  • post_id (FK → posts.post_id) ✓ Correct (use PK)
  • post.user_id (FK) ✗ Wrong (use FK, not unique)

Also, the database can be too liberal. You have to enforce limits via the API, not the front-end code.Like you might have one-to-many relationship with media as a tweet. But you cannot have infinite content being dumped into your app, so you have to apply limits at your API so that we don’t accept it. If you just do it at the frontend level, people can spam your API directly.