Theory
The engine behind the screens
Users see the front end, but the real work happens in the back end, the server-side code they never see. When a student registers for an event, the back end validates the request, checks the rules, saves the data, and responds. It is the engine of your application.
Back-end development builds this engine: the business logic, the APIs the front end calls, the security, and the connection to the database. You know the tools (Node/Express, PHP, .NET, Python) and REST from your degree. This lesson gives guidance for building the back end well, organised, correct, and secure, so the whole system works reliably behind the interface.
Theory
What the back end does
The back end has several jobs.
Business logic: the actual rules and processing, checking an event is not full before registering, calculating totals, enforcing what is allowed. APIs (endpoints): the interface the front end calls, designed as clean REST endpoints (GET to read, POST to create, and so on, from your full-stack course). Validation and security: never trust input from the client, validate it on the server, authenticate users, and protect sensitive data. Database communication: reading and writing the data, using the design from your ER diagram.
Keep it organised (separating routes, controllers, and data models) so the code stays clear as it grows, exactly the structure you learned in full-stack development. Build the back end to match the modules from your high-level design.
Formula
The back end owns correctness and security
A crucial principle: the back end is where correctness, data integrity, and security must be enforced, because the front end can be bypassed or tampered with. Recall from your web courses: never trust the client. A malicious user can send any request, so the server must validate every input, check every permission, and protect the data.
So put your important rules and checks in the back end, not only the front end. The front end can guide users (hiding a button, showing an error), but only the back end can truly enforce the rules and keep the data safe. This is where the trustworthiness of your whole project lives. Build the back end as the reliable, secure guardian of your data and logic.
Quiz
Where should the important rules and validation of your project be enforced, and why?
- Only in the front end, because that is what users see
- In the back end (the server), because the client can be bypassed or tampered with, so the server must validate input and enforce rules and security
- Nowhere; rules enforce themselves
- Only in the database, never in code
Show the answer
In the back end (the server), because the client can be bypassed or tampered with, so the server must validate input and enforce rules and security
Important rules, validation, and security must be enforced in the back end (the server), because the client (front end) can be bypassed or tampered with, so a malicious user could send any request; only server-side checks can truly enforce the rules and protect the data (the 'never trust the client' principle from your web courses). Option A is unsafe: front-end validation improves user experience but can be circumvented, so it cannot be the only line of defence. Option C is wrong: rules do not enforce themselves; they must be coded and checked. Option D is incomplete: while the database can enforce some constraints, business logic and security also belong in the server-side code. The back end owns correctness and security.
Think first
Why can the front end never be trusted to enforce security on its own?
You validated input in the front end. Why is that not enough, and why must the back end re-check everything? Then tap.
Show the answer
Because the front end runs on the USER'S device, where anyone can inspect, modify, or bypass it, so any check done only in the front end can be defeated, which means the server must independently validate and enforce everything, or the system is insecure. Consider what the front end actually is: code (HTML, JavaScript, or a mobile app) running on the user's own machine, fully under their control. A user, or an attacker, can open developer tools, alter the code, disable a validation, or, crucially, IGNORE the front end entirely and send raw requests straight to your server using simple tools. So a front-end check like 'do not allow registering for a full event' or 'this field must be filled in' only stops HONEST users using the interface as intended; it does nothing against someone who bypasses the interface and sends a crafted request directly. If the server blindly trusted such requests because 'the front end already validated', an attacker could register for full events, submit invalid or malicious data, access things they should not, or tamper with records, because the only real gatekeeper was on the wrong side. That is why the golden rule is 'never trust the client': the server must treat every incoming request as potentially hostile and independently validate the input, check the user's permissions, enforce the business rules, and protect the data, regardless of what the front end supposedly did. Front-end validation is still valuable, it gives users fast, friendly feedback and reduces needless server load, but it is a CONVENIENCE, not a security boundary. The genuine security and correctness boundary is the server, because it is the part you control and attackers cannot alter. This is one of the most important lessons in building safe applications, and it applies directly to your project: put your real checks in the back end. Anything running on the user's device can be bypassed, so the server must be the one that truly enforces the rules.
Summary
Key takeaways
- The back end is the server-side engine users never see; it does the real work behind every screen.
- Its jobs: business logic (rules and processing), APIs/endpoints (the interface the front end calls, designed as clean REST), validation and security, and database communication.
- Keep it organised (routes, controllers, data models) so the code stays clear, as in your full-stack course.
- Build it to match the modules from your high-level design and the data from your ER diagram.
- Correctness, data integrity, and security must be enforced in the back end, because the client can be bypassed or tampered with.
- Never trust the client: front-end validation aids users, but only the server can truly enforce rules and protect data.
- Memory hook: the back end holds the logic, exposes the APIs, talks to the database, and is the true guardian of correctness and security.