Nuestra APIDaniel RabinovichCTO - MercadoLibre@drabinovich

Agenda

Quiénes somos

Nuestra API

MercadoLibre

#1 sitio de e-commerce más grande del LatAm

#8 sitio de e-commerce más grande del mundo

90MM usuarios registrados

23MM usuarios activos (operaron en 2012)

5,7BN de dólares transaccionados (2012)

275% de crecimiento desde el IPO (2007)

Un poco de "scalability porn”

7Gbps de tráfico

1,4 BN de hits al día en el front-end 7,2 BN de hits al día en la API

1800 búsquedas por segundo

95 bases de datos

930TB de data en bases de datos

120TB de fotos

Un ecosistema de ecosistemas

MercadoPago

Publicidad

MercadoEnvios

MercadoShops

Agenda

Quiénes somos

Nuestra API

Contexto

Diseño

Monetización

Monolítico -> DesacopladoNacimos monolíticos, desacoplamos (justo) a tiempo

Flexibilidad

Escalabilidad

Apertura

Control

Performance

Monolítico Desacoplado

Monolitos -> presión crecienteCambios en el entorno exigen flexibilidades para las que no están preparadas

Monolítico

Escalar el equipo

Múltiples "pantallas"

Velocidad de desarrollo

Abrir la plataforma

Qué no hicimosLas APIs como “backdoors” nacen condenadas a muerte

Developers

APIs

Usuarios

Comemos el pescado que vendemos

Front-end Mobile Back-end

Una única API

Developers

Compartimos exactamente la misma API que usamos para nuestros front-ends

Una API es una necesidad interna, antes que una externa

Partimos MercadoLibre en 100 “celdas”

Code

Infrastructure Data

Team

Facebook

Search

View Item Paage

Listings

Users

Orders

Cada “celda” funciona como si fuese una empresa independiente

Posponer soluciones!=

No prever soluciones

"The bright side of being late is that (if you're still alive) you

can leapfrog"

Agenda

Quiénes somos

Nuestra API

Contexto

Diseño

Monetización

REST sobre HTTPEl mundo descripto en términos de “recursos”

/sites/MLA

/users/4605484

/items/MLA473364655

/pictures/MLA3004267263_082012

Sólo verbos estándar HTTPMinimizan la necesidad de leer documentación

Obtener Crear Modificar Borrar

Verbos STD evitan DOCsEn SOAP podría ser “updateUser”, “alterUser”, etc. Sobre REST no hay duda!

PUT /users/4605484{

last_name: “Fagúndez”

}

Una API no sólo es una interfaz para computadoras.

Repasamos conceptos de UsabilidadPueden aplicarse directamente a los usuarios de una API

Learnability

Efficiency

Satisfaction

Pretty Print: la vista para el DeveloperLa API detecta cuando se navega desde un browser, y se “autodocumenta”

Para máquinas Para humanos

Pretty Print: recursos relacionadosLos IDs se transforman en links en la vista “para humanos”

Introspection: la API se autoexplicaLa API genera su propia metadata a través del verbo STD "OPTIONS"

OPTIONS /sites

Usabilidad orientada al programadorLas convenciones son el activo oculto más importante de una API

• “AR” vs “0001” (ISO codes sobre códigos “inventados”)

• “seller_id” vs “customer_id” (reduce ambigüedad)

• “condition: used” vs“used:true” (escalable, evita cambios de firma ante nuevos valores)

• Diseñar para el caso canónico (Desnormalizar inteligentemente, evita requests innecesarios)

Diseñar para el caso canónicoEj: el GET /items tiene como caso canónico mostrar la página de producto

GET /items/MLA472660878

Caso canónico justifica desnormalizarLa API de un artículo resuelve la URL de la foto para evitar el request adicional

/items/MLA472660878

El problema “N+1”Típico en front-ends de listados: 1 request para los IDs + uno por cada producto

Sergún REST “Kosher”

20 filas = 21 requests

• 1 para los IDs• 20 requests para

las descripciones

SelectionLa capacidad de pedir menos atributos que los dflt del recurso

/items/MLA121484389?attributes=title

