Loopback4 "todo" tutorial seems to be only partially working

Question

I'm new to Loopback4 and I've just completed the "todo" tutorial, installing it exactly as documented.

Some routes seem to work fine. I can add a todo item, query it by id, delete it by id, etc. But the GET /todos/count and GET /todos don't seem to work. The first returns 0 and the second returns an empty list. However, I can see data in db.json, and again I can get them by ID.

Am I missing something here? Anyone know why these might not work?

On a related note, can you give advice on how to debug? I enabled debug strings, but nothing useful seems to be output. There are no errors.

Answer 1

This "issue" has been quite extensively documented issue #6662.

The Short Answer

Swagger UI, the underlying library used by API Explorer substitutes missing example queries from the OpenAPI 3.0 spec with its own generated query on a best-effort basis. Most of the time, this may not be ideal and usually generate an over-restrictive query filter.

Why It Happens

LoopBack 4 REST by default generates and exposes an OpenAPI 3.0 spec under /openapi.json and openapi.yml. This can be used by API consumers and code generators to programmatically interface with the API.

One of those API consumers is the API Explorer (powered by Swagger UI), reads the OpenAPI 3.0 spec to generate the user interface and the example parameters.

Swagger UI's Examples

Swagger UI, the underlying library powering the API Explorer attempts to create an "example" HTTP query based on the OpnAPI 3.0 spec.

However, these examples are not usable out-of-the-box; They're typically meant to be used as a guide on the expected syntax for that parameter.

GET /todos

In the case of GET /todos, the LoopBack 4 is expecting a Filter:

The Filter is used to narrow the scope of the query, and the example generated by Swagger UI is very restrictive. This is because Swagger UI's generated examples are meant to show all possible properties in the parameter.

Most notably, Swagger UI adds additionalProp* in the WhereFilter when the API supports additional properties. This is not useful as these properties do not exist within the current database.

By clearing the Filter query before pressing Execute, we are telling LoopBack 4 not to narrow the scope of the request.

GET /todos/count

Unlike GET /todos, GET /todos/count expects a WhereFilter only as the broader Filter properties such as order, skip, limit, etc. are not applicable when returning a single count value.

Nonetheless, the same issue applies with additionalProp* being added into the WhereFilter.

Why isn't the Filter Model-aware?

At this moment, this feature is being tracked by issue #4977.