Descargado 48 veces
![N+1 -> Selection + Multiget
Multiget: 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"
}
]](https://image.slidesharecdn.com/danielrabinovich-phpconference-131007083225-phpapp01/75/Daniel-rabinovich-php-conference-29-2048.jpg)
![Amigarse con la inconsistencia
Prerrequisito 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](https://image.slidesharecdn.com/danielrabinovich-phpconference-131007083225-phpapp01/75/Daniel-rabinovich-php-conference-32-2048.jpg)
Subido porDaniel Rabinovich
Daniel rabinovich php conference
La presentación describe la API de MercadoLibre. Es la API interna más grande de Latinoamérica, con 7.2 mil millones de solicitudes diarias. La API se diseñó inicialmente para uso interno pero ahora es utilizada por desarrolladores externos. El diseño se centra en ser amigable para programadores y en equilibrar consistencia y disponibilidad. La presentación también cubre temas como monetización, versionamiento y comunidad de desarrolladores.
Daniel rabinovich php conference
- 1. Nuestra API Daniel Rabinovich CTO- MercadoLibre @drabinovich
- 2.
- 3. MercadoLibre #1 sitio dee-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)
- 4. 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
- 5. Un ecosistema deecosistemas Mercado Pago Publicidad Mercado Envios Mercado Shops
- 6.
- 7. Monolítico -> Desacoplado Nacimosmonolíticos, desacoplamos (justo) a tiempo Monolítico Desacoplado
- 8. Monolitos -> presióncreciente Cambios 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
- 10. Comemos el pescadoque vendemos Front-end Mobile Back-end Una única API Developers Compartimos exactamente la misma API que usamos para nuestros front-ends
- 11. Una API esuna necesidad interna, antes que una externa
- 12. Partimos MercadoLibre en100 “celdas” Code Infra structure Data Team Facebook Search View Item Paage Listings Users Orders Cada “celda” funciona como si fuese una empresa independiente
- 13. Posponer soluciones != No preversoluciones
- 14. "The bright sideof being late is that (if you're still alive) you can leapfrog"
- 15.
- 16. REST sobre HTTP Elmundo descripto en términos de “recursos” /sites/MLA /users/4605484 /items/MLA473364655 /pictures/MLA3004267263_082012
- 17. Sólo verbos estándarHTTP Minimizan la necesidad de leer documentación Obtener Crear Modificar Borrar
- 18. Verbos STD evitanDOCs En SOAP podría ser “updateUser”, “alterUser”, etc. Sobre REST no hay duda! PUT /users/4605484 { last_name: “Fagúndez” }
- 19. Una API nosólo es una interfaz para computadoras.
- 20. Repasamos conceptos deUsabilidad Pueden aplicarse directamente a los usuarios de una API Learnability Efficiency Satisfaction
- 21. Pretty Print: lavista para el Developer La API detecta cuando se navega desde un browser, y se “autodocumenta” Para máquinas Para humanos
- 22. Pretty Print: recursosrelacionados Los IDs se transforman en links en la vista “para humanos”
- 23. Introspection: la APIse autoexplica La API genera su propia metadata a través del verbo STD "OPTIONS" OPTIONS /sites
- 24. Usabilidad orientada alprogramador Las 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)
- 25. Diseñar para elcaso canónico Ej: el GET /items tiene como caso canónico mostrar la página de producto GET /items/MLA472660878
- 26. Caso canónico justificadesnormalizar La API de un artículo resuelve la URL de la foto para evitar el request adicional /items/MLA472660878
- 27. El problema “N+1” Típicoen 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
- 28. Selection La capacidad depedir menos atributos que los dflt del recurso /items/MLA121484389?attributes=title { title: "Boomerang Artesanales De Alta Calidad } 2K 340b -> -84%
- 29. N+1 -> Selection+ Multiget Multiget: 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" } ]
- 30. "There is nofree Lunch" Selection y Multiget son violaciones a REST con costos ocultos Difícil de “cachear” y “shardear”
- 32. Amigarse con lainconsistencia Prerrequisito 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
- 33. El verbo SEARCH:reglas de convivencia Recursos base: CRUD + push para que otros armen índices SearchListings Push notifications Recursos base (sólo CRUD) Consultas complejas
- 34. Un ejemplo simple Parabuscar por "apodo" habría que crear un índice en el recurso USERS /users/search?nickname=LEWIS_CARROLL
- 35. Balancear requests ala “celda” correcta Cada celda es responsable de generar sus propias reglas de balanceo Users SearchUsers /users/search?nickname=LEWIS_CARROLL /users/4605484
- 36. El usuario debepercibir una sola API
- 37. Estandarización del paginado OFFSETy LIMIT mejor que PAGE=N, permite controlar el tamaño de la página /sites/MLA/search?q=boomerang&limit=2&offset=10
- 38. Caching es diseño,no optimización Las 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
- 39. Autenticación y autorización Sondos 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)
- 40. Autenticación OAuth 2.0 permiteque aplicaciones 3 actores: • MercadoLibre • Usuario • Aplicación OAuth permite que aplicaciones ejecuten acciones en nombre de usuarios sin acceder a sus credenciales (pwd)
- 41. Recursos públicos Son visiblespara todos los actores del sistema GET /users/46054484
- 42. Recursos privados Son accesiblessólo para sus dueños. OAuth les provee un ACCESS_TOKEN GET /users/me?access_token=ABC
- 43. El usuario “autoriza”las apps A operar en su nombre. El app no obtiene acceso a sus credenciales.
- 44. Las reglas denegocio son parte de la API Es una excelente manera de no duplicar lógica Por ejemplo, las reglas de pricing son consumidas desde el flujo de venta y desde el back-end de atención al cliente
- 45. Lockeos y HTTP Unmecanismo 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)
- 46. Atómico y Stateless Independientementede la cantidad de pasos que tengan los front-ends User SYI FrontEnd Items API Select Category Item Details Listing Types Confirmation POST Item Responsabilidad del FrontEnd Request atómico
- 47. HTTP return codes-> Parte de la API Cuanto más estándares usemos, más gente sabrá usar la API sin leer la DOC 201: Object Created 206: Partially created (ej: completar el pago para crear una orden) 401: Unauthorized 404: Not found 410: Gone 500: Internal Server Error 501: Not implemented
- 48. Push Notifications Clientes externospueden suscribirse a "Topics"
- 49. Versionamiento La API debecambiar a distintas velocidades según el tipo de app que soporta
- 50. Versionamiento La API debecambiar a distintas velocidades según el tipo de app que soporta api.mercadolibre.com v1.api.mercadolibre.com Fuente: Darío Simonassi
- 51. Comunidad El "churn" dedevelopers 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
- 52. SDKs Proveen un buenrest client y los flujos de OAuth
- 53.
- 54.
- 55. Esquemas de monetización Compradores 17MM(2012) Vendedores 6MM (2012) 150K profesionales Revenue Share (compartimos la comisión por venta) Aplicaciones que produzcan mejoras operativas
- 56. El nicho: serviciosa vendedores Gestores de ventas, inventario, logística, integradores con ERPs, CRMs, etc
- 57. La API estátomando tracción Retailers, Integradores, Gestores de Ventas y ERPs están usando la API
- 58. Algunos números El segmentomá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
- 59. Pero.. faltaba uneslabón Qué pasa cuando un startup no tiene dinero para empezar? API exitosa Tecnología Monetización Comunidad Financiamiento
- 60. Creamos un fondode US$ 10MM Para 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
- 61.
- 62. Recapitulando… • La APIes 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.
- 63.