What about filter ?

[TheoD02]

Hi there!

First of all thank you for the packages you were publishing! :)

I have a question concerning the api-lite, I'm hesitating for a new project how to implement the api.

Either via the usual controller approach, with nelmio api doc bundle, and the new attributes for managing payloads, queries and so on.

Or via the API Platform implementation, which seems very interesting with the DTO approach, but it's precisely the filtering part that makes me hesitate, as the current API Platform implementation is extremely linked to Doctrine. This makes the filter part a bit more complicated than the other approach.

What do you have in mind for the filter part?
Have you already started working on this? I'm ready to participate in this implementation if needed :)

[priyadi]

For filtering, I suggest doing it manually for now, which is pretty simple to do. I just committed a simple example in our tests: 23eed90

For a better DX & encapsulation, I have some ideas, but I have been postponing the implementation because I currently don't need filtering in the app we are developing. I'll try writing them down here in a few hours.

[TheoD02]

Thank you for your reply :)

Yes, that's something I've already managed to do, also with the help of this implementation symfony/symfony#53915 to keep precisely the use of MapQueryString attribute.

I look forward to hearing from you, take your time :)

[priyadi]

@TheoD02 Sorry for the late response. I'm currently working on a pagination framework that supports keyset pagination. One of the aims is that I want it to be decoupled from the filtering framework. Whether I will be successful on that decides how I want to proceed with this.

Currently, all (?) keyset pagination framework are designed to be coupled with filtering, which limits how we do the filtering. This includes how API Platform core implement keyset pagination.

I hope to publish the first version of my pagination framework some time this week.

[priyadi]

The pagination framework is done: https://github.com/rekalogika/rekapager

So that's one piece of the puzzle.

[TheoD02]

Apologies for the Delayed Response :/

I haven't had much time to work on it this past month😄, but I found some time this week to work on the filter with API Platform! :)

Here are some approaches that worked on my side without using your package for now.

Resource:

#[ApiResource(
    operations: [
        new GetCollection(
            uriTemplate: '/users',
            filters: [UserCollectionFilter::class],
            provider: UserCollectionProvider::class
        )
    ]
)]
class UserResource
{
    #[ApiProperty(identifier: true)]
    public int $id;

    public string $name;
}

Filter Definition:

#[AsApiFilter]
class UserCollectionFilter implements ApiFilterInterface, QueryBuilderApiFilterInterface
{
    #[ApiParameter(description: 'Filter by something.')]
    private ?string $customFilter = null;

    public function definition(): FilterDefinitionBag
    {
        return new FilterDefinitionBag(FilterDefinition::create()->field('name')->addOperator(ContainsOperator::class));
    }

    public function applyToQueryBuilder(QueryBuilder $qb): QueryBuilder
    {
        // Need some relations to filter by?
        // $qb->leftJoin('u.relations', 'r');

        if ($this->customFilter) {
            $qb
                ->andWhere('u.id >= :customFilter')
                ->setParameter('customFilter', $this->customFilter);
        }

        return $qb;
    }
}

The logic behind this class is to define common operators through FilterDefinition with some operators like eq, neq, gte, etc. If we need some filter that requires more logic, add a relation, or don't want to pass by filter definition, we can add QueryBuilderApiFilterInterface to interact with QueryBuilder. I have also created CriteriaApiFilterInterface for Doctrine Criteria support, but I haven't tested this one thoroughly yet.

Provider:

/**
 * @template-extends AbstractProvider<UserResource>
 */
final class UserCollectionProvider extends AbstractProvider
{
    /**
     * @return array<UserResource>
     */
    #[\Override]
    public function provide(Operation $operation, array $uriVariables = [], array $context = []): array
    {
        $qb = $this->repository->createQueryBuilder('u');

        return $this->mapItems($qb, $operation, $context);
    }
}

Under the hood, mapItems for now is like mapCollection but with Jolicode automapper. In api-lite, the filter would be applied in PaginatorApplier i think.

Documentation is well generated with some injection in OpenAPI doc with ResourceMetadataCollectionFactoryInterface.

What Do You Think About This Approach?

For now, the code is in the project without a bundle. I will extract the code soon to provide you with a repository to see in depth how it works 😄
EDIT: here the repo api-platform-filters-poc

Additional:

Here is the code for ContainsOperator, for example:

class ContainsOperator implements OrmOperatorInterface, StringOperatorInterface
{
    use ParameterNameGeneratorTrait;

    #[\Override]
    public function queryOperatorName(): string
    {
        return 'contains';
    }

    #[\Override]
    public function description(): string
    {
        return 'Partial string match';
    }

    #[\Override]
    public function apply(QueryBuilder $qb, string $rootAlias, string|array $value, \ReflectionProperty|FilterDefinition $filterDefinition): QueryBuilder
    {
        Assert::string($value);

        $parameterName = $this->generateParameterName($filterDefinition->getName(), $this->queryOperatorName());

        return $qb->andWhere(sprintf('%s.%s LIKE :%s', $rootAlias, $filterDefinition->getName(), $parameterName))
            ->setParameter($parameterName, "%{$value}%");
    }
}