Introducción al uso de API’s

Ahora sí. Después de pasar la casi totalidad del curso trabajando en nuestra aplicación de una forma bastante limitada, ha llegado la hora de aprender a comunicar los componentes con API’s, es decir, procesos remotos que se ejecutan en el servidor para trabajar con nuestros datos. Por ejemplo. El CRUD que hicimos de socios está muy interesante, pero tiene un problema. Cuando recargamos la página, perdemos los datos de todos los socios que hayamos grabado o editado. Es normal. Estos datos sólo viven en la memoria del navegador durante el ciclo de ejecución de la aplicación. Evidentemente, aunque lo que hemos hecho tenga valor didáctico, en la práctica no sirve para nada si no podemos persistir los datos en una base de datos remota.

Hay muchos otros casos en los que necesitaremos acceder a procesos que se ejecutan en el servidor. De hecho cualquier aplicativo web es inconcebible actualmente sin trabajar contra API’s de un servidor que, a su vez, manipulen o procesen datos, o hagan cualquier otra cosa que no podamos llevar a cabo, únicamente, en el lado del cliente.

Comunicar con este tipo de artefactos desde Angular es un proceso sencillo, eficiente y potente, y en esta sección del curso vamos a aprender a dominarlo.

CONECTAR EN PLAN CASERO

Ahora que ya sabemos como podemos emplear jQuery en nuestras aplicaciones Angular, cuando hablamos de conectar con una API para persistir o leer datos seguro que lo primero que te viene a la cabeza es utilizar Ajax en jQuery para enviar o recibir datos. La idea no está mal. Sin embargo, Angular nos proporciona herramientas propias para realizar estas operaciones de una forma mucho más acorde con el framework. A la larga, será siempre mejor emplear las herramientas y técnicas propias de Angular. Sin embargo, eso no quiere decir que no usemos algunos conceptos más propios de JavaScript, de modo genérico, que específicamente de Angular. Conoceremos las herramientas que Angular nos proporciona para lograr la conectividad con API’s, pero también veremos que parte del proceso puede (y debe) hacerse en JavaScript.

PREPARANDO EL ESCENARIO

Lo primero con lo que vamos a contar es con un directorio específico, dentro de nuestro localhost, para las pruebas en este terreno. Dentro de este directorio tendremos tres scripts PHP que servirán para registrar un nuevo socio, leer la lista de socios o borrar un socio de la lista. Los socios se persistirán en una base de datos MySQL. La estructura de la base de datos y los scripts PHP no necesitamos conocerlos por ahora. Los encontrarás disponibles para descargar cuando llegue el momento. De momento, nos basta con saber lo que hacen, pero no como lo hacen. Supongo que estás familiarizado con PHP y MySQL pero, si necesitas conocer más, puedes leer sobre el tema en este mismo blog (en las secciones OOP y Buenas prácticas), y en eldesvandejose.com.

LOS ENVIRONMENTS

El primer paso que tenemos que dar con nuestra aplicación es indicarle dónde van a estar nuestras API’s. Deberemos establecer dos rutas generales: una para desarrollo y otra para producción. Lo que haremos es indicarle a la aplicación cuales son las rutas «base» de las APIS’s. Por ejemplo, supongamos el caso de que tenemos las tres que hemos mencionado. Es posible que las rutas para alcanzarlas para desarrollo sean las siguientes:

http://localhost/apis/mi_crud/grabar_nuevo.php
http://localhost/apis/mi_crud/listar.php
http://localhost/apis/mi_crud/editar.php

La ruta base (es decir, la parte «común») sería http://localhost/apis/mi_crud/.

Ahora supongamos que tenemos previsto que, cuando pasemos a producción, las API’s van a ser las siguientes:

http://mis_apis.com/grabar_nuevo.php
http://mis_apis.com/listar.php
http://mis_apis.com/editar.php

La ruta base para producción sería http://mis_apis.com/.

Bien. Pues estas dos partes comunes se las tenemos que indicar a la aplicación. En el directorio src tenemos un directorio llamado environments. Dentro hay dos ficheros: src/environments/environment.ts y src/environments/environment.prod.ts. En principio, el primero tiene el siguiente código:

