Upload
daniel-rabinovich
View
1.456
Download
4
Embed Size (px)
DESCRIPTION
Citation preview
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
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
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