• No se han encontrado resultados

Desarrollo de un sitio web de compra de juguetes de Afiliados de Amazon

N/A
N/A
Protected

Academic year: 2023

Share "Desarrollo de un sitio web de compra de juguetes de Afiliados de Amazon"

Copied!
95
0
0

Texto completo

(1)

Desarrollo de un

sitio web de compra de juguetes de

Afiliados de Amazon

( gegantoys.com )

(2)

Estudiante

Óscar del Águila Giménez

Máster en Desarrollo de Sitios y Aplicaciones Web.

Área de Informática,

Multimedia y comunicación

Tutor/a de TF

Carles Arnal Castello

Profesor/a responsable

César Pablo Córcoles Briongos

Fecha Entrega

01/2023

(3)

Copyright © 2022 Oscar del Águila Giménez.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

A copy of the license is included in the section entitled "GNU Free Documentation License".

(4)

Agradecimientos:

Quiero agradecer a la gente de mi entorno: amigos, familia y en especial a mi mujer Erika, que tanto ha sufrido para darme el tiempo necesario para poder estudiar, y a mis dos hijas por el mismo motivo, el apoyo que me han prestado tanto emocional como económico.

Muchas gracias.

(5)

FICHA DEL TRABAJO FINAL

Título del trabajo:

Desarrollo de un sitio web de juguetes con el programa de marketing de Afiliados de Amazon.

Nombre del autor: Oscar del Águila Giménez Nombre del consultor/a: Carles Arnal Castello

Nombre del PRA: César Pablo Córcoles Briongos Fecha de entrega: 01/2023

Titulación o programa: Máster Universitario en Desarrollo de Sitios y Aplicaciones Web.

Área del Trabajo Final: Área de Informática, Multimedia y comunicación.

Idioma del trabajo: Castellano

Palabras clave Web, Afiliados, Amazon Resumen

El presente Trabajo Final de Máster es de tipo profesionalizador y consiste en documentar el desarrollo e implementación de un sitio web de juguetes que opera con el programa de marketing de Afiliados de Amazon.

La finalidad de este trabajo es realizar un estudio para averiguar si es viable obtener ingresos y en qué cuantía, de forma ‘pasiva’, mediante esta nueva metodología de negocio del programa de afiliados. Está orientado, sobre todo, a emprendedores que no dispongan de medios para crear su propio negocio deseando ayudarles a decidir si emprender este camino o no.

Para ello vamos a emplear técnicas de marketing generando tráfico para obtener una buena posición SEO en lo que respecta al sitio web y analizaremos los datos y estadísticas resultado obtenidos a partir de las acciones del usuario final gracias a la plataforma de Amazon, que nos brinda.

Abstract

(6)

This Master's Final Project is of a professional nature and consists of documenting the development and implementation of a toy website that operates with the Amazon Affiliate marketing program.

The purpose of this work is to carry out a study to find out if it is feasible to obtain income and in what amount, in a 'passive' way, through this new business methodology of the affiliate program. It is aimed, above all, at entrepreneurs who do not have the means to create their own business, wishing to help them decide whether to take this path or not.

For this we are going to use marketing techniques generating traffic to obtain a good SEO position in regards to the website and we will analyze the data and statistics obtained from the actions of the end user thanks to the Amazon platform, which it provides us.

(7)

Índice

Lista de figuras ... 4

1. Introducción ... 5

1.1. Contexto y justificación del Trabajo ... 5

1.2. Objetivos del Trabajo ... 6

1.3. Impacto en sostenibilidad, ético-social y de diversidad ... 7

1.4. Enfoque y método seguido ... 8

1.5. Planificación del Trabajo ... 9

1.6. Breve sumario de productos obtenidos ... 12

1.7. Breve descripción de los otros capítulos de la memoria ... 12

2. Materiales y métodos ... 13

2.1 Metodología para el desarrollo del TFM. ... 13

2.2 Análisis de requerimientos. ... 15

2.2.1 Descripción general. ... 15

2.2.2 Descripción detallada de requerimientos funcionales... 16

2.2.3 Descripción detallada de requerimientos Web. ... 18

2.3 Diseño de la interfaz. ... 19

2.3.1 Sitemap ... 19

2.3.2 Casos de uso para un usuario no autentificado. ... 21

2.3.3 Casos de uso para un usuario autentificado ... 21

2.3.4 Casos de uso para el usuario administrador ... 22

2.3.5 Diagramas de flujo. ... 23

2.3.5.1 Diagrama de flujo para autentificación de usuario. ... 23

2.3.5.2 Diagrama de flujo para el caso de uso de compra de un juguete. ... 25

2.3.6 Estudio de la usabilidad ... 26

2.3.7 Prototipos de la interfaz de usuario (mobile). ... 28

2.3.7.1 Diseño del menú y página inicio mobile. ... 28

2.3.7.2 Diseño catálogo juguetes, inicio, favoritos (mobile). ... 29

2.3.7.3 Diseño Acerca nosotros, Detalle juguete, registro mobile ... 30

2.3.8 Prototipos para la interfaz de usuario (escritorio). ... 31

2.3.8.1 Diseño Inicio de sesión (escritorio): ... 31

2.3.8.2 Diseño inicio, catálogo de juguetes. ... 32

2.3.8.3 Diseño Administración experiencias para el Administrador ... 33

2.3.9 Estilos CSS utilizados en el diseño. ... 34

2.4 Arquitectura ... 35

2.4.1 Frontend y backend independientes. ... 35

2.4.2 Arquitectura de la parte frontend (MVC). ... 36

2.4.3 Servicios de nuestra App. ... 37

(8)

2.4.4 ¿Por qué Angular? ... 38

2.4.5 Arquitectura de la parte backend. ... 39

2.4.6 Controladores del backend. ... 40

2.4.7 ¿Por qué Laravel? ... 40

2.4.8 Base de datos ... 41

2.5 Análisis de mercado ... 43

2.5.1 Definición del mercado objetivo. ... 43

2.5.2 ¿El mercado objetivo es grande y perdurable en el tiempo? ... 43

2.5.3. Competidores existentes. ... 43

2.5.4. Cuál es nuestro público objetivo más relevante en términos de venta? ... 44

2.5.5. Análisis de potencial: ¿Cómo podría desarrollarse el mercado objetivo en el futuro? ... 45

2.6 Viabilidad ... 46

2.6.1 Recursos técnicos y económicos. ... 46

2.6.2 Comisiones que genera el producto. ... 47

2.6.3 Rentabilidad ... 48

2.7 SEO y Angular ... 49

2.8 Desarrollo e instalación del proyecto. ... 50

2.8.1 Desarrollo en local para la parte backend. ... 50

2.8.2 Funcionalidades destacables en el backend. ... 53

2.8.3 Desarrollo en local para la parte frontend ... 57

2.8.4 Aspectos destacados en el frontend ... 59

2.8.5 Problemas y soluciones durante el desarrollo Backend. ... 61

2.8.6 Problemas y soluciones durante el desarrollo Frontend. ... 63

2.8.7 Instalación de la App en producción (en servidor remoto)... 67

2.8.8 Carga de productos en el catálogo de la web desde cero. ... 68

2.8.9 Mejoras en el diseño de la interfaz de usuario frontend ... 69

2.8.9.1 Cambio en el diseñó del formulario Juguetes : ... 69

2.8.9.2 Diseño actual del formulario juguete. ... 69

2.8.9.3 Cambio en el diseño de formulario experiencias. ... 70

