Dominando la paginación en Django REST: Creación de clases personalizadas para APIs globalmente escalables

En el mundo del desarrollo web, la creación de APIs robustas y escalables es primordial. A medida que las aplicaciones crecen, también lo hace el volumen de datos que manejan. Servir grandes cantidades de datos en una única respuesta de la API no solo es ineficiente, sino que también puede conducir a malas experiencias de usuario, tiempos de carga lentos y una mayor tensión en el servidor. Aquí es donde entra en juego la paginación, una técnica crítica para dividir grandes conjuntos de datos en fragmentos más pequeños y manejables.

Django REST Framework (DRF) proporciona excelentes opciones de paginación integradas que cubren la mayoría de los casos de uso comunes. Sin embargo, a medida que evolucionan los requisitos de su API, especialmente cuando se atiende a diversas audiencias globales o se integra con marcos de trabajo frontend específicos, a menudo encontrará la necesidad de ir más allá de los valores predeterminados. Esta guía completa profundizará en las capacidades de paginación de DRF, centrándose en cómo crear clases de paginación personalizadas que ofrezcan una flexibilidad y un control sin igual sobre la entrega de datos de su API.

Ya sea que esté construyendo una plataforma global de comercio electrónico, un servicio de análisis de datos o una red social, comprender e implementar estrategias de paginación adaptadas es clave para ofrecer una experiencia de alto rendimiento y fácil de usar en todo el mundo.

La esencia de la paginación de la API

En esencia, la paginación de la API es el proceso de dividir un gran conjunto de resultados de una consulta de base de datos en distintas "páginas" o "fragmentos" de datos. En lugar de devolver cientos o miles de registros de una sola vez, la API devuelve un subconjunto más pequeño, junto con metadatos que ayudan al cliente a navegar por el resto de los datos.

¿Por qué la paginación es indispensable para las APIs modernas?

• Optimización del rendimiento: Enviar menos datos a través de la red reduce el uso del ancho de banda y mejora los tiempos de respuesta, lo cual es crucial para los usuarios en regiones con conexiones a Internet más lentas.
• Experiencia de usuario mejorada: Los usuarios no quieren esperar a que se cargue un conjunto de datos completo. La paginación de datos permite tiempos de carga iniciales más rápidos y una experiencia de navegación más fluida, especialmente en dispositivos móviles.
• Carga reducida del servidor: Obtener y serializar grandes conjuntos de consultas puede consumir importantes recursos del servidor (CPU, memoria). La paginación limita esta tensión, haciendo que su API sea más robusta y escalable.
• Manejo eficiente de datos: Para los clientes, procesar fragmentos de datos más pequeños es más fácil y requiere menos memoria, lo que conduce a aplicaciones más receptivas.
• Escalabilidad global: A medida que su base de usuarios se expande por todo el mundo, la cantidad de datos crece exponencialmente. Una paginación eficaz garantiza que su API siga funcionando independientemente del volumen de datos.

Opciones de paginación integradas de DRF: una descripción general rápida

Django REST Framework ofrece tres estilos de paginación principales de forma predeterminada, cada uno adecuado para diferentes escenarios:

1. PageNumberPagination

Este es posiblemente el estilo de paginación más común e intuitivo. Los clientes solicitan un número de página específico y, opcionalmente, un tamaño de página. DRF devuelve los resultados de esa página, junto con enlaces a las páginas siguientes y anteriores, y un recuento del total de elementos.

Solicitud de ejemplo: /items/?page=2&page_size=10

Casos de uso: Ideal para aplicaciones web tradicionales con navegación explícita por páginas (por ejemplo, "Página 1 de 10").

Consideraciones globales: Tenga en cuenta que algunos sistemas pueden preferir páginas indexadas a 0. DRF utiliza de forma predeterminada la indexación a 1, que es común a nivel mundial, pero es posible que se necesite personalización.

Configuración básica (settings.py):

            REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
    'PAGE_SIZE': 10
}
            

              
                Copy
              
            
          

2. LimitOffsetPagination

Este estilo permite a los clientes especificar un offset (cuántos elementos omitir) y un limit (cuántos elementos devolver). Es más flexible para escenarios como el desplazamiento infinito o cuando los clientes necesitan más control sobre la recuperación de datos.

