Debugging a Web application
Is it a front or a back issue?
Although we have a workflow that prevents bugs, we are all familiar with the following: we are peacefully developing a new feature, when all of a sudden Slack is going crazy. Notifications popping up everywhere, everybody pinging @here…
The origin of this mess is simple, the QA has just calmly announced that …
We have some trouble on prod. Is someone on it?
The first reflex is to check the last deploys, so that we can go back to the most recent stable version. Once done, we take a breath: the application is usable again, but our issue is far from being fixed… The bug must still be solved!
Next we must ask: where does the problem lie?
We quickly need to put aside most of the possible sources by asking a second question: is this bug a front-end or a back-end one?
The answer should not be hard to find, and yet: I have spent so much time investigating bugs only to find they were coming from the API not sending a correct data structure…
And reverse, of course: our back-end friends are fortunately not always the guilty developers!
Quickly discerning if the origin of the bug is back or front is essential to be as efficient as possible. But how can we know?
It depends on the context and technologies we are using on the project. At OpenClassrooms, we have modern pages built with React, communicating with an OAuth2 API… but we also have some legacy pages in Twig and good old jQuery. It is obvious that the debugging cannot be done the same way in each of these cases…
…Really? Not sure.
In this article, I’ll share two very different situations we experienced at OpenClassrooms, explaining how we got to the conclusion that the bug came from the back-end… or the front-end (which is, of course, way less frequent 🙃 ).
Issue #1 : English courses are displaying twice and the French ones are missing!
Context : data injected in a Twig page, then updated via API.
In order to handle our many mentors and students, the OpenClassrooms team can fill in a lot of different forms.
Because our administrators use to search for some courses, we have created an Autocomplete component communicating with our API.
Let’s focus on a specific form where we can search French and English courses separately:
The problem we faced was a bit strange: whatever the submitted values were, only english courses were being displayed after page reload.
However, the stored values in the database were correct; only the display was inconsistent. The conclusion seemed to be obvious: the issue was a front-end one.
Maybe there was a conflict when the Autocomplete was used several times in the same page? After all, it’s the first time we’ve faced this scenario.
That’s said, values were correctly saved in database, meaning that the Autocomplete worked well: it suggested the right information and sent them correctly to the server. It means there were no problem with requests to the API.
Since the issue was only on the display, we had to check what the component received from the Twig template.
Big surprise! All Autocomplete components of the page received only English courses. This component is dumb, it simply displays what it receives without any treatment… Meaning that the issue was on the back-end side!
It was a dark story of a Symfony loader that was static and did not re-instantiate properly (something back, nothing to do with the front!).
Issue #2: course category colors are missing!
Context: data received from API requests.
Before speaking about this issue, you should know that we have recently deployed a new interface for displaying courses search results.What is specifically relevant to the next bug is that each of our course categories now appear in a specific color:
Even if it’s a display matter, it has been decided that these colors are part of our business rules: so we receive them from the API.
But during the development of this small feature, we had an erroneous rendering:
As mentioned, the color is sent by the API: since everything was black, it seemed obvious that it was because the front-end did not receive any color. A back-end problem, in short!
Furthermore, the React component displaying a course handled this color:
But upon further inspection, we discovered that this CourseListItemWithWrapper component is a container of CourseListItem. It turns out that this last handles a special case for when the given course is not available yet:
This was the origin of the problem: if we look attentively at the previous container, we can see that the category color is indeed sent, but not the openedAt property. Without this information, the color can’t be displayed. The issue was indeed on the front-end side…
Conclusion: check the data first.
Even if these two issues had different origins, they have one thing in common. It would have been a lot quicker to find the source of the problem by first checking one place: the back-end return.
As soon as there is a display issue, or a data inconsistency, your first reflex should be to check data sent by the back-end… before you add any breakpoints in your code and before even opening your IDE!
If this data matches the contract defined between the front and back teams, it means that the issue comes from the front-end, in 100% of the cases.
Otherwise, we first need to fix the back-end bug. It may be enough to correct the main problem, or it may reveal another one… but on the front side, this time.