2.9 Repositorios en GitHub y URL App de producción. ... 71

2.10 Productos obtenidos. ... 72

3. Resultados ... 73

3.1 Resultados página de inicio. ... 73

3.2 Resultados página de catálogo de juguetes. ... 75

3.3 Resultados página garantías. ... 77

3.11 Resumen de los resultados del producto. ... 79

4. Conclusiones y trabajos futuros ... 80

4.1 Conclusiones a partir de los resultados obtenidos. ... 80

(9)

4.3 Análisis crítico del seguimiento de la planificación y metodología a lo largo del producto. ... 82 4.4 Impactos previstos (ético-sociales, de sostenibilidad y de diversidad):

logrados y/o mitigados. ... 83 4.5 ¿Cómo se han solucionado los impactos (ético-sociales, de sostenibilidad y de diversidad) no previstos?... 83 4.6 Líneas de trabajo pendientes. ... 84 5. Bibliografía ... 85

(10)

Lista de figuras

Figura 1: Tabla de planificación de tareas Figura 2: Tabla modelo Waterfall

Figura 3: Sitemap del sitio web

Figura 4: Diagrama de flujo para autentificación de usuario

Figura 5: Diagrama de flujo para el caso de uso de compra de un juguete Figura 6: Diseño del menú mobile

Figura 7: Diseño pantalla inicio mobile

Figura 8: Diseño catálogo de juguetes mobile

Figura 9: Diseño Acerca de nosotros, detalle y registro mobile Figura 10: Diseño inicio de sesión (escritorio)

Figura 11: Diseño inicio, catálogo juguetes (escritorio) Figura 12: Diseño Administración experiencias (escritorio) Figura 13: Arquitectura frontend

Figura 14: Árbol de categorías Figura 15. Arquitectura backend

Figura 16: Modelo de la base de datos

Figura 17: Fichero Excel de importación a la base de datos Figura 18: Diseño actual del formulario juguete

Figura 19: Cambio en el diseño de formulario experiencias Figura 20: Resultados página inicio escritorio.

Figura 21: Resultados página inicio móvil.

Figura 22: Resultados página catálogo juguetes escritorio Figura 23: Resultados página catálogo juguetes móvil Figura 24: Resultados página garantías escritorio Figura 25: Resultados página garantías móvil

(11)

1. Introducción

1.1. Contexto y justificación del Trabajo

En ocasiones no podemos emprender un negocio online por falta de recursos y/o medios o simplemente por ignorancia de cómo proceder para poder llevarlo a cabo. Muchos profesionales de las tecnologías de internet y multimedia disponen de conocimientos técnicos, como es en mi caso, pero no pueden aprovecharlos; y con este TF de máster deseo aportar un estudio sobre nuevas oportunidades de negocio como el programa de afiliados de Amazon

(parecido al dropshipping) para ver hasta qué punto es viable generar ingresos mediante esta estrategia de negocio.

Iniciarse en un programa de afiliados puede ser una oportunidad para blogueros o webmasters que quieran mediante una temática concreta

promocionar productos que están en venta en un mayorista como Amazon y así ganar una pequeña comisión por la venta de ellos a través de su web.

Puede ser una oportunidad real de ingresos debido a:

 No se necesita inventario de productos ni enviarlos porque se encarga el mayorista.

 Modelo de negocio de bajo riesgo.

 Tienen potenciales altos de ingresos.

 No se necesita una gran inversión.

Algunas herramientas para poder llevar a cabo una web con potencial de ventas pueden ser: Google Keyword Planner, estrategias de marketing como email marketing y SEO. Planteando estas herramientas más un buen diseño y buen rendimiento web solo nos quedaría estudiar los resultados de ventas obtenidos mediante la plataforma de Amazon para que el propio lector saque sus propias conclusiones.

Buscamos una forma de ingresos fácil con los conocimientos informáticos y multimedia de los que dispone normalmente un profesional del sector. Utilizar el programa de afiliados es una manera; además del marketing de afiliados, tenemos otra forma muy parecida llamada dropshipping. En las dos formas online el mayorista o fabricante es responsable del inventario de productos, sin embargo existen diferencias:

 Con dropshipping hacemos una reventa y con marketing de afiliados una promoción para que con cada venta ganemos una comisión.

(12)

 El precio del producto no lo podemos cambiar en el programa de afiliados, con dropshipping sí.

 En Atención al Cliente para devoluciones es responsable el mayorista en el caso de marketing de afiliados y con dropshipping el responsable es el propietario de la tienda.

Nuestro trabajo va a consistir en emprender un negocio con marketing de afiliados porque requiere de menor responsabilidad que con

dropshipping, solamente preocupándonos de promocionar productos y nada más.

Hay posibilidades de que nuestro negocio escale y se convierta en una tienda mixta de programa de afiliados junto con dropshipping para obtener mayores ingresos, pero como iniciadores solamente vamos a estudiar la solución de afiliados.

1.2. Objetivos del Trabajo

 Desarrollar un estudio sobre la viabilidad de generación de ingresos económicos mediante el programa de afiliados de Amazon.

 Determinar qué perfil de desarrolladores más o menos

experimentados de tecnologías web pueden desarrollar este tipo de oportunidad o trabajo con éxito.

 Determinar un coste en recursos tanto en tiempo como económicos para llevar a cabo este tipo de negocio.

 Desarrollar un estudio para ayudar a decidir al futuro emprendedor, mediante datos concretos, hasta qué punto es factible o no el éxito de emprender un negocio de este tipo.

 El objetivo no es crear un referencia única ni exclusiva para tener éxito sino más bien crear una referencia que sirva de ejemplo de caso particular.

 Conseguir un reto personal: desarrollar un sitio web e-commerce personalizado con Angular y Laravel y sin usar un CMS para su implementación de manera que solamente falte el carrito de compra para acabar de ser un e-commerce completo.

(13)

1.3. Impacto en sostenibilidad, ético-social y de diversidad

El Trabajo Final de Máster pretende motivar a personas emprendedoras que deseen formar un negocio para tener una vía de ingresos extra de forma “fácil”

aprovechando el programa de Afiliados.

Pretendemos romper a muy pequeña escala la economía presente actualmente en el planeta de propietarios de negocios grandes en beneficio de gente más pobre pero con conocimientos técnicos.

No sabemos si el programa de marketing es sostenible como sustento de forma de vida porque no sabemos qué beneficios económicos conlleva en general.

Me parece injusto éticamente que profesionales de la tecnologías multimedia y de internet que han dedicado gran tiempo de su vida a estudiar no puedan crear negocios propios por el simple hecho de no tener medios económicos y/o proveedores de productos que vender, por poner una situación. Poner en conocimiento esta metodología de negocio y conocer más sus posibilidades de éxito me parece muy interesante para el futuro emprendedor. Así que me encuentro motivado para llevar a cabo el TF de máster para comprobar si el programa de Afiliados es realista como una oportunidad de ingresos.

El TF no tiene un impacto social determinante de carácter negativo ni positivo en cualquier ámbito. Está destinado para gente madura capaz de afrontar un fracaso si fuera el caso después de haber invertido mucho tiempo para llevarlo a cabo. No está pensado mayoritariamente para personas que no poseen conocimientos informáticos, que se dediquen a aprender el diseño web simplemente para llevar a cabo este tipo de negocio porque ya debemos saber que nadie da duros a cuatro pesetas y no hay caminos fáciles, así que lo único que pido es cautela a la hora de invertir el tiempo que se nos da para tomar decisiones que puedan ser relevantes en nuestra vida.