Solicitud de ejemplo: /items/?limit=10&offset=20

Casos de uso: Ideal para clientes que implementan desplazamiento infinito, lógica de paginación personalizada o segmentación al estilo de base de datos.

Consideraciones globales: Muy flexible para los clientes que prefieren administrar sus propias "páginas" basándose en un desplazamiento, lo que puede ser beneficioso para la integración con diversas bibliotecas frontend o clientes móviles.

Configuración básica (settings.py):

            REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.LimitOffsetPagination',
    'PAGE_SIZE': 10  # default limit if not provided
}
            

              
                Copy
              
            
          

3. CursorPagination

La paginación con cursor ofrece una solución más robusta para conjuntos de datos extremadamente grandes o cuando el ordenamiento consistente es crítico. En lugar de utilizar números de página o desplazamientos, utiliza un "cursor" opaco (a menudo una marca de tiempo codificada o un identificador único) para determinar el siguiente conjunto de resultados. Este método es altamente resistente a los duplicados o elementos omitidos causados por inserciones/eliminaciones de datos durante la paginación.

Solicitud de ejemplo: /items/?cursor=cD0xMjM0NTY3ODkwMTIyMzM0NQ%3D%3D

Casos de uso: Ideal para escenarios de "desplazamiento infinito" donde el conjunto de datos está en constante cambio (por ejemplo, un feed de redes sociales), o cuando se trata de millones de registros donde el rendimiento y la consistencia son primordiales.

Consideraciones globales: Proporciona una consistencia superior para los datos que se actualizan constantemente, asegurando que todos los usuarios globales vean un flujo de información ordenado y confiable, independientemente de cuándo inicien su solicitud.

Configuración básica (settings.py):

            REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.CursorPagination',
    'PAGE_SIZE': 10,
    'CURSOR_ORDERING': '-created_at' # Field to order by
}
            

              
                Copy
              
            
          

¿Por qué ir a lo personalizado? El poder de la paginación adaptada

Si bien las opciones integradas de DRF son poderosas, existen muchos escenarios en los que es posible que no se alineen perfectamente con sus necesidades arquitectónicas específicas, los requisitos del cliente o la lógica de negocios. Aquí es donde la creación de una clase de paginación personalizada se vuelve invaluable.

Cuando lo incorporado no es suficiente:

• Requisitos únicos de Frontend: Su frontend podría exigir nombres de parámetros específicos (por ejemplo, start y limit en lugar de page y page_size) o una estructura de respuesta personalizada que incluya metadatos adicionales (como el rango de elementos mostrados o estadísticas resumidas complejas).
• Integración con sistemas externos o heredados: Al integrarse con APIs de terceros o servicios más antiguos, es posible que deba imitar sus parámetros de paginación o formatos de respuesta con precisión.
• Lógica de negocios compleja: Tal vez el tamaño de la página debería cambiar dinámicamente en función de los roles de usuario, los niveles de suscripción o el tipo de datos que se consultan.
• Necesidades de metadatos mejoradas: Más allá de count, next y previous, es posible que deba incluir current_page, total_pages, items_on_page u otras estadísticas personalizadas relevantes para su base de usuarios global.
• Optimización del rendimiento para consultas específicas: Para patrones de acceso a datos altamente especializados, se puede optimizar una clase de paginación personalizada para interactuar con la base de datos de manera más eficiente.
• Consistencia y accesibilidad global: Garantizar que la respuesta de la API sea consistente y fácilmente analizable por diversos clientes en diferentes regiones geográficas, potencialmente ofreciendo diferentes parámetros específicos del idioma (aunque normalmente no se recomienda para los propios endpoints de la API, sino para la representación del lado del cliente).
• "Cargar más" / Desplazamiento infinito con lógica personalizada: Si bien se puede usar LimitOffsetPagination, una clase personalizada proporciona un control preciso sobre cómo se comporta la funcionalidad "cargar más", incluidos los ajustes dinámicos basados en el comportamiento del usuario o las condiciones de la red.

Creando tu primera clase de paginación personalizada

Todas las clases de paginación personalizadas en DRF deben heredar de rest_framework.pagination.BasePagination o una de sus implementaciones concretas existentes como PageNumberPagination o LimitOffsetPagination. Heredar de una clase existente suele ser más fácil, ya que proporciona gran parte de la lógica repetitiva.

