SRTMUN Students: Using Postman and Browser DevTools to Debug a Full Stack App

To debug a full stack app, first decide which of three layers owns the bug: the front end (what the browser renders and runs), the network (the request and response in between) or the server (routes, logic and database). Browser DevTools shows you what the browser sent and received, and Postman lets you replay the same request without the front end, so together they split the problem in half within minutes.

This guide gives SRTMUN students a repeatable workflow, a text flowchart for locating a bug, a debugging log template you can copy, and a worked illustrative example. It assumes a typical stack of a JavaScript front end calling a REST API, but the logic holds for most setups.

Why “it doesn’t work” is not a bug report

Most beginners debug by changing code and refreshing. That works for tiny errors and fails the moment a feature crosses layers. A login button that does nothing could be a click handler that never fires, a request blocked by the browser, a server that returns 500, or a response the UI ignores. Each needs a different fix.

The discipline is simple: observe first, form one hypothesis, test it with one tool, record the result. The rest of this article turns that into steps.

The three layers and what each tool shows

Preparation: set up so bugs are easy to see

• Open DevTools (F12 or Ctrl+Shift+I) before reproducing the bug, so nothing is missed.
• In the Network tab, tick Preserve log and Disable cache while debugging.
• Filter to Fetch/XHR to hide images and stylesheets.
• Keep the server terminal visible beside the browser. Add one log line at the start of each route handler if you have none.
• In Postman, create a collection for your project and an environment with a variable such as baseUrl (for example http://localhost:5000) so you can switch between local and deployed servers.

Flowchart: where does this bug live?

Read this top to bottom. Stop at the first box that gives you a clear answer.

START: Something is wrong in the app
  |
  v
[1] Open Console. Any red error on page load or on the action?
  |-- YES --> Read the first error. Does the stack trace point to your front-end file?
  |            |-- YES --> FRONT-END BUG (fix JS, then retest)
  |            |-- NO (message says CORS / Failed to fetch) --> go to [2]
  |-- NO  --> go to [2]
  |
  v
[2] Open Network tab. Trigger the action. Is a request listed?
  |-- NO  --> FRONT-END BUG (handler not attached, wrong condition, form blocked)
  |-- YES --> go to [3]
  |
  v
[3] Check the request: URL, method, headers, body correct?
  |-- NO  --> FRONT-END (building the request wrongly)
  |-- YES --> go to [4]
  |
  v
[4] Check the status code.
  |-- No response / (failed) / CORS error --> NETWORK or SERVER CONFIG
  |-- 4xx --> read response body. Request invalid, or auth/route missing
  |-- 5xx --> SERVER BUG (read terminal logs)
  |-- 2xx --> go to [5]
  |
  v
[5] Copy the same request into Postman. Same response?
  |-- Response data is wrong in Postman too --> SERVER BUG (logic or database)
  |-- Response is correct in Postman --> FRONT-END BUG (rendering, state, parsing)

The workflow in seven steps

Step 1: Reproduce and write the expected result

Write one sentence: “When I do X, I expect Y, but I get Z.” If you cannot reproduce it reliably, note the conditions: logged in or out, which browser, which data.

Step 2: Read the Console from the top

The first error is usually the cause; later errors are often side effects. Note the file name and line number. A TypeError: Cannot read properties of undefined often means data you expected from the API has not arrived or has a different shape.

Step 3: Inspect the request in the Network tab

Click the request and check, in order: Headers (URL, method, status, content type), Payload (what you actually sent), Response (what came back) and Timing (was it slow or stuck pending). Many bugs end here: a field named userName sent when the server expects username, or a GET where a POST was needed.

Step 4: Decode the status code

Step 5: Replay the request in Postman

Copy the request from DevTools (right-click the request, Copy, Copy as cURL) and use Postman’s Import to paste it. Send it. Postman does not run your front-end code and does not enforce browser CORS rules, so:

• If Postman fails the same way, the server or the data is at fault.
• If Postman succeeds but the browser fails, suspect CORS, cookies, headers added or missing by front-end code, or the way the UI handles the response.

Step 6: Narrow it with one change at a time

In Postman, vary one thing: remove a field, change an ID, drop the auth header. Watch how the status and body change. On the server, add a temporary log of req.body, the query result and the value returned. On the front end, use a breakpoint in the Sources tab or a console.log right after the response is parsed.

Step 7: Fix, retest at both ends, and record

Retest in Postman first, then in the browser. Add a Postman test or saved example so the bug cannot quietly return. Then fill in your debugging log.

Debugging log template you can copy

Keep this in a notes file or a Markdown file in your repository. One entry per bug takes two minutes and becomes useful evidence of your process in a project report or portfolio.

Worked example: a profile update that “saves” but shows old data

This scenario is illustrative. It was constructed to show the method and is not output from a real project or a test run.

Suppose a student builds a profile page. The user edits their city, clicks Save, sees a success message, but after refreshing the page the old city is still shown.

1. Reproduce and state it. “When I change the city to Nanded and save, I expect the refreshed page to show Nanded; it shows the old value.”
2. Console. No red errors. This does not rule out any layer yet.
3. Network. A PUT /api/profile request appears with status 200. The Payload tab shows {"town": "Nanded"}.
4. Spot the clue. The database field is called city, but the front end sent town. The request is being built wrongly, so the first suspect is the front end.
5. Confirm with Postman. Send PUT with {"city": "Nanded"} and then GET /api/profile. If the GET now shows Nanded, the server works when given the right field.
6. Find the second issue. Send the original {"town": ...} body. The server still returns 200 because it ignores unknown fields and reports success without checking that anything changed. That is a server weakness: it should return 400 for an unknown field or confirm which fields were updated.
7. Fix both. Rename the field in the front-end form code. On the server, validate the body and return a clear error for unexpected fields.
8. Log it. Layer: front end (cause) plus server (missing validation). Lesson: a 200 status proves the server answered, not that the data changed.

Notice that the bug had two owners. The flowchart finds the first; Postman then exposed the second.

Common full stack symptoms mapped to the likely layer

Postman habits that save time

• Save every working request into a collection with a clear name like “Auth – Login (valid)”.
• Save a failing example for each error you expect (missing field, wrong password), so you can test validation.
• Use environment variables for baseUrl and token. Store the token from the login response using a short test script, then reuse it.
• Add basic tests such as checking the status code and that the response has the expected field.
• Never share a collection with real secrets in it. Replace keys and passwords before exporting or committing it.

DevTools habits that save time

• Use Network, then Throttling to simulate slow connections and expose loading-state bugs.
• Use Application, then Local Storage / Cookies to check whether a token is really stored and whether it expires.
• Use Sources breakpoints instead of scattering console.log everywhere; pause at the line after the response arrives and inspect variables.
• Use Elements to check whether a node exists but is hidden by CSS, which is different from not being rendered at all.
• Right-click a request and choose Replay XHR to resend it without clicking through the UI again.

SRTMUN students: turning debugging practice into coursework evidence

Swami Ramanand Teerth Marathwada University in Nanded says on its home page that it was established on 17 September 1994 by the Government of Maharashtra. A university notice on its academic section page tells affiliated colleges to build their own websites and submit their College Profile through e-Samarth, which shows that many students study at affiliated colleges. In practice, your day-to-day project guidance may come from your own college as well as the university.

For computing students, the university’s syllabi page lists NEP-era syllabus documents by programme and year. A search excerpt of the B.Sc. Third Year Computer Science (Single Major) 2026-27 syllabus mentions Python practical work such as functions and lambda expressions. That is a programming base, but this excerpt should not be taken as the full syllabus; open the current PDF and check what it actually covers. Debugging habits such as reading stack traces and isolating a function carry straight over to JavaScript and server code.

The Academic category page also lists an Academic Calendar 2026-27, published on 6 May 2026. Check it for exam and break dates before you plan a 14-day internship alongside your studies. The rules for internships, project work or credit were not available to confirm here, so do not assume that any outside internship counts toward your degree.

The free two-week online internship at CareerSwami offers a free offer letter and a free completion certificate after successful completion; it gives no stipend, academic credit or placement. A tidy debugging log is a practical way to show what you did during it.

Verification steps for SRTMUN students before you rely on this

1. Open the current Academic Calendar 2026-27 on the university’s academic page and note your semester’s exam and break dates.
2. Download the syllabus PDF for your exact programme and year from the syllabi page and check whether a project, internship or full stack topics appear.
3. Email your department or project coordinator asking in writing: “Is there a project or internship requirement in my scheme, and are online internships accepted?”
4. Ask whether internship rules are set by the university or by your college, and request the circular or regulation in writing.
5. Before using a university placement-related page, confirm with your college whether it serves your campus or only a sub-campus.

A 14-day plan for practising this workflow

If you take a two-week internship or study on your own, this schedule builds the habit on a small project.

Frequently Asked Questions

Should I start with Postman or with DevTools?

Start with DevTools because it shows what your real front end actually sent and received. Use Postman second, to replay that request without the front end and see which side owns the fault.

Why does my API work in Postman but fail in the browser?

Browsers enforce CORS and send cookies and headers that Postman does not by default. Check the Console for a CORS message, confirm your server allows your front-end origin, and compare the headers of the browser request with your Postman request.

Does a 200 status mean the feature works?

No. It only means the server responded successfully. Check the response body and confirm the data changed, as in the profile example above.

How do I debug a 500 error?

The browser cannot tell you the cause. Look at your server terminal for the stack trace, reproduce the request in Postman, and log the incoming body and the database result inside the failing route.

Is console.log enough, or should I learn breakpoints?

Console logging is fine for quick checks. Breakpoints in the Sources tab let you inspect many variables at once and step through code, which is faster for complex state bugs. Learn both.

What should I put in a debugging log if I am short of time?

At minimum: expected result, actual result, the network evidence (method, URL, status), the layer you identified and the fix. Those five fields take about two minutes.

Will a debugging log count for marks or credit at my college?

That depends on your college and scheme, and it was not verified here. Ask your project coordinator in writing whether process documentation is assessed. Even if it is not, it strengthens a project report or portfolio.

Is it safe to share my Postman collection on GitHub?

Only after removing real tokens, passwords, API keys and database URLs. Use environment variables with placeholder values, and share the collection without the environment’s secret values.