Go - lesson 2 | HackIndia Skills

Why types matter

Your HTTP service will receive, store, and return data. If that data is loose, every handler becomes a mess of string keys and checks.

In Go, you model data with structs, slices, and maps. This makes your repo easier for a recruiter to read and easier for you to test.

Key point

One idea

Create types for the real things in your app. Then pass those types through your handlers instead of passing raw maps everywhere.

Example

Model a project

For a HackIndia-style backend, you may track student projects. Start with a struct that names the data clearly.

JSON tags control the field names your API sends and receives. Keep Go field names exported with capital letters if another package or JSON encoder must access them.

package main

type Project struct {
	ID       string   `json:"id"`
	Name     string   `json:"name"`
	Team     string   `json:"team"`
	College  string   `json:"college"`
	Tags     []string `json:"tags"`
	RepoURL  string   `json:"repoUrl"`
	LiveURL  string   `json:"liveUrl,omitempty"`
}

type ProjectStore struct {
	items map[string]Project
	order []string
}

Your to-do

Build useful shapes

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Name the main thing your service manages, such as Project, Event, Expense, or Order.
Add fields your API really needs today, not every field you can imagine.
Use a slice when order matters, like tags or recent submissions.
Use a map when you need fast lookup by ID, email, slug, or UPI reference.
Group related data into another struct instead of adding many loose fields.

0 of 5 done

Example

Use make correctly

Slices and maps often need initialization before use. The built-in make creates initialized slices, maps, and channels and returns the value, not a pointer.

A nil map will panic when you assign into it. So initialize your store before your handlers use it.

func NewProjectStore() *ProjectStore {
	return &ProjectStore{
		items: make(map[string]Project),
		order: make([]string, 0),
	}
}

func (s *ProjectStore) Add(p Project) {
	s.items[p.ID] = p
	s.order = append(s.order, p.ID)
}

func (s *ProjectStore) All() []Project {
	projects := make([]Project, 0, len(s.order))
	for _, id := range s.order {
		projects = append(projects, s.items[id])
	}
	return projects
}

Common mistake

Avoid map soup

Do not model a project as map[string]string just because JSON looks like key-value data. That hides mistakes until runtime.

With a struct, the compiler catches p.RepoURL versus p.RepoUrl. With a raw map, a typo becomes bad data in your API response.

Tip

Use AI carefully

You can ask AI to draft structs from a sample JSON response. Then check three things yourself: field names are clear, optional fields use omitempty only when empty is valid, and lists are slices, not comma-separated strings.

If AI gives you interface{} for normal app data, push back. Ask for concrete structs unless the field can truly hold many unrelated shapes.