Comprensión de los componentes básicos de la paginación

Al extender BasePagination, normalmente anulará dos métodos principales:

• paginate_queryset(self, queryset, request, view=None): Este método toma el queryset completo, la solicitud actual y la vista. Su responsabilidad es segmentar el queryset y devolver los objetos para la "página" actual. También debe almacenar el objeto de página paginado (por ejemplo, en self.page) para su uso posterior.
• get_paginated_response(self, data): Este método toma los datos serializados para la página actual y debe devolver un objeto Response que contenga tanto los datos paginados como cualquier metadato de paginación adicional (como enlaces siguiente/anterior, recuento total, etc.).

Para modificaciones más simples, heredar de PageNumberPagination o LimitOffsetPagination y anular solo algunos atributos o métodos auxiliares suele ser suficiente.

Ejemplo 1: CustomPageNumberPagination con metadatos mejorados

Digamos que sus clientes globales necesitan información más detallada en la respuesta de paginación, como el número de página actual, el número total de páginas y el rango de elementos que se muestran en la página actual, además de los valores predeterminados de DRF count, next y previous. Extenderemos PageNumberPagination.

Cree un archivo llamado pagination.py en el directorio de su aplicación o proyecto:

            # myapp/pagination.py

from rest_framework.pagination import PageNumberPagination
from rest_framework.response import Response

class CustomPaginationWithMetadata(PageNumberPagination):
    page_size = 10
    page_size_query_param = 'page_size'
    max_page_size = 100

    def get_paginated_response(self, data):
        return Response({
            'links': {
                'next': self.get_next_link(),
                'previous': self.get_previous_link()
            },
            'pagination_info': {
                'total_items': self.page.paginator.count,
                'total_pages': self.page.paginator.num_pages,
                'current_page': self.page.number,
                'items_per_page': self.get_page_size(self.request),
                'current_page_items_count': len(data),
                'start_item_index': self.page.start_index(), # 1-based index
                'end_item_index': self.page.end_index() # 1-based index
            },
            'data': data
        })
            

              
                Copy
              
            
          

Explicación:

• Heredamos de PageNumberPagination para aprovechar su lógica central para manejar los parámetros page y page_size.
• Anulamos get_paginated_response para personalizar la estructura de respuesta JSON.
• Hemos añadido un diccionario 'pagination_info' que contiene:
• total_items: Recuento total de todos los elementos (en todas las páginas).
• total_pages: Número total de páginas disponibles.
• current_page: El número de página de la respuesta actual.
• items_per_page: El número máximo de elementos por página.
• current_page_items_count: El número real de elementos devueltos en la página actual.
• start_item_index y end_item_index: El rango de índice basado en 1 de los elementos en la página actual, que puede ser muy útil para las interfaces de usuario que muestran "Elementos X-Y de Z".
• Los datos reales están anidados bajo una clave 'data' para mayor claridad.

Aplicación de la paginación personalizada a una vista:

            # myapp/views.py

from rest_framework import generics
from .models import Product
from .serializers import ProductSerializer
from .pagination import CustomPaginationWithMetadata

class ProductListView(generics.ListAPIView):
    queryset = Product.objects.all().order_by('id')
    serializer_class = ProductSerializer
    pagination_class = CustomPaginationWithMetadata # Apply your custom class
            

              
                Copy
              
            
          

Ahora, cuando acceda a /products/?page=1&page_size=5, obtendrá una respuesta como esta:

            {
    "links": {
        "next": "http://api.example.com/products/?page=2&page_size=5",
        "previous": null
    },
    "pagination_info": {
        "total_items": 25,
        "total_pages": 5,
        "current_page": 1,
        "items_per_page": 5,
        "current_page_items_count": 5,
        "start_item_index": 1,
        "end_item_index": 5
    },
    "data": [
        { "id": 1, "name": "Global Gadget A", "price": "29.99" },
        { "id": 2, "name": "Regional Widget B", "price": "15.50" }
    ]
}
            

              
                Copy
              
            
          