La existencia de muchos negocios online de este tipo no supone la pérdida de las tiendas de barrio del pequeño comerciante, ya que éste puede promover sus productos en Amazon y realizar lo mismo contratando a un programador:

crear su propia web para promocionarlos mejor que Amazon. Este tipo de negocio no es más que un “refuerzo“ o una técnica de marketing para promocionar productos haciéndoles mayor propaganda que la que se encuentra en el mayorista por defecto. Para vender más hay que estar bien informado de lo que acontece a nuestro alrededor y conocer las técnicas de venta actuales, porque el programa de afiliados no deja de ser una nueva técnica para una mayor venta.

(14)

1.4. Enfoque y método seguido

Para el desarrollo web de Afiliados de Amazon no vamos a utilizar la

herramienta ‘rey’ que es el CMS WordPress, sino que desarrollaremos una web personalizada desde cero para marcar diferencia con los sitios de afiliados ya existentes realizados en WordPress y ver qué resultados obtenemos. Como el número de ventas es importante para conseguir nuestros objetivos, para favorecerla, seleccionaremos juguetes de Amazon que reúnan ciertos criterios.

Una vez nuestro sitio web esté funcionando con los juguetes escogidos

realizaremos un estudio con los datos que nos proporciona la plataforma de Amazon Afiliados:

1. Resumen de las comisiones generadas los últimos 30 días.

2. Productos enviados.

3. Productos pedidos.

4. Ingresos totales.

5. Número de clics y porcentaje de conversión.

6. Rendimientos por tipo de enlace (banner, enlace de producto).

7. Informes de resumen consolidado.

Con el análisis de los datos de los puntos anteriores más otras variables (conocimientos de mercado, recursos invertidos para el lanzamiento del producto, rendimiento web, tráfico generado mediante SEO, …) deduciremos si es una oportunidad real de negocio.

(15)

1.5. Planificación del Trabajo

A continuación mostramos una tabla con los tiempos asignados a cada tarea del TFM.

Figura 1: Tabla de planificación de tareas.

Adjunto documentos .pdf en la entrega PEC1 con la planificación de tareas representada mediante diagramas de Gantt.

(16)

Recursos y/o herramientas asignadas a las tareas del TF:

TAREA RECURSO

Comprender el Programa de Afiliados de Amazon

https://afiliados.amazon.es/

SiteMap y casos de uso Flowmapp

Diseñó de la interfaz Justinmind

Front-end Angular (framework)

Back-end Laravel (framework)

Estilos CSS Tailwind, Angular Material, Bootstrap

Modelo relacional Xampp

Hosting + dominio https://gegantoys.com

(17)

Hitos parciales de cada PEC en orden de preferencia de desarrollo:

HITOS PEC Asignada

Sitemap y casos de uso PEC1

Diseño de la interfaz. Prototipos con todos sus elementos funcionales.

PEC1

Conocimientos SEO para Angular. PEC1

Modelo relacional de base de datos PEC1

Implementación en Angular del frontend PEC2

Implementación de la API Rest backend PEC2

Añadir estilos CSS PEC2

Registro en el programa de Afiliados de Amazon

PEC2

Introducción de juguetes a nuestro sitio web mediante las herramientas de la plataforma de Amazon.

PEC2

Análisis y estudio de los datos, fin memoria y conclusiones.

Entrega final

(18)

1.6. Breve sumario de productos obtenidos

El producto obtenido es la publicación en internet de un sitio web que sirve como catálogo de referencia y blog informativo de juguetes al usuario que desea comprar y que enlaza con la web de Amazon donde finalizar la compra.

El producto obtenido en este TFM no es un ecommerce, sino un sitio web que promueve la venta de marcas de juguetes. El beneficio que obtenemos de cada venta es una comisión.

1.7. Breve descripción de los otros capítulos de la memoria

En los siguientes apartados de esta memoria del TF redactamos toda la parte de desarrollo del producto antes de su lanzamiento al mercado, describiendo todas sus fases: requerimientos previos, diseños, diagramas, descripciones, casos de uso, prototipos, arquitectura utilizada, pruebas realizadas,

mantenimiento o mejoras y su post-lanzamiento, que conlleva el estudio en este documento de la rentabilidad del producto durante su uso en un

determinado tiempo, la escalabilidad de la App, y sus posibles utilidades y vías de desarrollo.

(19)

2. Materiales y métodos

2.1 Metodología para el desarrollo del TFM.

La metodología que hemos seguido para llevar a cabo el proyecto TFM es la establecida por el modelo Waterfall o modelo en cascada, que consta de las siguientes fases:

Figura 2. Tabla modelo Waterfall.

Análisis de Requerimientos

Diseño

Implementación

Pruebas

Mantenimiento

Esta metodología se suele utilizar en proyectos de software y a continuación explicamos en que consiste cada una de las fases aplicada a nuestro producto en particular:

Análisis de requerimientos: en este apartado describimos el producto en sí, los servicios de los que constará el producto, las metas y objetivos que debe cumplir el producto.

Diseño: En esta fase describimos los diferentes casos de uso del producto, el diseño de la interfaz, los prototipos del producto, la arquitectura y el diseño del modelo relacional.

Implementación: En este apartado hacemos funcional todo lo que hayamos descrito en el apartado de diseño mediante la codificación.

(20)

Pruebas: Realizaremos pruebas de unidad (para cada uno de los módulos que forman la aplicación) y pruebas de integración interrelacionando módulos y que impliquen el buen funcionamiento total de la App.

Mantenimiento: Una vez puesta en funcionamiento la App esta fase consiste en encontrar errores o posibles mejoras no descubiertos en las etapas anteriores del modelo Waterfall y corregirlos. También atiende los cambios que se puedan producir a causa de modificaciones en los requerimientos.

Características del modelo:

Esta metodología o proceso de desarrollo implica:

- Documentación exhaustiva para cada fase o etapa pensando en el desarrollo y futuro mantenimiento.

- Es un modelo pensado para planificar las tareas y los tiempos asignados a cada tarea ya que se conocen los requerimientos y los objetivos a alcanzar.

- Las fases del proyecto se realizan consecutivamente, sin la intención de volver a la etapa anterior.

La naturaleza del producto que vamos a desarrollar en este TFM ‘pide’ su desarrollo mediante esta metodología.

(21)

2.2 Análisis de requerimientos.

2.2.1 Descripción general.

Requerimientos funcionales

Sesión

Autentificación de usuarios, reseteo de contraseña, sesión abierta en el navegador mediante token. Actualizar perfil. Verificación de email.

Catálogo Búsqueda de juguetes mediante categorías o bien mediante campo de búsqueda.

Blog La App ha de contener un blog con las experiencias de usuarios de juguetes cuya compra haya sido verificada.

Favoritos Permite crear una lista de favoritos al usuario (elimina y añade favoritos).

Administración

Parte administrativa que permita crear una experiencia a un usuario que realice una compra de un juguete. Más tarde el administrador del sitio revisa la experiencia y la publica en el blog o no.

Administración

El administrador añade, elimina, actualiza juguetes del catálogo. Tiene la opción de publicar el juguete en el catálogo en el momento que desee.

Newsletter El usuario puede recibir emails con información sobre juguetes que puedan ser de su interés.

(22)

Requerimientos NO funcionales

Web Responsive

