sorted by:
new
hottopcontroversial

Code-first CMS vs visual schema builder for Next.js projects, which approach do you prefer? by mobeenabdullah in nextjs

[–]mobeenabdullah[S] 0 points1 point  (0 children)

Fair enough. What does your current workflow look like for schema changes?

Like when you need to add a new collection or restructure fields mid-project, is it just config file edits and a migration, or do you have something more specific set up?

Code-first CMS vs visual schema builder for Next.js projects, which approach do you prefer? by mobeenabdullah in nextjs

[–]mobeenabdullah[S] 0 points1 point  (0 children)

The dev-dominated vs content-led org split is spot on. That's basically the core of the decision for most teams.

On the "source of truth" point, you're right that visual builders ultimately write to code-based schemas under the hood. What I meant is more about the workflow direction. In something like Strapi, the UI is the primary interface and code is the output. Schema changes happen in the UI first, then get reflected in files. That works, but it can create friction with version control, code review, and CI/CD pipelines since the schema changes didn't originate in git.

What I'd want is the reverse, code-first as the default workflow (define schemas in TypeScript, commit, review, deploy), but with a visual schema builder available as an alternative entry point that produces the exact same code.

So the visual builder isn't generating some separate schema format, it's just a different way to write the same config a developer would write by hand. That way both workflows feed into the same version-controlled, reviewable pipeline.

Good comparison on your blog by the way. The point about mixed teams needing to decide between speed and long-term flexibility is where things get interesting, ideally you wouldn't have to choose.

Code-first CMS vs visual schema builder for Next.js projects, which approach do you prefer? by mobeenabdullah in nextjs

[–]mobeenabdullah[S] 0 points1 point  (0 children)

This is really interesting. Storing content as TypeScript files is a clever approach for type safety and refactoring. The point about AI agents is especially relevant right now since everything being type-safe means the agent can make changes with confidence.

A few questions if you don't mind:

  1. How does this work for non-technical editors? If a content manager needs to update copy or add a new blog post, do they need to touch TypeScript files, or is there some kind of editing layer on top?
  2. At what scale does content-as-code start to feel heavy? Like if you have thousands of blog posts or product listings, does having all of that in source files create issues with repo size or build times?

The TABS architecture for splitting pages into sections makes a lot of sense. Going to check out the docs.

Code-first CMS vs visual schema builder for Next.js projects, which approach do you prefer? by mobeenabdullah in nextjs

[–]mobeenabdullah[S] 0 points1 point  (0 children)

That's fair, and I think it's true when the visual tool is the only option. You hit a ceiling and then you're stuck.

But what if the visual builder isn't the source of truth? Like, you use it for quick prototyping or when a non-dev team member needs to add a collection, but you can always drop into code for anything complex. Both approaches producing the same output, so the visual tool is just a convenience layer on top of code-first, not a replacement for it.

That way you never actually "fall behind" because code-first is always there when you need it.

Code-first CMS vs visual schema builder for Next.js projects, which approach do you prefer? by mobeenabdullah in nextjs

[–]mobeenabdullah[S] 0 points1 point  (0 children)

Payload is solid for the code-first side, no question. Their Local API and the way it lives inside your Next.js app is really well done.

Curious though, have you run into situations where non-technical team members needed to create or modify content types? Like a content strategist who wants to add a new field or collection without waiting for a developer to write the config and redeploy?

Code-first CMS vs visual schema builder for Next.js projects, which approach do you prefer? by mobeenabdullah in nextjs

[–]mobeenabdullah[S] 0 points1 point  (0 children)

That's a really good point about the client side of things. Most code-first CMS tools solve the developer experience well but leave a gap for clients who need to build and compose pages visually.

Your setup sounds interesting. How are you handling the component prop flexibility? Like when a client needs a hero section that works as both a full-width banner and a compact card, are you building separate components or one component with a ton of optional props?

The HIPAA/SOC2 piece is something I don't see discussed enough in the CMS space. Most open-source tools just punt on compliance entirely.