I’m explaining how to set up a content management system using the Next.js frontend, Express API, Prisma, PostgreSQL, Cloudinary, and DeepL.

Next.js CMS Architecture: Content, Image, and i18n Management

As a portfolio, blog, or corporate site grows, static JSON files become insufficient. Posts, blog articles, page components, images, and translations must be manageable. The goal here is not merely to add an admin panel, but to make the content workflow secure and sustainable.

API client

On the frontend, the API endpoint must be managed through a single instance. This ensures that components remain consistent across local, staging, and production environments.

import axios from 'axios'

const axiosInstance = axios.create({
  baseURL: process.env.NEXT_PUBLIC_API_BASE_URL,
  timeout: 15000,
})

export default axiosInstance

Locale Parameter

When CMS data is stored in two languages, the frontend does not need to write separate endpoints for each locale. The locale parameter is sent, and the server applies the translation fields to the main fields.

export async function getPortfolioData(locale: string) {
  const response = await axiosInstance.get("/api/projects", {
    params: { locale },
  })

  return response.data
}

Translation Storage Model

The original content can be stored in Turkish, while English equivalents can be stored in a JSON field like translations.en. This allows the editor to view the translation without altering the main text. When creating a new record, automatic translation can be generated using DeepL.

const project = {
  title: 'Başlık',
  description: 'Açıklama',
  translations: {
    en: {
      title: 'Title',
      description: 'Description',
    },
  },
}

Media Management

Images should be uploaded via drag-and-drop in the admin panel and stored in the media library. The frontend can generate transformed URLs for different use cases: such as thumbnails, banners, or gallery sizes. This way, the editor doesn’t have to resize the same image repeatedly.

Markdown Editor

Writing HTML in blog and project content strains the editor. Markdown is more intuitive; tools like headings, lists, links, bold text, and code blocks can be provided via shortcut buttons in the admin panel. Preserving code blocks during translation is also particularly important in technical blogs.

Conclusion

A well-designed CMS architecture accelerates content creation without compromising frontend quality. The API returns the correct data based on the locale, the media system handles the visual load, the Markdown editor simplifies technical writing, and automatic translation makes bilingual publishing sustainable.

Thinking End-to-End

In a full-stack CMS architecture, the frontend, API, database, media management, and translation system may appear as separate components; however, they form a single user experience. The title entered in the admin panel must appear correctly on the frontend, images must be displayed at the correct dimensions, translations must appear in the correct locale, and the content editor should not be overwhelmed by technical details.

Data Contract

There must be a clear contract between the data the frontend expects and the data the API returns. If the project card expects title, description, category, imageUrl, and slug, the API must return these fields pre-populated for each locale. The frontend should not attempt to parse the translation JSON; the server should handle this.

Editor Experience

The CMS is a tool not only for developers but also for content contributors. Image uploads should be drag-and-drop, Markdown tools should be intuitive, translation status should be visible, and error messages should not be technical. A well-designed admin panel reduces the product’s maintenance costs.

Publication Security

As the content system grows, validation, authentication, role-based access control, media limits, environment security, and backup strategies become critical. Even a small portfolio site, if built with the right architecture, can evolve into an enterprise site or content platform in the future.

Implementation Plan

When applying this approach to a real project, start by building a small but fully functional core. The first step should be to clarify the data model, the second step to define the API contract, and the third step to complete the main workflow in the user interface. Afterward, additional layers such as automation, translation, reporting, or media management can be added sequentially. Proceeding in this manner maintains development speed while preventing complexity from growing too early.

Additionally, every technical decision must have a user or operational justification. A table, queue, SDK, or dashboard component should be added not merely because it is technically correct, but because it makes the process more understandable, faster, or more measurable. Robust products grow through this discipline.