Afiliados de Amazon

Poseer una cuenta en Afiliados de Amazon.

Alojamiento Hosting Web + dominio del sitio

Web Aplicar SEO

2.2.2 Descripción detallada de requerimientos funcionales.

Barra de estado o notificación de estado

- Asignar un espacio en la pantalla del navegador que notifique el resultado y estado de la operación que se está realizando (login, actualizar perfil, ...).

Validaciones de formulario

- Realizar validaciones para los campos de los formularios en al App mediante validaciones de formularios reactivos de Angular.

- Realizar validación de coincidir contraseñas en contraseña y repite contraseña mediante validación personalizada .

Referente a la paginación

- Realizar paginación mediante un botón de Cargar más ítems.

- Cuando volvemos del detalle de juguete o experiencia debemos situarnos en el ítem exacto del listado para no volver a realizar scroll.

(23)

En la autentificación (login):

- Poner un enlace para acceder a la página de registro de nuevo usuario.

- Una vez el usuario se ha autentificado, las peticiones al backend deben ser seguras mediante token. Impedir también que la página se cargue en caso de no encontrar el token de usuario mediante Guards de Angular.

Imágenes:

- Si no se encuentra la imagen en la página a cargar, debemos poner una imagen o similar por defecto que represente que no se ha encontrado la imagen original; mediante un pipe de Angular.

En el perfil:

En esta página dar la opción de cambio de contraseña.

Blog de experiencias

- Debe mostrar todas las experiencias independientemente del usuario.

Listado de juguetes (administrador) :

- Habilitar un botón de editar y eliminar el ítem en cuestión.

Listado de experiencias (usuario autentificado que no es administrador).

- Debe poder editar y eliminar sus experiencias y también si lo desea de asignar una fotografía a la experiencia (upload de la foto al servidor) mediante un control de tipo File desde formulario.

- Cuando se crea o edita una experiencia se actualiza la fecha en base de datos de forma automática.

Menús de la App

- La App debe disponer de dos menús, uno de uso general y otro

secundario que se activará cuando el usuario se haya autentificado. La

(24)

opción de menú de Admin juguetes solamente aparecerá cuando se haya autentificado el administrador.

Favoritos

- Desde el detalle del juguete el usuario autentificado debe de poder de poner el juguete como favorito en su lista de favoritos.

- En su lista de favoritos debe de poder eliminar favoritos.

- Solamente en el detalle del juguete se indica si el juguete está escogido como favorito por parte del usuario autentificado.

Checkbox publicar

- Cuando nos logamos como administrador en el formulario de juguete y de experiencia debemos habilitar un checkbox que indique si deseamos publicar o no la experiencia o el juguete implicado.

2.2.3 Descripción detallada de requerimientos Web.

1. Dotar a la aplicación Angular con PWA (Progressive Web Application) para simular una aplicación nativa en el dispositivo si descargamos el sitio mediante esta tecnología.

2. Aumentar el rendimiento a nivel de respuesta de cara al usuario, utilizando técnicas de memoria caché.

3. Servir las páginas de la App SPA (single page application) de forma estática para mejorar el rendimiento mediante Angular Universal.

4. Carga de la App de forma lazy (perezosa) para cargar la App por partes y/o bajo demanda del usuario según vaya navegando.

5. Implementar técnicas SEO para posicionamiento web

(25)

2.3 Diseño de la interfaz.

Definición del sitemap y los diferentes casos de uso según el tipo de usuario que navegue (administrador, usuario autentificado, usuario sin autentificar) y la pantalla donde se encuentre.

2.3.1 Sitemap

En la siguiente figura presentamos el sitemap de nuestro sitio web, donde vemos las diferentes pantallas que lo forman.

Figura 3: Sitemap del sitio web

(26)

Enumeración de las pantallas del sitemap:

Inicio.

Registro de nuevo usuario.

Autentificación de usuario.

o CRUD de experiencia (*)

o Lista de favoritos del usuario.

o Datos del perfil del usuario.

Catálogo de juguetes.

o Detalle del juguete.

Blog experiencias.

Garantías, cómo funciona, servicios.

CRUD experiencias (*). Solo ve el administrador.

CRUD juguetes. Solo ve el administrador.

(*) Realmente la pantalla de experiencias de un usuario autentificado y la pantalla de administrador de experiencias son la misma, lo única diferencia es que en el caso de usuario autentificado no se muestra el checkbox de

experiencia publicada y revisada, que más tarde veremos su funcionalidad.

(27)

2.3.2 Casos de uso para un usuario no autentificado.

Los casos de uso para un usuario no autentificado en el sitio web son muy simples, entre ellos el usuario puede:

 Iniciar sesión o registrarse.

 Al registrarse el usuario tiene la opción de marcar si desea recibir emails con juguetes que puedan ser de su interés.

 Solicitud de reseteo de la contraseña en caso de olvido de la misma.

 Búsqueda de juguetes mediante categorías a las que pertenecen los juguetes o bien mediante buscador de texto.

 Navegación por el blog de experiencias de usuarios con compras verificadas.

 Consultar las garantías y funcionamiento del sitio web.

 Contacto mediante cumplimentación de formulario.

 Navegación en general consultando información detallada de juguetes, destacados,…

2.3.3 Casos de uso para un usuario autentificado

Un usuario autentificado, además de los casos de uso anteriores, puede interaccionar con el sitio de las siguientes formas:

 Puede actualizar los datos personales de su perfil.

 Las compras de juguetes que haya realizado el usuario y que hayan sido verificadas por el administrador mediante el panel de Amazon Afiliados en la cuenta pertinente, el usuario puede escribir la experiencia en el sitio web de ese juguete, la cual será revisada por el administrador. También puede editar, eliminar experiencias.

 Al navegar por el catálogo de juguetes del sitio puede agregar juguetes a su lista de favoritos.

 En el apartado de lista de favoritos que tiene el usuario, puede eliminar juguetes de esta lista si lo desea.

 Puede cerrar sesión

(28)

2.3.4 Casos de uso para el usuario administrador

El administrador del sitio además de todos los casos de uso anteriores puede hacer:

 Una vez un usuario autentificado haya creado una experiencia para el blog, el administrador revisará la experiencia manualmente para si procede de ser publicada o no, y si procede entonces el administrador marca la casilla de verificación conforme puede ser publicada. Esta casilla de verificación o checkbox en el panel de administración de experiencias determina si mostrar la experiencia en el blog.

 El administrador controla los juguetes a publicar en el sitio.

Los juguetes se muestran en el catálogo o no según si está marcada o no la casilla de verificación que se representa mediante un campo en la base de datos. Puede editar, eliminar y crear juguetes en la lista del catálogo también en el panel de administración de juguetes.

(29)

2.3.5 Diagramas de flujo.

A continuación presentamos dos diagramas de flujo para dos casos de uso:

2.3.5.1 Diagrama de flujo para autentificación de usuario.

Figura 4:

(30)

Consideraciones:

1. Para el alta de un nuevo usuario, una vez cumplimentado el formulario y guardados los datos en la base de datos, realizaremos la verificación del email introducido mediante el envío de un correo que contendrá un enlace que el nuevo usuario ha de clicar para finalizar correctamente el proceso de alta.

2. Si el usuario no se acuerda de su contraseña tiene la opción de resetear la contraseña antigua y de introducir una nueva. La forma de proceder es la siguiente: Se le envía un email con un enlace que una vez clicado le redirige a la pantalla de edición de datos personales de usuario donde podrá

