feat(customer): list customer

[srindom]

What

• GET /admin/customers
• GET /admin/customer-groups

[changeset-bot]

⚠️ No Changeset found

Latest commit: a63119d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
medusa-dashboard	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 29, 2024 4:36pm

3 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
api-reference	⬜️ Ignored (Inspect)			Jan 29, 2024 4:36pm
docs-ui	⬜️ Ignored (Inspect)	Visit Preview		Jan 29, 2024 4:36pm
medusa-docs	⬜️ Ignored (Inspect)	Visit Preview		Jan 29, 2024 4:36pm

[carlos-r-l-rodrigues]

We can align how we want to build the GET endpoints.
I believe we should use the remoteQuery to be able to easily expand relations from here.

We have 2 utils that can help on that:
remoteQueryObjectFromString and remoteQueryObjectToString

we can discuss it on Monday and come up with a pattern to follow in all the api-v2 endpoints. cc: @adrien2p @olivermrbl

[srindom]

Agree remote query should be the way to go - do we have an example implementation of the approach somewhere?

[carlos-r-l-rodrigues]

We have mixed examples that we need to normalize from now on.
I believe this test is a good starting point, where we have a list of all default fields and relations to be listed. We need to think about and implement how to have a list of "allowed" relations to be expanded, and how to customize this list, adding custom relations to it.

from there it is used like this:

const remoteQuery = container.resolve("remoteQuery")

const query = remoteQueryObjectFromString({
  entryPoint: "product",
  variables: {},
  fields,
})

const results = await remoteQuery(query)

variables are handled here before calling module.list(filters, options)
We can send all the filters and options needed to the service from here.

As this will be replicate in most GET endpoints, I think it worth spending some time in it, even if in another PR.

[srindom]

I think I will need to see an example with filters and expands applied - I wasn't able to get this to work for these.

I suggest that we merge PRs without RemoteQuery until we have its feature set more standardized.

[carlos-r-l-rodrigues]

LGTM