Theory
Making the pieces work together
You have a front end and a back end, and a database design. Integration is where they, and any outside services, are connected into one working system. It is a distinct and often tricky phase: parts that each work alone can still fail to work together.
Three connections matter: the back end to the database, the back end to any external APIs (services you do not build yourself), and the front end to the back end. This lesson covers integrating them, and why doing it early and carefully avoids nasty surprises. Integration is where a collection of parts becomes an actual application.
Theory
Database and external APIs
The back end connects to your database to store and retrieve data, using the structure from your ER diagram. This is the core integration: your logic reading and writing real, persistent data.
It may also connect to external APIs, third-party services you call rather than build. Examples: a payment gateway (to take payments), a maps service (for locations), email or SMS services (for notifications), or Firebase (for authentication). You call their API, and they provide the service, saving you from building complex systems yourself.
External APIs are powerful, they give you capabilities you could never build in a semester, but they add a dependency: your system now relies on that service, so you must handle its errors (what if it is down or rejects a request?) and read its documentation carefully.
Formula
Integrate early, and expect surprises
Here is hard-won advice: integrate early and incrementally, do not build the front end and back end in total isolation for weeks and only connect them at the end. Integration is exactly where hidden problems surface: mismatched data formats, authentication issues, unexpected errors from an external API, connections that do not behave as assumed.
If you leave all integration to the last minute, you discover these problems when there is no time to fix them. Instead, connect the parts as you build, test each integration point, and handle errors gracefully. The parts working alone is not the same as the system working; only integration proves it. Wire it together early, and the surprises come while you can still handle them.
Quiz
Why should you integrate the parts of your project (front end, back end, database, external APIs) early and incrementally rather than only at the end?
- Because integration always works perfectly the first time
- Because integration is where hidden problems surface (mismatched formats, auth, errors), so connecting early gives you time to find and fix them
- Because the parts never need to connect
- To make the project take longer
Show the answer
Because integration is where hidden problems surface (mismatched formats, auth, errors), so connecting early gives you time to find and fix them
You should integrate early and incrementally because integration is exactly where hidden problems surface, mismatched data formats, authentication issues, unexpected errors from external services, connections behaving differently than assumed, and connecting early gives you time to find and fix them before the deadline. Option A is wrong and dangerous: integration rarely works perfectly first time; that assumption is why leaving it to the end causes disasters. Option C is false: the whole point of the project is that the parts connect into one working system. Option D is nonsense: integrating early saves time overall by catching problems when they are small. Parts working alone is not the system working; integrate early to surface and solve the inevitable connection issues in time.
Think first
Why do parts that each work on their own still fail when connected?
The front end works, the back end works, so why does connecting them so often reveal new problems? Then tap.
Show the answer
Because when two parts are built separately, each is built against ASSUMPTIONS about the other, and those assumptions rarely match perfectly, so the mismatches, invisible while each part is tested alone, only appear at the point where they actually meet. Consider what 'each part works' really means: the front end works against what it EXPECTS the back end to send and accept; the back end works against what it EXPECTS the front end to send and against how it ASSUMES the database or an external API behaves. But these expectations are formed independently, and small differences creep in: the front end sends a date as text but the back end expects a number; the back end returns a field named one thing but the front end reads another; the API expects an authentication token the front end does not attach; an external service returns errors in a format nobody anticipated; a data field is longer than the database column allows. None of these show up while testing a part in ISOLATION, because in isolation each side uses its own assumptions consistently. They only surface at the INTEGRATION point, where the real data and real behaviour of one part meet the expectations of the other, and the mismatch breaks something. This is why integration is famously where bugs hide, and why 'it works on my part' is not the same as 'the system works'. There are also genuinely new concerns that only exist BETWEEN parts: authentication across the boundary, error handling when a remote call fails, network issues, data format agreements, timing, none of which any single part can fully test alone. The remedy is to integrate EARLY and INCREMENTALLY, connecting and testing the real interaction between parts as you build them, so these mismatched assumptions are exposed while they are small and there is time to reconcile them, rather than discovering a pile of them at the end. Integration testing (a level you will meet next) exists precisely for this. So parts failing when connected is normal and expected, it is the assumptions meeting reality, which is exactly why you must integrate and test the connections deliberately, not assume they will just fit. Separate parts carry separate assumptions; integration is where they are reconciled.
Summary
Key takeaways
- Integration connects the separately built parts, front end, back end, database, external APIs, into one working system.
- The back end connects to the database (using your ER design) to store and retrieve data.
- The back end may connect to external APIs, third-party services you call rather than build (payments, maps, email/SMS, Firebase auth).
- External APIs give capabilities you could not build yourself, but add a dependency, so handle their errors and read their docs.
- The front end connects to the back end via API calls.
- Integrate early and incrementally, because integration is where hidden problems (mismatched formats, auth, errors) surface; connecting early gives time to fix them.
- Memory hook: wire the parts together early and test each connection, parts working alone is not the system working.