Estos metadatos mejorados son increíblemente útiles para los desarrolladores de frontend que construyen interfaces de usuario complejas, proporcionando una estructura de datos consistente y rica independientemente de su ubicación geográfica o marco de trabajo preferido.

Ejemplo 2: FlexiblePageSizePagination con límites predeterminados y máximos

A menudo, desea permitir que los clientes especifiquen su tamaño de página preferido, pero también hacer cumplir un límite máximo para evitar el abuso y administrar la carga del servidor. Este es un requisito común para las APIs globales de cara al público. Creemos una clase personalizada que se base en PageNumberPagination.

            # myapp/pagination.py

from rest_framework.pagination import PageNumberPagination

class FlexiblePageSizePagination(PageNumberPagination):
    page_size = 20  # Default page size if not specified by client
    page_size_query_param = 'limit' # Client uses 'limit' instead of 'page_size'
    max_page_size = 50 # Maximum page size allowed

    # Optionally, you can also customize the page query parameter name:
    page_query_param = 'page_number' # Client uses 'page_number' instead of 'page'
            

              
                Copy
              
            
          

Explicación:

• page_size: Establece el número predeterminado de elementos por página si el cliente no proporciona el parámetro limit.
• page_size_query_param = 'limit': Cambia el parámetro de consulta que los clientes usan para solicitar un tamaño de página específico de page_size a limit.
• max_page_size = 50: Asegura que, incluso si un cliente solicita limit=5000, la API solo devolverá un máximo de 50 elementos por página, evitando el agotamiento de recursos.
• page_query_param = 'page_number': Cambia el parámetro de consulta para el número de página de page a page_number.

Aplicando esto:

            # myapp/views.py

from rest_framework import generics
from .models import Item
from .serializers import ItemSerializer
from .pagination import FlexiblePageSizePagination

class ItemListView(generics.ListAPIView):
    queryset = Item.objects.all().order_by('name')
    serializer_class = ItemSerializer
    pagination_class = FlexiblePageSizePagination
            

              
                Copy
              
            
          

Ahora, los clientes pueden solicitar /items/?page_number=3&limit=30. Si solicitan limit=100, la API lo limitará silenciosamente a 50, proporcionando un control robusto sobre el uso de la API.

Escenarios de personalización avanzados

1. Personalización completa de los parámetros de consulta

¿Qué sucede si necesita parámetros de consulta completamente diferentes, como start_index y item_count, imitando algunos diseños de API más antiguos o integraciones de socios específicos? Deberá anular los métodos que analizan estos parámetros.

            # myapp/pagination.py

from rest_framework.pagination import PageNumberPagination
from rest_framework.response import Response

class StartIndexItemCountPagination(PageNumberPagination):
    # Override the default page_size for this custom scheme
    page_size = 10
    page_size_query_param = 'item_count'
    max_page_size = 100
    
    start_index_query_param = 'start_index'

    def get_page_number(self, request):
        try:
            # The start_index is 1-based, we need to convert it to a 0-based offset
            # then calculate the page number based on page_size
            start_index = int(request.query_params.get(self.start_index_query_param, 1))
            page_size = self.get_page_size(request)
            if page_size == 0: # Avoid division by zero
                return 1
            # Convert 1-based start_index to 0-based offset, then to page number
            # e.g., start_index=1, page_size=10 -> page 1
            # e.g., start_index=11, page_size=10 -> page 2
            return (start_index - 1) // page_size + 1
        except (TypeError, ValueError):
            return 1 # Default to page 1 if invalid

    def get_paginated_response(self, data):
        # You can still use the enhanced metadata here from Example 1 if desired
        return Response({
            'meta': {
                'total_records': self.page.paginator.count,
                'start': self.page.start_index(),
                'count': len(data),
                'next_start_index': self.get_next_start_index() # Custom next link logic
            },
            'data': data
        }) 

    def get_next_start_index(self):
        if not self.page.has_next():
            return None
        page_size = self.get_page_size(self.request)
        # Next page's start index is current end index + 1
        return self.page.end_index() + 1

    def get_next_link(self):
        # We need to rebuild the next link using our custom parameters
        if not self.page.has_next():
            return None

        url = self.request.build_absolute_uri()
        page_size = self.get_page_size(self.request)
        next_start_index = self.page.end_index() + 1

        # Use parse_qsl and urlencode for robust query param handling
        from urllib.parse import urlparse, urlunparse, parse_qsl, urlencode
        
        scheme, netloc, path, params, query, fragment = urlparse(url);
        query_params = dict(parse_qsl(query))

        query_params[self.start_index_query_param] = next_start_index
        query_params[self.page_size_query_param] = page_size

        return urlunparse((scheme, netloc, path, params, urlencode(query_params), fragment))

    # You might also need to override get_previous_link similarly
    def get_previous_link(self):
        if not self.page.has_previous():
            return None

        url = self.request.build_absolute_uri()
        page_size = self.get_page_size(self.request)
        # Previous page's start index is current start index - page_size
        previous_start_index = self.page.start_index() - page_size
        if previous_start_index < 1:
            previous_start_index = 1

        from urllib.parse import urlparse, urlunparse, parse_qsl, urlencode
        
        scheme, netloc, path, params, query, fragment = urlparse(url);
        query_params = dict(parse_qsl(query))

        query_params[self.start_index_query_param] = previous_start_index
        query_params[self.page_size_query_param] = page_size

        return urlunparse((scheme, netloc, path, params, urlencode(query_params), fragment))


            

              
                Copy
              
            
          