Y el segundo tiene algo parecido, con una diferencia interesante:

Como ves, en el de desarrollo la variable production vale false, mientras que en el de producción esta variable vale true. Esta variable es empleada por Angular para seleccionar un fichero u otro, dependiendo de si estamos ejecutando nuestra aplicación en desarrollo, o la versión distribuible (compilada). Vamos a modificar estos ficheros. El de desarrollo quedará así:

El de producción, por su parte, quedará así:

Cómo Angular elegirá, de forma transparente a nosotros, el archivo que corresponda al modo en que estemos trabajando (desarrollo o producción), en la variable API_URL siempre tendremos la ruta base adecuada para que la aplicación localice la raíz de nuestras API’s. Esta variable puede llamarse como deseemos. El nombre que yo le he puesto es el que he elegido, pero puede ser el que sea. Lo que realmente importa es que esta variable estará disponible con solo importar el fichero adecuado en donde lo necesitemos. Es algo que veremos en este mismo artículo.

IMPORTANDO EL MÓDULO HttpClientModule

Angular implementa un módulo propio que permite establecer las comunicaciones HTTP. Se llama HttpClientModule. Debemos importarlo en la raíz del proyecto, es decir, en AppModule, concretamente, en el fichero app.module.ts, que quedará de una forma similar al siguiente ejemplo (observa las líneas resaltadas):

IMPORTANDO LO QUE NECESITAMOS, DONDE LO NECESITAMOS

Aún hay otras importaciones que hacer. Las comunicaciones podemos hacerlas desde uno o más componentes, o desde uno o más servicios, o desde algunos componentes y/o algunos servicios. Es decir, podemos hacerlas desde donde nos haga falta. Puede que nuestra aplicación sea muy sencilla (como son las que estamos viendo hasta ahora), o muy compleja. En todo caso, en los archivos TypeScript de los componentes y de los servicios desde los que tengamos que alcanzar las API’s deberemos incluir, en la parte superior, tres importaciones esenciales. En el ejemplo que estamos preparando para estos artículos yo las hago en members.service.ts, pero podemos hacerlas en otros lugares, si las vamos a necesitar. Las tres líneas a incluir, en la parte superior de nuestros componentes y/o servicios serán las siguientes:

La primera línea importa la clase HttpClient, que necesitaremos para instanciar un cliente HTTP. La segunda importa la clase Observable, de la librería rxjs. Se trata de una librería de uso libre, desarrollada por Microsoft e implementada por Angular. La última línea importa el archivo de entorno, que contiene la variable donde definimos la ruta base de nuestras API’s. Y aquí entra la magia de Angular. No tenemos que preocuparnos de si el archivo que se importa es el de desarrollo (environment.ts) o el de producción (environment.prod.ts). Cuando estamos desarrollando, y ejecutamos nuestra aplicación en desarrollo, Angular importa el archivo de desarrollo. Sin embargo, cuando creamos la versión distribuible (con npm run build, si lo recuerdas), Angular incluirá, en esta, el archivo de entorno de producción. Nosotros no tenemos que preocuparnos de esto, como te he comentado anteriormente. Con esto, ya tenemos la ruta base adecuada a cada entorno, en la variable enviroment.API_URL, donde API_URL es el nombre que le dimos a esta variable en sendos archivos (el mismo nombre en ambos, eso sí).

La clase HttpClient debemos usarla para crear un objeto, al que llamaremos http (aunque podemos llamarlo como queramos), dentro de la clase del servicio. Podemos hacerlo, directamente, en el constructor, así:

constructor(private http: HttpClient)

Este objeto lo necesitaremos en el próximo artículo.

CONCLUYENDO

En este artículo hemos preparado el escenario, es decir, hemos preparado nuestra aplicación para poder acceder a las APIS’s cuando lo necesitemos. En esta aplicación sólo podremos acceder desde members.service.ts (o desde los componentes que inyecten este servicio, en su caso), porque es el único sitio donde hemos importado HttpClient, Observable y environment. En el siguiente artículo empezaremos a ver qué hacer con todo esto que hemos montado.

   

Deja un comentario