They’re kind of like a contract that says, “I have these methods and/or properties and that’s all you know about me”.

Imagine you have a bunch of places in your code where you have a list of things that might be empty and you only want to get the first item out and throw an error if it’s empty. You could write a helper function for that:

function pop_or_throw<T>(items: T[]): T {
    const item = items.pop()
    if (item == null) throw new NotFoundError()
    return item
}

But now you realize you actually do the same exact thing with a bunch of maps. You pop an item off and if it’s empty, you throw an error. So to make this helper function usable everywhere, you can write an interface:

interface Poppable<T> {
    pop: () => T | undefined
}

function pop_or_throw<T>(items: Poppable<T>): T {
    const item = items.pop()
    if (item == null) throw new NotFoundError()
    return item
}

That’s the gist of what interfaces are for. They allow you to think about exactly what your code requires of the things it references and not worry about the specifics of everything else, which often makes it more flexible.

So if you’re writing a function that accepts an object, instead of specifying that object, you can write an interface that only specifies that methods or properties you plan to use. That way, if you make changes to the object or need to switch to a different object, you can leave your other code intact.

They don’t always make sense for small projects, but for large projects they help maintainability a lot. Also, they help when you’re first reasoning through a problem because they force you to minimize what parts of the rest of your system you have to think about while working on a particular part. I’ve seen it talked about like, “when you’re designing a lego, you don’t think about all possible other kinds of legos, you just imagine the connector circles on top”. Those connector circles are the parts that are shared among all of the pieces you care about. It’s your interface.