One idea
In Go, a type implements an interface by having the methods the interface asks for. You do not write “implements”.
This means your service can depend on behavior, such as “can find a student”, instead of a concrete detail, such as “uses Postgres”.
Why it matters
Your HackIndia repo needs typed handlers and clean design. Interfaces help you keep HTTP code separate from storage code.
A recruiter should be able to read your handler and see the business action. They should not need to understand your map, file, or database code first.
Design the interface
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.
0 of 5 done
Small store example
Here the handler depends on StudentStore. The mapStore type matches it because it has FindByID with the same signature.
No extra keyword is needed. If the method is missing or has the wrong return type, the code will not compile.
package main
import "fmt"
type Student struct {
ID string
Name string
}
type StudentStore interface {
FindByID(id string) (Student, bool)
}
type mapStore struct {
students map[string]Student
}
func (m mapStore) FindByID(id string) (Student, bool) {
student, ok := m.students[id]
return student, ok
}
func PrintStudent(store StudentStore, id string) {
student, ok := store.FindByID(id)
if !ok {
fmt.Println("student not found")
return
}
fmt.Println(student.Name)
}
func main() {
store := mapStore{
students: map[string]Student{
"101": {ID: "101", Name: "Asha"},
},
}
PrintStudent(store, "101")
}Use fakes
Interfaces make testing easier. You can pass a fake store to a handler instead of connecting to a real database or editing live data.
For a college project, this is enough to show good backend thinking. Your README can say the HTTP layer is tested with a fake store.
type fakeStore struct{}
func (fakeStore) FindByID(id string) (Student, bool) {
return Student{ID: id, Name: "Test Student"}, true
}Avoid empty interface
Do not use interface{} because you are unsure of the type. It means any non-interface type can fit, so you lose useful compiler checks.
Prefer concrete types or a small interface with named methods. Your service will be easier to read and safer to change.
Go 1.27 note
Go 1.27 supports generic methods, so older tutorials saying Go has no generic methods are outdated.
But interface methods may not declare type parameters, and generic methods cannot implement interface methods. Keep service interfaces simple and non-generic.
Do this now
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.
0 of 5 done