{ title: "Boomerang Artesanales De Alta Calidad}

2K

340b -> -84%

N+1 -> Selection + MultigetMultiget: la capacidad de obtener N recursos en un solo API call

/items?ids=MLA121484389,MLA125002468&attributes=title

[-{

title: "Boomerang De Diseño Australiano Con Retorno" }-{

title: "Boomerang Artesanales De Alta Calidad" }

]

"There is no free Lunch"

Selection y Multigetson violaciones a REST

con costos ocultos

Difícil de “cachear” y “shardear”

Amigarse con la inconsistenciaPrerrequisito básico para poder escalar horizontalmente

• Brewster’s CAP Theorem (Consitency, Availability, Partition Tolerance; pick 2)

• El trade-off en realidad es A vs C.

• En el 99% de los casos, elegimos A+P

• Las propiedades A[C]ID no deben ser defaults

• Consistencia -> Inconsistencia eventual

El verbo SEARCH: reglas de convivenciaRecursos base: CRUD + push para que otros armen índices

SearchListings

Push notifications

Recursos base(sólo CRUD)

Consultascomplejas

Un ejemplo simplePara buscar por "apodo" habría que crear un índice en el recurso USERS

/users/search?nickname=LEWIS_CARROLL

Balancear requests a la “celda” correctaCada celda es responsable de generar sus propias reglas de balanceo

Users SearchUsers

/users/search?nickname=LEWIS_CARROLL/users/4605484

El usuario debe percibiruna sola API

Estandarización del paginadoOFFSET y LIMIT mejor que PAGE=N, permite controlar el tamaño de la página

/sites/MLA/search?q=boomerang&limit=2&offset=10

Caching es diseño, no optimizaciónLas estrategias de cacheo pueden alterar el diseño

• Validation: Consistente, pero con penalties de performance 2 HTTP Headers: Etag (If-None-Match) y Last-Modified (If-Modified-Since)

• Expiration: Mucho más rápido, pero eventualmente inconsistente HTTP Header: Cache-Control: max-age=X, public

Autenticación y autorizaciónSon dos conceptos muy diferentes

Autenticación:Confirmar la identidad del usuario

a través de ciertas credenciales (ej: pwd)Administrada por Plug-Ins centralizados

Autorización:Confirmar si un usuario puede ejecutar

una acción (ej: modificar un artículo)Administrara por el desarrollador (con defaults)

AutenticaciónOAuth 2.0 permite que aplicaciones

3 actores:• MercadoLibre• Usuario• Aplicación

OAuth permite que aplicacionesejecuten acciones en nombrede usuarios sin acceder a suscredenciales (pwd)

Recursos públicosSon visibles para todos los actores del sistema

GET /users/46054484

Recursos privadosSon accesibles sólo para sus dueños. OAuth les provee un ACCESS_TOKEN

GET /users/me?access_token=ABC

El usuario “autoriza” las appsA operar en su nombre. El app no obtiene acceso a sus credenciales.

Las reglas de negocio son parte de la APIEs una excelente manera de no duplicar lógica

Por ejemplo, las reglas de pricing son consumidas desdeel flujo de venta y desde el back-end de atención al cliente

Lockeos y HTTPUn mecanismo elegante dentro del protocolo, para hacer optimistic locking

Una manera de aplicar optimistic locking usando HTTP

- GET /users/123- Etag = ABC

- PUT /users/123 - If-match: ABC

(Aplicar si nadie modificó el objeto)

Atómico y StatelessIndependientemente de la cantidad de pasos que tengan los front-ends

UserSYI

FrontEndItemsAPI

Select Category

Item Details

Listing Types

Confirmation

POST Item

Responsabilidad

del FrontEnd

Request

atómico

HTTP return codes -> Parte de la APICuanto más estándares usemos, más gente sabrá usar la API sin leer la DOC

201: Object Created206: Partially created (ej: completar el pago para crear una orden)

401: Unauthorized404: Not found410: Gone

500: Internal Server Error501: Not implemented

Push NotificationsClientes externos pueden suscribirse a "Topics"

VersionamientoLa API debe cambiar a distintas velocidades según el tipo de app que soporta

VersionamientoLa API debe cambiar a distintas velocidades según el tipo de app que soporta

api.mercadolibre.com v1.api.mercadolibre.com

Fuente: Darío Simonassi

ComunidadEl "churn" de developers es enorme sin una comunidad fuerte detrás

developers.mercadolibre.com

github.com/mercadolibre(js-sdk, java-sdk, net-sdk, php-sdk)

@melidevelopers

#meli@irc.freenode.net

SDKsProveen un buen rest client y los flujos de OAuth

Agenda

Quiénes somos

Nuestra API

Contexto

Diseño

Monetización

TML-YLGDE

Fuente: Fede Procaccini

Esquemas de monetización

Compradores17MM (2012)

Vendedores6MM (2012)

150K profesionales

Revenue Share(compartimos la

comisión por venta)

Aplicacionesque produzcan

mejoras operativas

El nicho: servicios a vendedoresGestores de ventas, inventario, logística, integradores con ERPs, CRMs, etc

La API está tomando tracciónRetailers, Integradores, Gestores de Ventas y ERPs están usando la API

Algunos númerosEl segmento más activo son aplicaciones para vendedores

33K apps activas

2,6MM usuarios aceptaron al menos 1 app

50% de top sellers aceptaron al menos 1 app

Se hacen a través de la API:

• 3% del total de compras móviles

• 7% del total de publicaciones

• 19% de los updates a listings

Pero.. faltaba un eslabónQué pasa cuando un startup no tiene dinero para empezar?

APIexitosa

Tecnología

Monetización

Comunidad

Financiamiento

Creamos un fondo de US$ 10MMPara invertir en startups que mejoren el ecosistema de MercadoLibre

Ya hicimos las primeras 3 inversiones de US$ 100.000 c/u:

• Mr Presta: Microloans. Scoring basado en historial de ventas

• Nubi Metrics: Business Intelligence para vendedores

• Parsimotion: cloud based ERP orientado a supply-chain

Agenda

Quiénes somos

Nuestra API

Recapitulando…

Recapitulando…

• La API es primero una necesidad interna.

• No es sólo una interfaz para computadoras.

• Desnormalizar inteligentemente.

• Amigarse con la inconsistencia.

• Posponer soluciones != no preverlas.

• El usuario debe percibir una sola API.

• Pensar en monetización desde el día 0.

Gracias!@drabinovich