introducir la nueva contraseña. Para no crearle confusión la pantalla de actualizar perfil solamente mostrará los campos relativos a la nueva contraseña.

3. Aún y que no queda reflejado en el diagrama, si un usuario desea guardar la sesión una vez autentificado; para la siguiente vez que regrese al sitio web la sesión es recordada mediante token de sesión.

(31)

2.3.5.2 Diagrama de flujo para el caso de uso de compra de un juguete.

Figura 5:

(32)

2.3.6 Estudio de la usabilidad

Se entiende por usabilidad web la facilidad de uso que tiene una página web de cara a los usuarios que la visitan e interactúan con ella. Según Jacob Nielsen la usabilidad de un producto o sistema se mide a partir de cinco criterios:

1. Facilidad de aprendizaje: el sistema o producto debe ser fácil de aprender, de manera que el usuario pueda trabajar con él lo más rápido posible.

2. Eficiencia de uso: El nivel de productividad del usuario que ha aprendido a usar el producto debe ser alto para poder completar determinadas tareas.

3. Facilidad de memorización: El sistema debe ser fácil de recordar incluso después de algún periodo sin uso.

4. Errores: Para que un producto sea usable debe generar el menor número de errores posible.

5. Satisfacción: El sistema debe ser agradable de utilizar. Debe proporcionar comodidad y actitud positiva durante su uso.

Para la toma de decisiones en el diseño en la interfaz de nuestro sitio web y mejorar la experiencia de usuario hemos tomado en cuenta los criterios de Jacob Nielsen:

1. Sitio web accesible a todas las personas y responsive.

2. No realizamos carga cognitiva con muchos textos o imágenes que confundan y agobien al usuario en la navegación.

3. Web interactiva.

4. Legibilidad fácil mediante la alineación del texto a la izquierda (principios de alineación).

5. Utilización de iconos que preservan principios de coherencia entre forma y funcionalidad (e.g la lupa para buscar juguetes). Además hemos utilizado iconos para facilitar la comprensión de los contenidos y su acceso

optimizando por otro lado los tiempos de respuesta del usuario mejorando la experiencia.

6. La gestión de errores para un formulario mal cumplimentado no lleva a la

(33)

7. Pretendemos realizar un sitio sin errores de ejecución.

8. Uso coherente de los colores. Por ejemplo todos los botones de la aplicación que contienen la acción ‘eliminar’ poseen el mismo color rojo.

9. Varias maneras de acceder a contenidos: por ejemplo para buscar juguetes: mediante las categorías o bien con el campo de búsqueda tradicional.

(34)

2.3.7 Prototipos de la interfaz de usuario (mobile).

2.3.7.1 Diseño del menú y página inicio mobile.

Figura 6 y 7:

(35)

2.3.7.2 Diseño catálogo juguetes, inicio, favoritos (mobile).

Figura 8:

Catálogo de juguetes Inicio Favoritos

(36)

2.3.7.3 Diseño Acerca nosotros, Detalle juguete, registro mobile

Figura 9

Acerca de nosotros Detalle juguete Registro usuario

(37)

2.3.8 Prototipos para la interfaz de usuario (escritorio).

2.3.8.1 Diseño Inicio de sesión (escritorio):

Figura 10:

(38)

2.3.8.2 Diseño inicio, catálogo de juguetes.

Figura 11:

(39)

2.3.8.3 Diseño Administración experiencias para el Administrador

Figura 12:

(40)

2.3.9 Estilos CSS utilizados en el diseño.

Para aplicar los estilos a la web lo haremos mediante una combinación de la librería de utilidades Tailwind, el paquete de Bootstrap (es un paquete de componentes y utilidades CSS), Angular Material (paquete de componentes) y reglas de estilo CSS del propio lenguaje. Realizamos esta combinación aprovechando las ventajas de cada uno:

- Tailwind es una librería de utilidades CSS muy potente que permite,

mediante sus utilidades y modificadores, crear un sitio web responsive de manera muy fácil sin necesidad de implementar puntos de interrupción de estilos por el desarrollador; independientemente de la pantalla de dispositivo en la que nos encontremos.

-

Bootstrap: Contiene componentes que podemos usar y personalizar disminuyendo nuestro trabajo.

- Angular Material: para aprovechar los componentes elegantes y muy trabajados de los que dispone.

(41)

2.4 Arquitectura

2.4.1 Frontend y backend independientes.

La App que forma nuestro sitio web está formada por dos partes: frontend y backend totalmente independientes una de la otra porque hemos realizado una API Rest de backend que puede ser consumida por cualquier implementación frontend compatible.

Las aplicaciones para backend y frontend pueden ubicarse en máquinas físicas diferentes sin que el frontend tenga problemas para consumir la API Rest del backend más que los originados por los intercambios de recursos de origen cruzados (CORS). CORS es un mecanismo basado en el encabezado HTTP (incluimos reglas en los encabezados) que permite que un servidor indique cualquier origen (dominio, esquema o puerto) que no sea el suyo propio desde el cual un navegador debería permitir la carga de recursos. En la práctica, en nuestra App por ejemplo, en las aplicaciones de frontend y de backend para Angular y Laravel respectivamente indicamos en las cabeceras http las reglas necesarias para permitir la carga de recursos de origen distinto al sitio donde se encuentra la App que ejecuta la petición.

Ventajas de separar el frontend y backend:

1. La ampliación a otras plataformas de la misma aplicación es más fácil. Por ejemplo para realizar una App móvil solamente nos enfocamos en la parte frontend aprovechando la parte backend ya funcionando que proporciona la API a consumir.

2. Ambas partes son más fáciles de escalar cuando necesitan más recursos porque se destinan únicamente a la parte que lo necesita.

3. Independencia del lenguaje de programación usado para el frontend y backend.

4. Al separar las dos partes se crean varios perfiles de desarrollador. Por ejemplo para el mantenimiento de la parte frontend no necesitamos un programador fullstack sino solamente un programador con conocimientos frontend.

5. Las migraciones y mantenimiento es más fácil. Por ejemplo si queremos cambiar de alojamiento el frontend o bien crear otro diseño de usuario, podemos utilizar el viejo mientras se construye el nuevo diseño ya que la parte backend siempre funciona.

(42)

Clase 1

• Propiedades y métodos

Clase N

• Propiedades y métodos

Interfaz 1

• Propiedades

Interfaz N

• Propiedades

Controla dor 2

Controla dor N Controla

dor 1

2.4.2 Arquitectura de la parte frontend (MVC).

Figura 13: Arquitectura frontend:

Controladores frontend

Servicio 1 Servicio N

El usuario interactúa con elementos de la vista

Vista del sitio web

Modelo

formado por clases e interfaces

Request

