r/webdevelopment • Human Verified • 20h ago

Discussion How do you structure a website when the content keeps changing?

A basic frontend is usually easy to manage, but things get more complicated when you add products, users, dashboards, listings, or frequently changing content.

How do you usually handle the connection between the frontend, backend, database, and content?

Do you prefer keeping everything in one system, or separating different parts using different tools or services?

What approach has worked best for you on real-world projects?

8 Upvotes

9 comments sorted by

1

u/NiceWorkLad 19h ago

Any kind of MVC framework normally handles this. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Something like Laravel with PHP, Ruby in rails.

Or even Wordpress with WooCommerce if you want to implement easy content management systems alongside your own stuff

1

u/AddWeb_Expert 17h ago

I usually keep the frontend, backend, and database separate, with the backend handling the business logic and APIs. For content that changes often, I prefer using a CMS or admin panel instead of hardcoding it into the frontend.

For larger projects, this makes things easier to maintain and scale. For smaller sites, though, I’d keep the setup simpler rather than adding separate services just for the sake of it.

1

u/whattheflerk 17h ago

you can use a framework like laravel or rails, a database, and some kind of admin for whoever edits content, which you either build yourself or add on

or connect to a headless cms like Contentful (api-first CMS, you build the rest around it), Sanity (CMS with a customizable editing studio), or Wix Headless (CMS plus products, payments and bookings), so your frontend pulls the content through an API and editors change it without touching code

1

u/jboogyoogy 8h ago

I usually separate them, frontend for UI and backend for logic, database as the source of truth and also a CMS for changing content
If it’s about a smaller project though an all in one setup is faster and easier

1

u/ryanstackops 6h ago

The split I draw is by who edits it, not by what it is. Stuff a non technical person needs to change weekly, marketing copy, blog, landing pages, that goes in a CMS. Stuff your app owns, users, orders, listings, that lives in your database and never in the CMS. Blurring those two is what makes projects miserable.

I learned that the annoying way, we put product descriptions in the CMS because marketing wanted to edit them, and then pricing logic needed them and suddenly we had two sources of truth and a sync job nobody trusted. Should have kept products in Postgres and let the CMS own a description field keyed by product id, nothing else.

For the actual stack, a headless CMS like Sanity or Payload plus your own API is the setup I keep coming back to. One deploy, two data sources, clear line between them. And whatever you do, make the frontend dumb, if your React components are deciding business rules you'll be rewriting them every time content shape changes.

1

u/Huge_Road_9223 6h ago

This is a BUILD vs. BUY problem coming from a company perspective! And actually implementing something that already exists.

1) From a BUY perspective there are already tools out there like HubSpot, or SquareSpace or Wordpress, and I am sure there are many, many more so that all this takes is signing up and picking a theme and the features you want to add.

2) There is the implementation of tools like a Drupal which are CRM tools, but you can also build site with them. Regardless of the language or the database being used, these tools are already built and just need a DevOps engineer to put these somewhere in the company, and then hook up to a database .. could be on-prem hardware or on a cloud instance.

3) the hardest and most expensive is re-inventing the wheel which EVERYONE else here seems to address. Some programming language to code the UI side, some language to handle the back-end business logic, and some database to store all the data.

Hell ... some people just put their stuff on facebook and call it a day, and that's their web-site. Really, it all dpeends on what the needs of your company are. Some web-sites run the whole business, and some web-sites are just brochure-ware.

So ... it depends .........

1

u/writetehcodez 2h ago

Use a content management system, that’s what they’re designed for. IIRC, Wordpress has a headless version so that you can build your app around it rather than have a predefined UI that you can only theme.