ADR-201: Lambdas Wearables API Analysis

More details about this document
Latest published version:
https://adr.decentraland.org/adr/ADR-201
Authors:
pedrotambo
Feedback:
GitHub decentraland/adr (pull requests, new issue, open issues)
Edit this documentation:
GitHub View commits View commits on githistory.xyz

Abstract

The Explorer uses the Lambdas API /collections/wearables to get wearables. This API sometimes has bad performance (high response time with spikes of ~30s), it has an ill design and the handrail between the Explorer and the Content Server through Lambdas might not be necessary. In this document we review the functionalities of this API and analyze solutions to these problems.

Context, Reach & Prioritization

During the last MVFW, some APIs suffered from performance degradation. Among those APIs, there was the Lambdas endpoint GET /collections/wearables.

API Functionality

First, a review of the functionalities of the API will be covered. The API, based on the request filters, gets the wearables from the Content Server, applies a small transform and returns the result to the client.

Request filters

The API allows three query parameters:

Transform: Wearables from the Content Server to the Client

  1. First the wearable data from the Content Server is retrieved with this schema.
  2. Then only the metadata of type Wearable is returned to the client, but a small transform is applied: the contents are extended with full url.

Entity

Explorer use cases of the API

The API has many funcionalites, but the Explorer doesn't use all of them. After reviewing the unity-renderer repository, two use cases were recognized (check with Explorer Team):

  1. wearableIds: The Explorer requests multiple wearables by URN. From the user profiles it reads the wearables that the user is wearing and request them. Note that the user can wear wearables from different collections.
  2. collectionIds='urn:decentraland:off-chain:base-avatars': It uses the API functionality of requesting items from a collection but always for the base-avatar one. It should be because it is always needed for configuring the backpack where the base avatars are always available.

Solution Space Exploration

Solution: Explorer directly hits the Content Server

Are these functionalities (strings concatenation mostly) currently worthy enough to have a handrail between the Explorer and Content Server through Lambdas?

The Content Server provides the API POST /entities/active { pointers: string[], ids: string[] } for requesting multiples entities (that was not available at the time of the Lambdas API creation). The returned entities won't have the transform currently provided by Lambdas, so the Explorer will have to concatenate the Content Server url to the hashes of the contents.

Benefits of this solution

Alternative Solution: Redesign and Implement only used functionalities in Lamb2

Instead of having a single API supporting multiple functionalities, only two different APIs are proposed for each of the two use cases needed by the explorer:

RFC 2119 and RFC 8174

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

License

Copyright and related rights waived via CC0-1.0. DRAFT Living