to decide: functions API

[dbarrosop]

Functions can accept any combination of headers, methods and even content-types so our SDK should be able to accommodate any potential combination of parameters and assume nothing. In the current implementation we have the following:

  const fetch = async (
    path: string,
    options?: RequestInit,
    // eslint-disable-next-line @typescript-eslint/no-explicit-any
  ): Promise<FetchResponse<any>> => {
    const resp = await enhancedFetch(`${baseURL}${path}`, options);

    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    let body: any;
    // Process response based on content type
    if (resp.headers.get("content-type")?.includes("application/json")) {
      body = await resp.json();
    } else if (resp.headers.get("content-type")?.startsWith("text/")) {
      body = await resp.text();
    } else {
      body = await resp.blob();
    }

    // Create response payload with status, body and headers
    const payload = {
      status: resp.status,
      body: body,
      headers: resp.headers,
    };

    // Throw error for non-OK responses
    if (!resp.ok) {
      throw payload;
    }

    return payload;
  };

so the only processing we do is check for the response type and return an appropiate value for it but I am wondering if we should do no such thing and always return the blob in all cases so the user can process as/if needed.

The only issue is that using this involves passing all the parameters and all headers that fetch needs:

const resp = await nhost.functions.fetch("/myfunction", {
   method: "POST",
   body: JSON.stringify({...}),
   headers: {
      "Content-type": "application/json",
   },
})
// with the implementation above
const payload = resp.body as MyCustomType;
// or if we decide to always return a blob, which might be more efficient in cases where the
// payload doesn't need to be consumed
// const payload = JSON.parse(await resp.body.text()) as MyCustomType;

However, this is a bit cumbersome for the typical case; POST and application/json in the request so we could potentially add an invoke(...) method that:

1. assumes POST, always, otherwise use fetch
2. assumes Content-type: application/json
3. processes the response like in the example above

so it could be used as:

const resp = await nhost.functions.fetch("/myfunction", {
   body: {...},
})
const payload = resp.body as MyCustomType;

thoughts?

[PrinzKenny1]

Hi, what about something like this:

type FetchResponse<T> = {
  status: number;
  body: T;
  headers: Headers;
};

const standardRequest: RequestInit = {
  headers: {
    method: "POST",
    "Content-type": "application/json",
  },
};

// Overload signatures
function enhancedFetch(
  path: string,
  options?: RequestInit,
  preprocess?: boolean
): Promise<Response>;

function enhancedFetch<T>(
  path: string,
  options?: RequestInit,
  preprocess?: boolean
): Promise<FetchResponse<T>>;

async function enhancedFetch<T>(
  path: string,
  options: RequestInit = standardRequest,
  preprocess = true
): Promise<Response | FetchResponse<T>> {
  const combinedOptions = { ...standardRequest, ...options };

  const resp = await fetch(`${baseURL}${path}`, combinedOptions);

  if (!preprocess) {
    return resp;
  }

  let body: unknown;
  // Process response based on content type
  if (resp.headers.get("content-type")?.includes("application/json")) {
    body = await resp.json();
  } else if (resp.headers.get("content-type")?.startsWith("text/")) {
    body = await resp.text();
  } else {
    body = await resp.blob();
  }

  // Create response payload with status, body and headers
  const payload: FetchResponse<T> = {
    status: resp.status,
    body: body as T,
    headers: resp.headers,
  };

  // Throw error for non-OK responses
  if (!resp.ok) {
    throw payload;
  }

  return payload;
}

This would set some standard behaviour and yet would give the user the freedom to customize it to their use case.

E.g.

await enhancedFetch<MyCustomType>("/test", {
    body: "test",
    headers: {
      "Content-type": "text/html",
    },
  })

Would return a FetchResponse where it got preprocessed and when you access the body you'll have an object of type MyCustomType.

However if you do

await enhancedFetch(
    "/test",
    {
      body: "test",
    },
    false
  );

You'll get the raw fetch result and could do whatever you want.

Ofc in both cases you're able to customize all parameters like path, headers, body, method and so on. I hope I did understand you correctly and this can give you some inspiration :)

[dbarrosop]

That's a possibility. The only thing I don't like is that it fundamentally changes how the default "fetch" works (changing the default method, GET vs POST and content-type plain vs json) so it might confuse users used to fetch. That's why I was proposing leaving fetch as just a fetch wrapper and adding an invoke method where we just optimize for the common use-case.