Conclusiones clave:

• Anular get_page_number es crucial para asignar start_index personalizado al concepto de número de página interno de DRF.
• También debe ajustar get_next_link y get_previous_link para asegurarse de que las URLs generadas utilicen sus parámetros de consulta personalizados (start_index e item_count) correctamente.
• Este enfoque permite una integración perfecta con clientes que esperan esquemas de paginación no estándar específicos, lo cual es vital en un sistema interconectado globalmente donde pueden coexistir varios estándares.

2. Implementación de un "Cargar más" puro o Desplazamiento infinito

Para aplicaciones móviles o aplicaciones web de una sola página, a menudo se prefiere un patrón de "desplazamiento infinito" o "cargar más". Esto normalmente significa que la API solo devuelve un enlace next (si hay más datos disponibles) y ningún número de página o recuento total. LimitOffsetPagination es un buen punto de partida, pero podemos simplificar su salida.

            # myapp/pagination.py

from rest_framework.pagination import LimitOffsetPagination
from rest_framework.response import Response

class InfiniteScrollPagination(LimitOffsetPagination):
    default_limit = 25
    max_limit = 100
    limit_query_param = 'count'
    offset_query_param = 'start'

    def get_paginated_response(self, data):
        return Response({
            'next': self.get_next_link(),
            'previous': self.get_previous_link(),
            'results': data
        })
            

              
                Copy
              
            
          

Explicación:

• Simplificamos get_paginated_response para incluir solo next, previous y results.
• También hemos personalizado los parámetros de consulta a count (para límite) y start (para desplazamiento), que son comunes en escenarios de "cargar más".
• Este patrón es altamente efectivo para feeds de contenido global donde los usuarios se desplazan continuamente a través de los datos, proporcionando una experiencia perfecta.

Integración de la paginación personalizada en su proyecto DRF

Una vez que haya definido sus clases de paginación personalizadas, tiene dos formas principales de integrarlas en su proyecto DRF:

1. Paginación predeterminada global

Puede establecer una clase de paginación personalizada como la predeterminada para todas las vistas de API en su proyecto configurando REST_FRAMEWORK en su archivo settings.py:

            # settings.py

REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'myapp.pagination.CustomPaginationWithMetadata',
    'PAGE_SIZE': 15, # Default page size for views using this class globally
    # ... other DRF settings
}
            

              
                Copy
              
            
          

Esto es útil si la mayoría de sus endpoints de API utilizarán la misma lógica de paginación, asegurando un comportamiento consistente en toda su aplicación para todos los clientes globales.

2. Paginación por vista

Para un control más granular, puede aplicar una clase de paginación específica directamente a una vista o conjunto de vistas individual:

            # myapp/views.py

from rest_framework import generics
from .models import Order
from .serializers import OrderSerializer
from .pagination import InfiniteScrollPagination, CustomPaginationWithMetadata

class RecentOrdersView(generics.ListAPIView):
    queryset = Order.objects.all().order_by('-order_date')
    serializer_class = OrderSerializer
    pagination_class = InfiniteScrollPagination # Specific to this view

