It depends on the scope of the project. I like to start simple and restructure, or extract functions and route handlers, as the application starts to grow.
For me, typically it looks something like this after I've gone through the restructure process:
# Ol' (oftentimes) reliable
package.json
# Configuration is a topic for another time, and entirely situational
# Just imagine some config.js/json/.env/.yaml/rc file somewhere here
# Typically I just use a file that will load from env variables and set defaults, and I'll just require it as necessary elsewhere
# Kick-off file. Imports the app/server instance from app.js and initializes and runs it.
# In the case of an express app, would bind to a port and start listening.
index.js
# Exposes an app/server instance. Can be an express app or something similar.
# In an express app, this would be binding the routes and such
app.js
# Any functions and such, organized by functionality or feature
lib/**/*.js
lib/index.js
# This is really only relevant for http servers.
# Controllers to me are just objects with route handlers.
# I just group them by feature, or sometimes even path
controllers/index.js
controllers/**/*.js
# This can really be a directory or a file
# But all it does binds the functions from controllers to the appropriate routes
routes.js
routes/index.js
routes/**/*.js
# Models are entirely situational too, and only relevant when using a database
# Can also be a file or directory (K. I. S. S.)
models.js
models/index.js
models/**/*.js
This is entirely my opinion of how to do this. Another pattern I've been doing most recently has been grouping controller, route, and model together in a directory by feature/component/service in place of the separate route/controller/model directories/files to simplify things. I can sometimes even put all three in the same file if they're small enough and avoid the directory altogether. Then I just have the top level files that bind and register the handlers and kick things off as usual.