Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For a web application built and released as one product, a monorepo is a practical default: keep the Next.js frontend in web/ and the Go API in backend/. Give Go its own module root at backend/go.mod, put the server executable in backend/cmd/api/, and keep implementation packages in backend/internal/. This is a useful convention, not a framework-mandated template; choose the details around how your team works and deploys.
A practical starting layout
This example uses Next.js App Router and a single Go module. The directory names under internal/ illustrate possible responsibilities; create them only when they hold coherent code.
project/
web/
package.json
next.config.ts
src/
app/
layout.tsx
page.tsx
components/
features/
backend/
go.mod
cmd/
api/
main.go
internal/
config/
handler/
service/
store/
README.md
.gitignoreHere, the frontend and backend are visibly separated while remaining easy to change together. The Go module starts at backend/, not at the repository root. Next.js configuration and package metadata remain at web/; src/ contains application source.
Recommended Free Tools
This is an editorially practical synthesis, not an official shared Next.js and Go scaffold. Next.js leaves ordinary file organization flexible, and Go guidance describes layouts suited to different kinds of projects. Avoid empty folders added just to make the tree look complete.
#1 Best Overall
Choose the Next.js routing convention first
Next.js gives certain folders and files framework meaning. Use the router your application actually uses rather than combining examples from both conventions.
- App Router: put route segments and their special files in
app/. In the example,src/app/layout.tsxandsrc/app/page.tsxare App Router files. - Pages Router: use
pages/for routes instead of treatingapp/as interchangeable with it. - Static assets: Next.js reserves
public/for static assets. - Optional source directory:
src/is optional. It can separate application code from configuration, while configuration files such aspackage.jsonstay at the frontend project root.
See the Next.js project structure documentation for the current folder and file conventions. Keep environment files and credentials out of version control; the documentation identifies environment files among the project files that should not be tracked.
Rank #2
Organize frontend code for reuse and discoverability
Next.js does not prescribe one universal home for components and other ordinary application files. The official guidance describes placing shared code outside app/, putting shared folders inside it, or colocating code with routes and features. The right choice depends on whether code is shared broadly or belongs to one part of the application.
- Shared across many routes: a top-level
components/or similar folder makes shared UI easier to find. - Specific to a feature: colocate route-specific components and logic near the route or feature that owns them.
- Growing codebase: use a consistent convention so developers can predict where a file belongs; avoid duplicate homes for the same kind of code.
These are organizational options, not required folder names. Next.js explains its flexibility in Project Organization and File Colocation.
Rank #3
Keep the Go module and server entry point clear
In Go, a module groups related packages, and a go.mod file defines the module root and module path. Package import paths derive from that module path plus each package’s directory. With the example tree, the module root is backend/; Go packages live beneath it.
For a server repository that also contains non-Go files, Go guidance describes cmd/ as a useful place to collect commands. A server’s implementation packages typically belong under internal/, which prevents them from being imported by code outside the parent tree. Thus backend/cmd/api/main.go is the executable entry point, while implementation can be separated into packages beneath backend/internal/.
Rank #4
Names such as handler, service, and store are examples, not mandatory layers. Add a package when it represents a coherent unit or creates a useful boundary; a small server may need fewer packages. Read the Go guidance on organizing a Go module for the rationale behind these conventions.
Decide whether one repository fits your team
A monorepo is a reasonable starting point when frontend and backend changes are often coordinated, ownership overlaps, and the product is developed as a unit. It makes the boundary visible without requiring independent repositories. It does not require one deployment process or mean the two applications must ship together.
Separate repositories may fit better when ownership, release cadence, or operational boundaries are genuinely independent. The framework documentation does not prescribe a universal repository strategy; make the choice based on how the team changes, versions, and deploys the systems.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use one Go module unless independent versioning matters
A single go.mod under backend/ is the simpler default for one backend application. Multiple Go modules in the same repository are possible, but each module root has its own go.mod. Use them when distinct parts need independent versioning or maintenance—not merely to mirror the frontend/backend folder split.
Go’s guidance discusses managing module source and the implications of module boundaries. A repository can contain multiple modules, but that adds module roots and versioning concerns to maintain.
Quick Recap
Adapt the tree without adding ceremony
- If the repository contains only the frontend and backend, keeping their directories at the root is clear; a wrapper directory named
web/is not required. - If you use Pages Router, substitute
pages/for the App Router’sapp/convention rather than mixing their special files. - If the Go server is small, begin with
cmd/api/and only the implementation packages that provide real boundaries. - If release or ownership requirements are independent, reconsider the repository or module boundaries based on that need.
- Keep secrets and local environment configuration untracked.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