(petición Response

Request

(petición) Response

(43)

La parte frontend del sitio web está implementada mediante el framework de Angular, que es un framework desarrollado en lenguaje de programación Typescript. Angular permite desarrollar aplicaciones SPA (single page

aplication) o aplicaciones de una sola página con arquitectura MVC (modelo vista controlador), y que como indican sus siglas la App se compone de una vista (aquello que se ve en pantalla y con lo que puede interactuar el usuario final), el modelo (que, a grosso modo, son las estructuras de datos que se utilizan en la aplicación), y los controladores de la aplicación, que conectan el modelo de datos con la vista.

Como elemento extra contamos con los servicios en Angular, que posibilitan las peticiones a la parte backend mediante una dirección o ruta. Las peticiones o request pueden ser de tipo GET, POST, PUT, DELETE.

Entonces el backend procesa la petición y envía la respuesta o response al servicio para que la parte frontend actúe en consecuencia.

2.4.3 Servicios de nuestra App.

Los servicios más relevantes del frontend son:

- Categorías

Contiene los métodos encargados de obtener todas las categorías. Y la categoría a la que pertenece un juguete en particular.

- Experiencia

Servicio con el que realizamos el CRUD (crear, leer, actualizar, eliminar) relativo a las experiencias.

- Juguete

Servicio con el que realizamos el CRUD (crear, leer, actualizar, eliminar) relativo a los juguetes.

- Favoritos

Servicio con el que añadimos o eliminamos de la lista de favoritos.

- Sesión

Contiene los métodos relativos a la sesión del usuario en actual (login, registro, logout, …)

- Tree

Este servicio contiene todos los métodos necesarios para convertir una estructura de array de dos dimensiones en una estructura de árbol y

recorrerlo y extraer la información de cada nodo del árbol que nos interese.

He utilizado esta estructura de datos en árbol para representar la jerarquía de las categorías de juguetes porque es la óptima en rendimiento y espacio en memoria. Por ejemplo un árbol de categorías podría ser:

(44)

Figura 14: Árbol de categorías:

Intuitivamente comprobamos que al acceder a los hijos directos de un nodo estamos accediendo a las subcategorías de la categoría padre, que es lo que nos interesa.

2.4.4 ¿Por qué Angular?

Hemos optado por escoger el framework de Angular para la implementación del frontend por los siguientes motivos:

1. Los componentes que integran una App de Angular permiten la reutilización para otras aplicaciones en el futuro.

2. Dividir la App en componentes facilita el trabajo haciéndola más comprensible y facilita su posterior mantenimiento.

3. Angular está pensado para aplicaciones que tengan un número considerado de componentes (50+), es decir para frontend grandes, no como Vue, pensado para frontends más pequeños. Nuestra App gegantoys.com puede escalar hasta formar un e-commerce completo de forma que se convierta en una App grande en el futuro, y por este motivo hemos escogido Angular.

Juguetes

Aire libre

Bicicletas triciclos

Cometas y juguetes voladores

De casa

Juegos de mesa

(45)

f1 f2 f3

f1 f2 f3

f1 f2 f3

Modelo relacional (clases php laravel)

2.4.5 Arquitectura de la parte backend.

Figura 15. Arquitectura backend.

Ruta Ruta Ruta

Enrutador

Controladores de backend

Controlador1 Controlador2 ControladorN

El controlador usa el modelo relacional

Selecciona el

controlador que toque

API Rest Respuesta del controlador en formato JSON

Interviene ORM (Mapeador del objeto relacional) que interactúa con la Base de datos.

(46)

Las peticiones o request que envía Angular mediante los servicios de la App al backend, implementado en PHP y con el framework de Laravel, son capturadas por el enrutador que desglosa la ruta recibida y escoge la función del controlador correspondiente para procesar la petición. El controlador usa el modelo de datos para interactuar con la base de datos y también con el ORM de Laravel para enviar una respuesta.

Los tipos de request enviadas al backend son cuatro: POST para crear un registro en la base de datos, PUT para actualizarlo, DELETE para eliminarlo y GET para realizar una consulta de lectura en la base de datos.

El controlador enviará una respuesta (response) al servicio que envió la petición.

Nuestro backend en Laravel implementa un API Rest en JSON. Es decir que las peticiones de consulta de la base de datos de juguetes son enviadas al frontend en formato de texto JSON ( utilizado muy comúnmente para el intercambio de datos entre aplicaciones ).

2.4.6 Controladores del backend.

Los controladores de nuestro backend son: juguete, experiencia, usuario, auth, favorito; que contienen las funciones que en conjunto realizan el CRUD (leer, actualizar, eliminar, crear) sobre la tabla de base de datos que su nombre indica.

2.4.7 ¿Por qué Laravel?

Hemos escogido el framework de Laravel para implementar el backend por los siguientes motivos:

1. Permite realizar una API Rest en el formato muy extendido para intercambiar datos denominado JSON.

2. Laravel permite introducir miles de registros de datos de prueba, fácilmente y en muy poco tiempo, en la base de datos sin tener que introducirlos manualmente debido a los Factories y Seeders de los que dispone.

3. Laravel incluye Eloquent, un mapeador de objetos relacionales (ORM) que facilita la labor al desarrollador para desarrollar código que interactúa con la base de datos.

(47)

4. Con Laravel podemos utilizar el paquete fortify que implementa métodos para la autentificación de usuario y además permite utilizar nuestra propia interfaz de usuario del frontend para realizar esta labor de autentificación (porque funciona mediante rutas). Fortify cuenta con las rutas y los controladores necesarios para implementar todas las funciones de autentificación que son: inicio de sesión, registro, restablecimiento de contraseña, verificación de correo electrónico, …¨

2.4.8 Base de datos

He utilizado el sistema de gestión de Base de datos relacional de MySQL.

Figura 16: Modelo de la base de datos.

(48)

Consideramos las siguientes relaciones dentro de la base de datos:

Tablas implicadas Relación entre ellas

Juguetes - Categorías 1 juguete tiene 1 categoría

1 categoría pertenece a N juguetes

Juguetes - Favoritos 1 juguete tiene N favoritos

1 favorito pertenece a 1 juguete

Juguetes - Experiencias 1 Experiencia pertenece a 1 juguete 1 juguete tiene N experiencias

Usuarios – Favoritos 1 Usuario tiene N favoritos

1 favorito pertenece a 1 usuario

Usuarios - Experiencias 1 Usuario tiene N experiencias

1 experiencia pertenece a 1 usuario

(49)

2.5 Análisis de mercado

Para hacernos una idea de la forma en que el público objetivo podría

reaccionar a nuestro producto y de su rentabilidad como negocio realizaremos un pequeño análisis de mercado que cubre los siguientes cinco puntos.

2.5.1 Definición del mercado objetivo.

El mercado objetivo lo segmentamos y nos centramos únicamente en el público objetivo, ignorando los demás segmentos que componen el mercado objetivo (región o país, precios, costumbres ) porque el escenario en que nos

encontramos es positivo y no influyen. Los rasgos comunes que tiene nuestro público objetivo son:

 Compra por internet.

 Tiene una cuenta en Amazon o no le importaría crearla.

 Público confiado con el programa de afiliados: precio, condiciones y garantías son idénticas que como una compra directa en Amazon se tratara.

 Tiene vínculos afectivos con niños.

2.5.2 ¿El mercado objetivo es grande y perdurable en el tiempo?

Siempre habrá niños a los que comprar juguetes, así que la venta en este sector está garantizada, sobre todo en periodos de fiestas navideñas. El tipo de venta online cada vez resulta con menos problemas para gente que los tiene o tenía, así que tanto las ventas como la forma de hacerlo perdura en el tiempo.

2.5.3. Competidores existentes.

Los competidores son las tiendas físicas u online de juguetes y otras webs de programas de Afiliados. Hay que tener en cuenta que los marketplaces, es decir los grandes e-commerce, acaparan el 70% de las búsquedas en internet de los usuarios sobre los comercios online. Y más del 80% de estos usuarios terminan comprando a través de estas plataformas de venta. Debido a esto los e-commerce pequeños no los consideramos un problema grande como competidor.

(50)

Ventajas competitivas de las que disponemos:

1. Toda la logística de entrega, procesos de devolución, reembolsos y

atención al cliente del juguete será responsable Amazon, y actualmente su Atención al cliente goza de buena salud.

2. Amazon tiene mucha clientela y es una plataforma con grandes beneficios de ventas.

Conclusiones

1. Necesitamos que el usuario al navegar por nuestro sitio web reconozca y valore nuestra web como una fuente de ayuda a la hora de decidir a

comprar el juguete y a sabiendas que se trata de una web de afiliados, no le importe y converja en Amazon.

2. Debemos preocuparnos como hándicap de ventas de nuestro negocio de Afiliados de NO albergar una web poco fiable con bajo rendimiento, con poca transparencia en la información de los juguetes, que genere desconfianza, un sitio web pobre en definitiva.

3. Para superar estas barreras o más bien estar en consonancia con el escenario que se nos presenta debemos enfocarnos en primer lugar en conseguir una buena posición SEO; disponer de descripciones y

redacciones de calidad que le usuario valore de nuestros juguetes y que marquen la diferencia con el resto de e-commerce además de un buen diseño y rendimiento web.

2.5.4. Cuál es nuestro público objetivo más relevante en términos de venta?

Nuestro público objetivo más relevante es aquél que compra los juguetes top- ventas de Amazon (Estos productos pueden coincidir que sean también

productos destacados de Amazon). No realizaremos el perfil de usuario que compra los juguetes top-ventas para actuar en consecuencia, sino que directamente buscaremos los juguetes top-ventas con los datos que

proporciona Amazon y realizaremos un buen diseño web y accesible para garantizar el éxito.

Los criterios de selección para introducir un juguete en nuestro sitio web serán:

(51)

- Calificación promedio alta de los clientes de Amazon.

- Juguete con baja tasa de devoluciones (son productos Amazon Choice sí o sí).

- Productos Prime.

- Ranking de más vendido del juguete.

2.5.5. Análisis de potencial: ¿Cómo podría desarrollarse el mercado objetivo en el futuro?

El desarrollo del mercado objetivo en el futuro depende de dos factores:

 El número de competidores potenciales que podrían entrar en el mercado y sus consecuencias en un futuro.

El programa de Afiliados puede ser una fuente de ingresos, y empezar un negocio de este tipo no requiere de grandes recursos económicos como veremos en el estudio de viabilidad. Es una metodología de negocio relativamente poco conocida. Estos dos factores nos lleva a pensar que podría llegar a haber muchos competidores en un futuro.

 Los acontecimientos y tendencias que podrían influir en el mercado futuro ( ya sea por causas jurídicas, ciclos económicos o tendencias sociales). Realizar una predicción de factores jurídicos, economía y tendencias sociales que puedan afectar al producto y su rentabilidad es complicado. Intuitivamente:

- Ganar dinero fácil a la larga se vuelve complicado. Un ejemplo puede ser el de las criptomonedas como el BitCoin desde sus inicios. Viene a ser análogo a la ley de la oferta y la demanda que a más demanda mayor es el precio. Es decir que si se vuelve tendencia social este tipo de negocio de Afiliados o similares, seguramente su rentabilidad se verá afectada.

- Como la inversión es poca para llevar a cabo este negocio, aprovecha la oportunidad si la ves factible y adáptate a los cambios (e.g jurídicos) si los hubiera y valiera la pena.

(52)

2.6 Viabilidad

Para lanzar el producto al mercado debemos tener en cuenta de si disponemos de los recursos necesarios y de su futura rentabilidad.

2.6.1 Recursos técnicos y económicos.

Recursos técnicos

Disponer de alojamiento Web (escalable en recursos de memoria y espacio por si los accesos al sitio crecen mucho) para publicar el sitio web en internet.

Nombre para tu dominio .com de tu sitio de afiliados.

Conexión SSH al servidor remoto.

Conexión FTP al servidor remoto.

Seguridad SSL para conexiones seguras https.

Una Base de datos.

Recomendable un email corporativo.

Una cuenta de afiliados de Amazon.

(53)

Recursos económicos (inversión necesaria)

Alojamiento Web (Hosting) 5€ / mes aprox.

Mantener el dominio de tu sitio bajo tu propiedad.

15€ /año aprox.

Contratar a persona para redactar descripciones, artículos o temas interesantes de forma profesional para nuestra web.

Texto legal de las cookies del sitio Puede variar en función de cómo obtenerlo

2.6.2 Comisiones que genera el producto.

Las comisiones que paga Amazon a sus afiliados varían en función del país, la categoría de los productos que se venden y el número de ingresos generados.

Definiciones:

 Compra adscrita directa: Al clicar en un enlace de nuestra web en un juguete el usuario es dirigido a Amazon y realiza la compra, se considera venta directa. Si en vez de comprar el producto anterior compra otro que pertenece a la misma categoría, también se considera venta directa porque el producto comprado pertenece a la misma categoría.

 Compra adscrita indirecta: Siguiendo con el ejemplo anterior, si el usuario viene de nuestra web, pero compra una bufanda, se considera compra indirecta porque pertenece a otra categoría de productos de juguetes.

(54)

Para España, estas son las tarifas estimadas para la categoría juguete:

Compras adscritas indirectas Compras adscritas directas

1.5%

6% (facturación mes < 7500€)

7% (facturación mes >= 7500€)

Si la suma de los precios de los productos facturados de ventas directas durante el mes en curso supera o iguala los 7500€ entonces, sobre esta cantidad percibiremos el 7% de comisión.

2.6.3 Rentabilidad

La inversión económica de nuestro producto durante un año asciende a:

(5€/mes de hosting x 12 meses) + 15€/año de dominio = 75€ / año

Por lo tanto para ser rentable, en un año, debemos realizar un total de ventas de juguetes superior a 1250€:

1250€ x 6% de comisión = 75€

(55)

2.7 SEO y Angular

El posicionamiento del sitio web en los buscadores es muy importante para ser visible en internet. Es decir, cuando el usuario escribe palabras en el buscador de Google de juguetes como es en nuestro caso, deseamos que nuestro sitio aparezca en las primeras posiciones de búsqueda. Una vez lanzado el

producto a internet debemos hacerlo visible utilizando diferentes técnicas:

- Crear datos estructurados de mi sitio web de juguetes en Angular, que proporcionará metadatos adicionales que describen mejor el contenido de las páginas del proyecto. El motor de búsqueda de Google destaca mejor las páginas basadas en estas especificaciones. El paquete de NPM (Gestor de paquetes de Nodejs) ng-json-ld sirve para crear datos estructurados.

- Crear una PWA del sitio Web. Una vez realizada la versión de escritorio del sitio web, puedes convertir esta versión a una PWA (Progressive Web App) que hacen uso de un conjunto de características y herramientas para

ofrecer una experiencia a una aplicación móvil. El objetivo es mejorar la carga en el navegador del sitio web que con la conversión se consigue ya que los motores de búsqueda valoran mucho las página rápidas.

- Realizar SSR (Serve Side Rendering). Al compilar un proyecto Angular obtenemos un fichero HTML que ejecutará el navegador para mostrar los contenidos al usuario. El problema es que el fichero HTML contiene los ficheros asociados .JS y CSS que son invisibles para los motores de búsqueda y que poseen información que mejorarían la posición en internet si fuera detectada por los rastreadores de búsqueda. Para solucionar este problema debemos usar Angular Universal que genera páginas estáticas a partir del código no compilado para que los rastreadores las puedan

detectar y analizar y así nuestro sitio ser más amigable con SEO y posicionarnos mejor en internet.

- Definir título y meta Tags en el sitio web. Podemos usar la clase Meta de

@angular/platform-browser para realizar el renderizado de estas etiquetas ya que en Angular, por defecto, no aparecen.

- Crear una URL canónica del sitio web. Para evitar contenido duplicado que Google sanciona.

(56)

$ composer create-project laravel/laravel example-app

2.8 Desarrollo e instalación del proyecto.

2.8.1 Desarrollo en local para la parte backend.

Para el desarrollo e implementación del backend en la máquina local bajo sistema operativo W10 Home se ha procedido a instalar los siguientes programas y herramientas y se han seguido los siguientes pasos:

1. Uso del IDE VS Code para codificar.

2. Herramienta Xampp, con ella se instala PHP, MySQL, phpMyAdmin (una interfaz para poder visualizar cómodamente y operar con la base de datos).

3. Instalar Composer:

Visitar el apartado correspondiente al S.O de la máquina donde se vaya a instalar: https://getcomposer.org/doc/00-intro.md

4. Crear un proyecto en Laravel mediante composer con el comando:

Este comando crea un proyecto llamado example-app con el framework de laravel. Seguidamente debemos proceder a la configuración del fichero .env en el directorio raíz del proyecto para conectar con la base de datos que se llama en nuestro caso ecommerce-juguetes y creada previamente con la ayuda de phpMyAdmin. La configuración en nuestro caso queda así para realizar la conexión:

(57)

$ php artisan make:migration nombre_tabla

$ php artisan make:model nombre_modelo DB_CONNECTION=mysql

DB_HOST=127.0.0.1 DB_PORT=3306

DB_DATABASE=ecommerce-juguetes DB_USERNAME=root

DB_PASSWORD=oaguilag1

5. El siguiente paso es realizar mediante la api de artisan proveído por laravel las migraciones de las tablas que vamos a utilizar mediante el siguiente comando:

Con las tablas de la base de datos creadas definimos los campos, cada uno con su tipo de dato, de los que consta cada una de ellas.

6. También creamos los modelos para poder relacionar las tablas entre sí.

Si hubiera alguna relación entre las tablas del tipo N   M deberíamos crear una tabla pivote para poder relacionarlas entre ellas al recuperar datos, pero no es nuestro caso en donde las relaciones son 1  N. Entonces las claves

foráneas forman un campo más de la tabla que corresponda.

7. Para realizar datos de prueba y “llenar las tablas” utilizamos seeders y los factories en Laravel.

(58)

$ php artisan make:controller nombre_controlador --resource

8. El siguiente paso importante es crear los controladores que se acceden mediante el registro de las rutas en el fichero api.php dentro del directorio routes de nuestra App.

Para crear un controlador de tipo resource (implementa por defecto las funciones para realizar el CRUD en base de datos) escribimos el comando:

9. Las rutas disponibles en el fichero api.php que irán a parar al controlador juguetes son ( en nuestro caso las rutas son end-points de una api, por lo que las escribimos en este fichero, si no fuera así las rutas irían en el fichero web.php ):

//API Juguetes

Route::get('/juguetes/page/{page}',

'App\Http\Controllers\JugueteController@index');

Route::get('/juguetes/titulos',

'App\Http\Controllers\JugueteController@juguetesTitulos')-

>middleware(middleware:'auth:sanctum') ;

Route::get('/juguetes/categoria/page/{page}/{literalABuscar}', 'App\Http\Controllers\JugueteController@busquedaPorCategoria');

Route::get('/juguetes/busqueda/page/{page}/{literalABuscar}', 'App\Http\Controllers\JugueteController@busquedaPorBuscador');

Route::get('/juguete/{id}',

'App\Http\Controllers\JugueteController@show');

Route::get('/juguete/publicar/{id}',

'App\Http\Controllers\JugueteController@publicar');

Route::get('/juguete/nopublicar/{id}',

'App\Http\Controllers\JugueteController@noPublicar');

Route::post('/juguete','App\Http\Controllers\JugueteController@store')-

>middleware(middleware:'auth:sanctum') ;

(59)

53

$ composer require laravel/sanctum

$ php artisan vendor:publish –provider=”Laravel\Sanctum\SanctumServiceProvider”

Route::post('/juguete-

update','App\Http\Controllers\JugueteController@update')-

>middleware(middleware:'auth:sanctum') ;

Route::delete('/juguete/{id}','App\Http\Controllers\JugueteController@des troy')->middleware(middleware:'auth:sanctum') ;

Cuando se ejecuta la función del controlador que se invoca según la ruta llegada, devuelve una respuesta al front-end.

Hasta aquí hemos implementado el funcionamiento básico para backend.

2.8.2 Funcionalidades destacables en el backend.

1. Autentificación de usuario mediante token, implementada con Sanctum.

En principio en este documento se contempló la implementación de la autentificación de usuario mediante fortify, pero para el correcto

funcionamiento y en nuestro caso de SPA (aplicación de una sola página) la autentificación se ha de realizar mediante Sanctum. Fortify puede combinarse con Sanctum para realizar autentificaciones de doble factor (con móvil e.g), pero en esta App, solamente realizaremos autentificación mediante token con Sanctum y los pasos a seguir son los siguientes:

 Ejecutar el comando:

 Publicar:

(60)

$ php artisan migrate:fresh

$ php artisan make:mail ContactanosMailable

Una vez realizada la publicación ejecutamos:

para borrar y volver a crear las tablas de nuestra B.D que ya teníamos y además añadir una tabla por parte de Sanctum donde se almacenarán los tokens de usuario. Así y entonces para el login, y registro del usuario creo un controlador nuevo que nos permite aprovecharnos de este sistema de

autentificación (ver el código fuente del controlador Authcontroller de la App para ver cómo trata los tokens).

Las rutas que deben ser protegidas mediante autentificación que provienen del frontend y que llegan al backend quedan codificadas de esto modo en nuestro fichero api.php:

Route::post('/juguete-

update','App\Http\Controllers\JugueteController@update')-

>middleware(middleware:'auth:sanctum') ;

En el código anterior, en la request que llega, debe contener el token de autentificación que verifica Sanctum mediante el middleware que provee este sistema. Si Sanctum no encuentra el token en la request, devuelve como respuesta que el usuario no está autorizado y no hace nada más.

2. Envío de email mediante Mailable en Laravel.

Los pasos que hemos realizado para enviar un email desde nuestra App (esta función solamente está disponible desde producción) son:

 Ejecutamos el comando en la consola:

Referencias

Documento similar

[r]

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

Habiendo organizado un movimiento revolucionario en Valencia a principios de 1929 y persistido en las reuniones conspirativo-constitucionalistas desde entonces —cierto que a aquellas

Por lo tanto, en base a su perfil de eficacia y seguridad, ofatumumab debe considerarse una alternativa de tratamiento para pacientes con EMRR o EMSP con enfermedad activa

The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,

o Si dispone en su establecimiento de alguna silla de ruedas Jazz S50 o 708D cuyo nº de serie figura en el anexo 1 de esta nota informativa, consulte la nota de aviso de la

De hecho, este sometimiento periódico al voto, esta decisión periódica de los electores sobre la gestión ha sido uno de los componentes teóricos más interesantes de la