class ProductCatalogView(generics.ListAPIView):
    queryset = Product.objects.all().order_by('name')
    serializer_class = ProductSerializer
    pagination_class = CustomPaginationWithMetadata # Another specific class
            

              
                Copy
              
            
          

Esta flexibilidad le permite adaptar el comportamiento de paginación precisamente a las necesidades de cada endpoint, atendiendo a diferentes tipos de clientes (por ejemplo, aplicación móvil frente a web de escritorio frente a integración de socios) o diferentes tipos de datos.

Mejores prácticas para la paginación de APIs globales

Al implementar la paginación para APIs consumidas por una audiencia global, considere estas mejores prácticas para garantizar la robustez, el rendimiento y una experiencia de desarrollador consistente:

• La consistencia es clave: Esfuércese por lograr una estructura de respuesta de paginación consistente en toda su API, o al menos dentro de agrupaciones lógicas de endpoints. Esto reduce la fricción para los desarrolladores que se integran con su API, ya sea que estén en Tokio o Toronto.
• Documentación clara: Documente minuciosamente sus parámetros de paginación (por ejemplo, page, limit, cursor, start_index) y el formato de respuesta esperado. Proporcione ejemplos para cada tipo. Esto es crucial para los desarrolladores internacionales que podrían no tener acceso directo a su equipo para obtener aclaraciones. Herramientas como OpenAPI (Swagger) pueden ayudar enormemente aquí.
• Optimización del rendimiento:
• Índices de base de datos: Asegúrese de que los campos utilizados para el ordenamiento (por ejemplo, id, created_at) estén indexados correctamente en su base de datos para acelerar las consultas, especialmente para las cláusulas ORDER BY.
• Optimización de consultas: Supervise sus consultas de base de datos. Evite SELECT * cuando solo se necesiten campos específicos.
• Almacenamiento en caché: Implemente el almacenamiento en caché para datos paginados estáticos o de cambio lento a los que se accede con frecuencia para reducir la carga de la base de datos.
• Seguridad y prevención de abusos:
• Siempre aplique max_page_size (o max_limit) para evitar que los clientes soliciten conjuntos de datos excesivamente grandes, lo que podría conducir a ataques de denegación de servicio (DoS) o al agotamiento de recursos.
• Valide todos los parámetros de entrada para la paginación (por ejemplo, asegúrese de que los números de página sean enteros positivos).
• Consideraciones sobre la experiencia del usuario:
• Proporcione enlaces de navegación claros (next, previous).
• Para las interfaces de usuario, mostrar el recuento total de elementos y el total de páginas (si corresponde) ayuda a los usuarios a comprender el alcance de los datos disponibles.
• Considere el orden de visualización. Para datos globales, a menudo es mejor un ordenamiento consistente basado en created_at o id que una clasificación específica de la configuración regional a menos que se solicite explícitamente.
• Manejo de errores: Devuelva mensajes de error claros y descriptivos (por ejemplo, 400 Solicitud incorrecta) cuando los parámetros de paginación no sean válidos o estén fuera de rango.
• Pruebe a fondo: Pruebe la paginación con varios tamaños de página, al principio y al final de los conjuntos de datos y con conjuntos de datos vacíos. Esto es especialmente importante para las implementaciones personalizadas.

Conclusión

El sistema de paginación de Django REST Framework es robusto y altamente extensible. Si bien las clases integradas PageNumberPagination, LimitOffsetPagination y CursorPagination cubren una amplia gama de casos de uso, la capacidad de crear clases de paginación personalizadas le permite adaptar perfectamente la entrega de datos de su API a requisitos específicos.

Al comprender cómo anular los comportamientos predeterminados, agregar metadatos enriquecidos o cambiar completamente el esquema de parámetros, puede crear APIs que no solo sean eficientes y de alto rendimiento, sino también increíblemente flexibles y fáciles de usar para un público global. Adopte la paginación personalizada para desbloquear todo el potencial de sus aplicaciones Django REST Framework y brindar una experiencia superior a los usuarios e integradores de todo el mundo.

¿Qué desafíos de paginación personalizada ha encontrado? ¡Comparta sus ideas y soluciones en los comentarios a continuación!