API Consumption

HTTP client

@nuxtjs/axios (^5.13.6). nuxt.config.js configures:

axios: { baseURL: process.env.baseURL }

So all calls go to ${baseURL}/<endpoint> where baseURL points at designer-api.

Wrapper layer

The Vuex store (store/index.js) is the single wrapping layer. Two helper functions (likely in helpers/ — verify) are used by every action:

const { status, data } = await postData(this.app.$axios, '/endpoint', params)
const { status, data } = await getData(this.app.$axios, '/endpoint')

The store actions are essentially:

async getX({ commit }, params) {
  const { status, data } = await postData(this.app.$axios, '/getX', params);
  if (status === 200) commit('SET_X', data);
  return data;
}

Most of store/index.js's ~100+ actions follow this shape.

Axios interceptor — middleware/axios.js

export default function ({ $axios }) {
  $axios.interceptors.request.use((config) => {
    config.headers.apptype = Buffer.from(process.env.APP_TYPE, "utf8").toString("base64");
    return config;
  });
}

Every request gets an apptype header that's the base64-encoded APP_TYPE env var. The BE (designer-api) reads this to identify the calling app.

Auth header

@nuxtjs/auth's local strategy attaches the auth token automatically. Format: probably Authorization: Bearer <token> (verify). The exact header is set when login succeeds.

Login

Hits webauthenticate (per nuxt.config.js auth strategy):

auth: {
  strategies: {
    local: {
      endpoints: {
        login: { url: 'webauthenticate', method: 'post', propertyName: 'data' },
        user: { url: 'me', method: 'get', propertyName: 'data' },
        logout: false
      }
    }
  }
}

On success, @nuxtjs/auth stores the response's data.token (or whatever the BE returns) and uses it for subsequent requests.

Logout

logout: false — @nuxtjs/auth does not call a BE endpoint on logout. Client-side only:

1. Clear the auth state ($auth.setUser(null))
2. Clear cookies
3. Redirect

This means a token issued to the designer FE is never explicitly revoked. See security.md.

Error handling

Each store action checks status === 200. On non-200, it console.logs and returns the data anyway. There is no central error handler — components must check data.status (or assume null on failure).

Toasts are shown via vue-notification or vue-toastification, but inconsistently — many error paths just console.log and the user sees no UI feedback.

Endpoints used

A spot-check of store/index.js shows calls to:

• /commonPagecount
• /getUserDesignList, /getAllUserDesignList, /getEditDesignList
• /userlist
• /designUpload

And probably 100+ more across the file. The FE is hitting designer-api's ~269 endpoints; cross-reference with ../designer-api/API-inventory.md.

Retries

None.

Cancellation

None. A user navigating away from a page mid-request triggers setState-on-unmounted-component warnings (Vue 2 may suppress these; verify).

Response shape handling

Most BE responses are { status, data, code, message }. The store actions read status from the HTTP status (not the body's .status), then read data from the body. Verify: which status does the handler check?

If the helper unwraps to { status: httpStatus, data: body }, then status === 200 means "got 2xx HTTP response". If it unwraps to { status: body.status, data: body.data }, then status === 200 means "BE handler returned code: 200 in the envelope".

The convention matters because BE handlers sometimes return HTTP 200 with body.status = false (a soft failure). If the helper checks HTTP status, soft failures pass; if it checks envelope, they don't.

Recommendations

ID	Recommendation	Effort
A-1	Add central error handler that toasts on failure (so users see something when a call fails)	Small
A-2	Standardise response-shape checking (HTTP status vs body envelope — pick one)	Small
A-3	Add 401 handler that triggers logout + redirect	Small
A-4	Add request cancellation (axios CancelToken or AbortController) on route change	Medium
A-5	Add a 5-minute cache layer (mirror someli-platform/store/api.js pattern)	Medium
A-6	Extract action methods into services/ instead of cramming into store actions	Medium
A-7	Document the apptype header semantics — what does each APP_TYPE value mean to the BE?	Trivial