Whether all error messages should come from the backend in a form that can be shown to the user?

Question

The situation is such that I use the axios library and interceptors of successful and unsuccessful requests in order to automatically pick up and display an alert with the error text from the server in case of an error.
So my backend developer sends me error messages that are not suitable for output to an alert arguing that the message is I have to generate the error myself, but what comes from the server is only needed so that I know about the error. Is he right, or sending an error message from the backend should go strictly like response.message and match the error format displayed to the user on the UI?

The universal error interceptor that I spoke about looks like this, but the errors that it sends to me each time are on a different path, while their format is not suitable for displaying to the user, and often an array with errors comes to the request. Is he doing the right thing?

Because in that case, I cannot use the code below to handle errors

const API = axios.create({
  baseURL: '/api/',
  responseType: 'json',
  headers: { 'cache': 'no-store' },
})

const onFulfilled = (response) => response.data


const onRejected = (error) => {
  if (error.response?.status === 500) {
    notify(error.response.statusText || ' Internal server error', 'error')
  } else if (error.response?.data.message) {
    notify(error.response.data.message, 'error')
  } else {
    notify('Oops something went wrong', 'error')
  }
  ..... and so on
  return Promise.reject(error)
}

API.interceptors.response.use(onFulfilled, onRejected)

Answer 1

In most applications, there's a true back-end that carries out operations on data (retrieving, modifying, deleting, adding). That true back-end has nothing at all to do with the presentation to the user. If it has an error, it should just report that error back to the presentation layer and then it's up to the presentation layer to know what the user context was and what is and isn't appropriate to communicate to the user.

The presentation layer can be entirely in the front-end or it may be a combination of back-end template rendering and front-end display. In any case, it is the presentation layer's job to display error messages to the end user in a form that fits the context and will make sense to the user. Sometimes this presentation will also include an error code (for use in more detailed bug reports and troubleshooting), but that error code will not, by itself, generally be useful to the user except for more detailed reporting of a problem.

So, there is no precise answer to front-end or back-end since sometimes the back-end is involved in rendering content for the front-end to display. Whatever layer is presenting information to the user (wherever that is) is what should be making an error message for the user.

If you then throw in language support where you have a front-end that can be displayed in many different languages, you can immediately see that you don't want your data managing back-end APIs to have to be responsible for rendering error messages in a whole bunch of different languages. That is clearly the responsibility of a separate presentation layer.

Answer 2

Errors must be driven from scenarios, api must return right indicator to represent the true end to end state, and direct/inform user about what they need to do next or what happened in the system: generic messaging structures should be avoided in api, except for 404 or 501, 500 failure. Each logical message must have a instructional value to reduce the cognitive load.

Example: a cart item may not be returned due to invalid product id, or due to out of stock situation, or may be missing requires information in the object.. all of these scenarios must return a meaningful indicator to let frontend display informative and clear message to the user about end system state in user friendly manner.

IT teams must lead this effort and help business partners to implement right messaging verbiage. This would be impactful only if there is proper API to Front end messaging framework design is in place covering functional and non-functional scenarios.