Introducción al Stack MEAN y sus componentes: MongoDB, Express, AngularJS y NodeJS

Introducción

Node.js es una tecnología o plataforma que permite programar con JavaScript del lado del servidor y que ha ido ganando popularidad en los últimos años. Empezó usándose en pequeños proyectos o medianas empresas y ahora puede verse en grandes compañías como Microsoft, eBay, LinkedIn, Yahoo, WalMart, Uber, Oracle, y muchos más.

¿Por qué MEAN?

El stack MEAN usa cuatro componentes de software, MongoDB, ExpressJS, AngularJS y NodeJS. Estas cuatro herramientas juntas permite a los desarrolladores crear aplicaciones de forma eficiente, bien estructurada y rápida. Todos los componentes del stack usan JavaScript, usando para todo este lenguaje podemos hacer cosas cosas como:

– Usar JavaScript del lado del servidor (Node y Express)

– Usar JavaScript en el lado del cliente (Angular)

– Almacenar objetos JSON en MongoDB

– Usar los objetos JSON para transferir datos fácilmente de la base de datos al servidor y del servidor al cliente

El hecho de usar solo JavaScript como lenguaje aumenta la productividad. Los desarrolladores del lado del cliente que trabajan con Angular pueden entender fácilmente la mayoría del código del lado del servidor y viceversa.

En la base de datos almacenamos información como formato JSON. Después podemos escribir queries JSON (peticiones) en nuestro servidor Node y enviar estas peticiones directamente a nuestro front-end usando Angular. Esto es especialmente útil cuando tienes a varios desarrolladores trabajando en un proyecto. El código del lado del servidor es más legible por los desarrolladores front-end y viceversa.

La facilidad de desarrollo será mucho más evidente una vez empezamos a indagar en ejemplos y con suerte os salve a tu equipo y a ti de algunos quebraderos de cabeza en el futuro.

Cuándo usar el Stack MEAN

Los beneficios del stack MEAN provienen de la robustez de Node. Node nos proporciona su API abierta en real-time (tiempo real) la cual podemos usar libremente con nuestro código frontend en Angular. Podemos usarlo para transferir datos para aplicaciones como chats, actualización de estados, o cualquier otra situación que requiera mostrar datos rápidamente en tiempo real:

  • Chat
  • Actualización de estados en tiempo real por el usuario (como Twitter)
  • RSS feed
  • Tienda online
  • Polling app (aplicación para votaciones)

Cuando NO usar el Stack MEAN

Como pasa con cualquier otro lenguaje o grupo de lenguajes, hay muchas situaciones en las que usar MEAN podría no ser lo más adecuado y esto es muy importante saberlo antes de meternos de lleno a programar. Muchos de los beneficios del stack MEAN y las razones por las cuales deberías usarlo van enlazadas al uso de Node.

Node por lo general no es la mejor elección para tareas intensivas de CPU. Ha habido algunos casos donde Node en efecto ha ido bien con aplicaciones pesadas, pero como principiante es mejor alejarse de Node si sabes que tu aplicación requiere de mucha CPU.

¿Quién usa MEAN?

Muchos desarrolladores han estado rezando por la llegada del Stack MEAN. Este stack usa JavaScript para todas sus operaciones, lo que lo hace atractivo para los desarrolladores que quieren crear un proyecto de forma fluida.

Algunas de las grandes compañias ya han cosechado beneficios y han integrado Node en varias de sus operaciones:

 

 

 

New_Walmart_Logo

Walmart: Walmart empezó usando Node.js en 2012 para dar a los usuarios de móvil una moderna experiencia front end. Haciendo uso de la plataforma JavaScript, fueron capaces de integrar de forma rápida y sencilla sus APIs existentes con su aplicación Node. Declararon que el 53% del tráfico online de su Black Friday iba a sus servidores Node con 0 de inactividad.

 

 

Yahoo_Logo

 

Yahoo!: Yahoo empezó experimentando con Node en 2010. Al principio lo usaban para pequeñas tareas como subir archivos, y ahora usan Node para controlar casi 2 millones de peticiones por minuto. Han notado un incremento en la velocidad y una simplificación en el proceso de desarrollo.

 

LinkedIn-Logo-2C

 

LinkedIn: LinkedIn empezó a desarrollar el lado del servidor de su app móvil totalmente con Node. Antes usaban Ruby, pero desde que cambiaron han visto un enorme incremento en rendimiento, en un rango de 2 a 10 veces más rápido.

 

 

Paypal_logo-5

 

Paypal: Paypal recientemente se ha subido a bordo de Node y empieza a migrar su código Java a Node. Empezaron experimentando solo con la página de Account Overview, pero una vez vieron que la velocidad se incrementó en un 35% y el coste de desarrollo se redujo a la mitad, empezaron a pasar todo el sitio a Node.js.

 

Y muchas empresas más en la página Node Industry.

 

Primer vistazo

Vamos a echar un vistazo rápido a las tecnologías que usaremos. Recuerda, esta serie de tutoriales están destinados a enseñar
cómo todas estas piezas trabajan juntass, así que no va a meternos en las técnicas más avanzadas
y conceptos de cada uno. Dejaré enlaces a más recursos para complementar los conocimientos adquiridos en cada sección.

 

mongo_db

MongoDB, llamado así por la palabra “humongous”, es una base de datos de código abierto NoSQL, base de datos que almacena documentos en formato JSON. Se sitúa líder de las bases de datos NoSQL, según el estudio a partir del número de búsquedas en Google y demandas en ofertas de trabajo.

Mongo vs MYSQL

LAMP, que usa MYSQL, ha sido el stack lider durante varios años hasta ahora. MYSQL es clasificado como una base de datos relacional.

Base de datos relacional. Los datos se almacenan en tablas que no solo contienen datos, sino que también establecen las interconexiones (relaciones) con otros datos (que están guardados en otras tablas) en la base de datos.

Bases de datos documentales

Las bases de datos de MongoDB, por otro lado, son clasificadas como una base de datos no relacional, más concretamente una document-oriented database (base de datos orientada a documentos). Esto significa que defines tu estructura de datos como quieras. Gestiona datos semiestructurados, es decir, documentos. Luego puedes coger estos datos para combinarlos con tu aplicación y sus requisitos funcionales. También puedes fácilmente tomar objetos complejos e insertarlos en tu base de datos usando en tu base de datos usando JSON, XML, BSON, u otros formatos similares que se adapten mejor a tu aplicación. En resumen, estos datos son almacenados en los formatos citados anteriormente. Incluso puedes guardar documentos PDF en ciertas bases de datos documentales si se da el caso.

Base de datos orientada a documentos: Un tipo de base de datos NoSQL que almacena y recupera datos en documentos semiestructurados (en lugar de las tablas de los bases de datos relacionales).

Los modelos de datos en MongoDB son extremadamente flexibles. Una de las formas de almacenar datos es creando documentos y creando referencias para relacionar los datos. Puedes ver debajo que la ficha de información de nuestro Hobbit contiene información que podemos referenciar con el Hobbit Address Document:

Hobbit Info json { id: “1343”, name: “bilbo”, age: “50”, type: “hobbit” }

Hobbit Address Book json { hobbit_id: “1343”, city: “the-shire”, state: “middle-earth” }

Otra forma es insertando la Hobbit Address directamente en el documento Hobbit Info, de esta forma tienes un solo documento por cada Hobbit, permitiendo menos operaciones de escritura a la hora de actualizar información sobre un Hobbit y un mayor rendimiento (suponiendo que el documento no crecerá demasiado).

Una vez empiezas a guardar información sobre varios hobbits, cada uno de tus documentos se pueden clasificar como uno solo en una Hobbit Info Collection. Una colección simplemente es un grupo de documentos relacionados. En este caso tendremos los mismos campos con diferentes valores.

Las bases de datos NoSQL están pensadas para ser escalables y distribuidas.Y por ser distribuidas tendremos que tener en cuenta el teorema CAP.

El teorema CAP

El teorema CAP o teorema Brewer, dice que en sistemas distribuidos es imposible garantizar a la vez: consistencia, disponibilidad y tolerancia a particiones (Consistency-Availability-Partition Tolerance). Veamos qué son estas características:

  • Consistencia: todos los nodos de tu aplicación están disponibles entre ellos y muestran el mismo dato al mismo tiempo, al realizar una consulta o inserción siempre se tiene que recibir la misma información.
  • Disponibilidad: que todos los nodos se puedan leer y escribir.
  • Tolerancia a particiones: esta condición implica que el sistema tiene que seguir funcionando aunque existan fallos o caídas parciales que dividan el sistema.

Ha habido cierta confusión a la hora de interpretar esto, así que Brewer señala que todo se reduce a la Consistencia VS Disponibilidad. Si prestamos atención a sus definiciones vemos que estos dos conceptos se excluyen entre sí. Digamos que permites que todos los nodos estén disponibles para la lectura y la escritura en todo momento.

Un ejemplo real podría ser una app para un banco. Vamos a suponer que no los sobregiros bancarios (cuando el banco permite pagos más elevados que la suma que tienes en tu cuenta) y todas esas cositas “divertidas” no existen. El banco necesita saber el saldo de tu cuenta en todo momento. Si tienes 1000€ y retiras 1000€  te quedas a cero. Debido a que todos los nodos están disponibles para lectura y escritura, existe la posibilidad de que se lance el cobro de otra deuda en esa pequeña fracción de segundo en el que el saldo de tu cuenta aún se lee como 1000€. Así que cuando el saldo de tu cuenta se actualice dará lugar a un saldo negativo porque se ha autorizado un segundo pago de deuda que no debería haberse permitido. Está es la razón por la que la consistencia es más importante en este tipo de app bancaria.

El precio de la consistencia es renunciar a cierta disponibilidad. Tan pronto como se retiró el dinero en el ejemplo anterior debería haberse puesto en marcha un bloqueo para evitar que el saldo de la cuenta fuera leído como 1000€. Si tu aplicación no es capaz de leer cada nodo en cada segundo, entonces puede aparecer como caída o no disponible para algunos usuarios. Algunas aplicaciones tienden a favorecer la disponibilidad y el rendimiento frente a la consistencia, que es donde brillan muchas bases de datos orientadas a documentos.

MongoDB por defecto favorece la consistencia por encima de la disponibilidad. Pero se puede configurar para brindar más a apoyo a una u otra característica. El bloqueo de la lectura-escritura está en el ámbito de cada base de datos, por lo que cada nodo dentro de la base de datos siempre ve los datos al día. Debido a que MongoDB soporta sharding o particionado, una vez tu base de datos empieza a crecer los datos pueden partirse en múltiples bases de datos (o shards) a través de varios servidores. Cada shard será una base de datos independiente, formando una colección de bases de datos. Esto permite consultas más rápidas ya que solo necesitas acceder al shard (fragmento) que contiene esa información en vez de a toda la base de datos. Se puede también, sin embargo, causar inconsistencia de shard a shard durante un corto periodo de tiempo después de una escritura. Esto se llama consistencia eventual y constituye un compromiso común entre consistencia y disponibilidad.

Características principales

nodejs-light

Node.js esta basado en el motor V8 de Javascript de Google Chrome y juega su papel en el lado del servidor dentro de nuestra aplicación con MEAN. Este motor está diseñado para correr en un navegador y ejecutar el código de Javascript de una forma extremadamente rápida. ¿Qué significa esto? En un stack LAMP tienes tu servidor web (Apache, Nginx, etc) corriendo con un lenguaje de script del lado del servidor (PHP, Perl, Python) para crear un sitio web dinámico. El código del lado del servidor se usa para crear el entorno de la aplicación extrayendo datos de la base de datos (MYSQL) y después es interpretado por el servidor para producir la página web. Cuando se hace la petición de una nueva conexión, Apache crea un nuevo thread (hilo) o proceso para controlar esta petición, haciendo que sea multitarea (multihilo). A menudo tendrás un número de procesos hijos inactivos en espera para ser asignados a una nueva petición. Si configuras el servidor para tener a solo a 50 procesos hijos inactivos y entran 100 peticiones, algunos usuarios pueden pasar por un tiempo de espera de conexión hasta que varios de esos procesos se liberen.

Por supuesto, hay formas más eficientes de controlar esta escalabilidad, pero generalmente Apache usa un hilo por petición,  así para soportar a más y más usuarios con el tiempo necesitarás más y más servidores.

El multiprocesamiento o multihilo (en inglés multithreading) es un modelo de programación donde el flujo del programa  tiene varios hilos en ejecución. Diferentes partes del programa (hilos, threads) son capaces de ejecutarse simultáneamente e independientemente, en vez de esperar a que cada evento se finalice. Es bueno para que el usuario no tenga que esperar a que cada evento termine para ver alguna acción, pero cada nuevo thread o hilo consume más memoria y necesita su propia pila (o stack) donde almacenar variables locales, así se compensa la ganancia de rendimiento por un consumo mayor de memoria.

Aquí es donde destaca Node.js. Node es un lenguaje de programación orientado a eventos que juega el mismo papel que Apache. Interpreta el código del lado del cliente para producir la página web. Son similares en que cada conexión dispara un nuevo evento, pero la principal diferencia viene del hecho de que Node es asíncrono y de un único hilo en ejecución. Una aplicación para Node se programa sobre un solo hilo, con el que controla todas las peticiones.

Utiliza un modelo I/O (entrada/salida) orientado a eventos y basado en el ‘no-bloqueo’, que lo hace ligero y eficiente.

Si en la aplicación existe una operación bloqueante (I/O), Node.js crea entonces otro hilo en segundo plano, pero no lo hace por cada conexión, como haría un servidor web como por ejemplo Apache.

Programación orientada a eventos. El flujo de un programa se controla por una serie de eventos concretos (clicks del ratón, mensajes entrantes, teclas pulsadas, etc). En la mayoría de las GUIs (graphical user interface) hay eventos  y esta técnica de programación se puede implementar en cualquier lenguaje.


Programación asíncrona. En la programación asíncrona o no bloqueante los eventos se ejecutan independientemente del “flujo” principal del programa (la secuencia de ejecución de instrucciones en un programa) y no bloqueamos la ejecución. En lugar de no hacer nada a la espera de que suceda un evento, el programa pasa un evento a la cola y continúa con la ejecución. Una vez el evento está listo, el programa lo devolverá con un callback (nos ayuda a retornar el resultado cuando esté listo), ejecuta el código, y después vuelve al flujo principal. Por eso un programa asíncrono no corre en el típico orden de arriba a abajo que solemos ver en los programas síncronos.

Digamos por ejemplo que entra una consulta de la base de datos. Dependiendo del tamaño de la consulta, podría tardarse un par de segundos en devolver algo. Dado que solo hay un thread/hilo, puede parecer que no se puede procesar nada más mientras la consulta se está ejecutando. Esto daría como resultado tiempos de carga lentos para tus usuarios y que puede costarle el éxito a tu sitio web. Afortunadamente Node maneja multiples peticiones de forma elegante usando callbacks.

Callbacks asíncronos. Una función que es pasada como parámetro para ser ejecutada más adelante (cuando este lista). Los callbacks se usan cuando una función necesita más tiempo para ejecutarse para devolver los valores correctos. Es una forma de decirle a tu programa “cuando hayas terminado con esto, haz todo esto”.

Hay dos tipos de callbacks: síncronos y asíncronos. Los callbacks síncronos se consideran los callbacks de “bloqueo”, significa que tu programa no continuará su ejecución hasta que la función callback termine de ejecutarse. Puesto que a las operaciones de I/O (input/entrada y output/salida) les lleva mucho tiempo ejecutarse, puede parecerles a los usuarios que tu aplicación es lenta o se ralentiza.

Node usa callbacks asíncronos (también conocidos como callbacks de no-bloqueo) que permiten que tu programa siga ejecutándose mientras las operaciones de I/O dan lugar. Una vez que las operaciones se hayan completado, se emite un callback para decirle a tu programa que ya está preparado para ejecutarse. Una vez que la función se ha completado, el programa volverá a lo que estaba haciendo. Claro que, al tener muchos callbacks por tu código puede volverse todo muy caótico,

Ej: Tomando como ejemplo otra consulta a la base de datos, luego de una lectura de la misma, defino un callback para realizar cálculos con las filas recuperadas de la base de datos. O sea, ejecuto una llamada a una función cualquiera, la llamada devuelve valores a la función callback, dentro de la función callback puedo hacer algo. por lo que depende de ti, el programador, asegurarte de que lo hace correctamente.

NPM y Packages

Uno de los beneficios de Node es su gestor de paquetes, npm (node package manager) y nos permite gestionar todas las dependencias y módulos de una aplicación  Al igual que Ruby tiene RubyGems y PHP tiene Composer, Node tiene npm.

Viene ya incluido con Node y permite que nos bajemos una serie de packages/paquetes para satisfacer nuestras necesidades. Los packages amplían la funcionalidad de Node y este sistema de paquetes una de las cosas que hace a Node tan potente.

La capacidad de tener una serie de códigos que puedes reutilizar en todos tus proyectos es increíble y hace que el desarrollo sea mucho más sencillo. Puedes combinar varios paquetes para crear aplicaciones complejas.

A continuación pongo los paquetes más populares de Node:

  • ExpressJS – Actualmente es el package más famoso de node (y que usaremos en el resto de tutoriales como framework).
  • Mongoose – Es el paquete que usaremos para interactuar con MongoDB.
  • GruntJS  – Para automatizar tareas/tasks (lo usaremos más adelante).
  • PassportJS – Para implementar registros o autenticación de usuarios.
  • Socket.io – Para crear apps con comunicación bidireccional en tiempo real entre cliente y servidor (websocket apps).
  • Elasticsearch – Nos proporciona alta escalabilidad  en operaciones de búsqueda/search.

Frameworks

Existen varios frameworks para Node, nosotros usaremos Express en estos tutoriales, pero los conceptos que aprendamos se pueden trasladar fácilmente a otros frameworks.

Otros frameworks de interés son:

  • HapiJS – Excelente framework que empieza a ser usado cada vez más por fuertes empresas.
  • KoaJS – Un fork de Express, diseñado por el mismo equipo que lo empezó.
  • Restify – Toma prestada la sintaxis de Express para crear un framework dedicado a la construcción de APIs REST.
  • Sails – Un framework MVC (Model–view–controller).

Express gestiona casi todas las tareas que necesites y es extremadamente robusto, rápido, flexible, y ahora tiene respaldo comercial, ya que recientemente lo ha comprado/patrocinado StrongLoop.

Si bien estos otros frameworks han demostrado por sí mismos ser geniales (échales un vistazo, en serio), nosotros nos centraremos en Express. Al fin de cuentas, esto es el Stack MEAN.

ExpressJS

Express es una plataforma ligera para construir aplicaciones web usando NodeJS. Nos ayuda a organizar las aplicaciones web en el lado del servidor. En la web de ExpressJS, lo describen como “un framework de desarrollo de aplicaciones web minimalista y flexible para Node.js.

Express esconde muchas funcionalidades internas de Node, lo que te permite sumergirte en el código de tu aplicación y conseguir tus objetivos de forma muy rápida. Es fácil de aprender y te deja cierta flexibilidad con su estructura.

Por algo es el framework más popular de Node. Algunos nombres destacados que usan Express son:

  • MySpace
  • LinkedIn
  • Klout
  • Segment.io

Y muchos más en esta lista.

De entre tantas cosas que puede hacer este framework, podemos destacar:

  • Router
  • Manejo de peticiones
  • Configuración de la aplicación
  • Middleware

No te preocupes si estos términos son nuevos para ti, a medida que avancemos en los tutoriales profundizaremos en cada uno de estos componentes, los aprenderemos y los usaremos.

 

AngularJS-large

Angular, creado por Google, es un framework de JavaScript MVC para el desarrollo front end de forma rápida y dinámica.

Permite extender el vocabulario de tu HTML con directivas y atributos para crear componentes dinámicos. Si alguna vez has hecho una página web dinámica sin Angula te habrás dado cuenta de ciertas complicaciones frecuentes, como el data binding, validación de formulario, manejador de eventos con DOM (Document Object Model) y otras muchas. Angular presenta una solución “todo-en-uno” a esos problemas.

La curva de aprendizaje para Angular es muy pequeña, lo que explica que mucha gente se este pasando a este framework. La sintaxis es simple y sus principios básicos como el data binding (vinculación de elementos de nuestro documento HTML con nuestro modelo de datos) y la inyección de dependencias son sencillas de pillar con unos cuantos ejemplos, que por supuesto haremos en estos tutoriales.

Los dos puntos fuertes de Angular son el data binding y la inyección de dependencias:

Data Binding

Si vienes del país de jQuery, estarás familiarizado con el uso de selectores CSS para acceder al DOM. Cada vez que quieras obtener el valor de un input, necesitas usar $(‘input’).val();. No digo que este mal, pero cuando tienes aplicaciones grandes con muchos input boxes, llega a ser un tanto tedioso controlarlo.

Con Angular se ha eliminado la manipulación del DOM y al ser modelo MVC (model-view-controller) tus datos están en un lugar. Mediante el data binding, la vista (archivos HTML) se actualizará automáticamente cada vez que el modelo cambie y viceversa.

Inyección de dependencias

Un app en Angular la conforman un grupo de módulos/componentes diferentes que se unen para construir tu aplicación. Por ejemplo, la aplicación podría tener un modelo para interactuar con un objeto específico de una API, o un controlador que mandara datos a nuestras vistas, o un módulo que manejara el enrutamiento de nuestra app Angular…

Inyección de dependencias. Una dependencia en tu código se produce cuando un objeto depende de otro. Hay diferentes grados de dependencia, pero tenerla en exceso hace que testear tu código sea complicado o que algunos procesos se ejecuten más tiempo de la cuenta.

La inyección de dependencias es un método por el cual damos a un objeto las dependencias que requiere para su funcionamiento.

Tener aplicaciones compartimentadas y modulares nos da muchos beneficios. Al igual que los packages en Node y PHP o las gemas en Ruby, podemos reutilizar los módulos o componentes en diferentes proyectos e incluso bajarnos módulos que otros desarrolladores hayan creado. Mediante la inyección de estos módulos en nuestra aplicación, podemos testear cada módulo por separado. Siéndonos posible determinar que parte de nuestra app está fallando y limitar el problema a solo ciertos grupos de código.

Otras características:

  • MVC
  • Directives/directivas
  • Scopes
  • Templates
  • Tests unitarios

Pensando en MEAN

Cuando hagamos aplicaciones con el stack MEAN en esta serie de tutoriales, hay una forma de pensar que debemos emplear. Hablamos del modelo cliente-servidor. Vamos a pensar en nuestra aplicación como dos partes separadas que se encargan de tareas específicas. Los proveedores de un recurso o servicio (servidores/backend/Node) controlan la capa de datos y proporcionarán información a los solicitantes de nuestros servicios (clientes/frontend/Angular).

The providers of a resource or service (servidr/backend/Node) will handle the data layer and will provide information to our service requesters (clients/frontend/Angular).

Modelo Cliente-servidor

En esta serie de tutoriales pensaremos en el modelo cliente-servidor, es muy importante ser conscientes de esto mientras aprendemos el stack MEAN.

Modelo Cliente-servidor. La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Pueden residir en un mismo ordenador o comunicarse a través de una red.

Son muchos los beneficios al tener presente nuestra aplicación como dos partes separadas. Al tener nuestro servidor como una entidad propia con una API con la que podemos acceder a todos nuestros datos, estamos proporcionando una forma de crear una aplicación escalable.

Esta forma de pensar no es exclusiva del stack MEAN. Existen numerosas aplicaciones que podrían beneficiarse de este tipo de arquitectura. Tener el código del lado del servidor separado nos deja crear múltiples aplicaciones front-end clientes como páginas webs,  Android apps, iPhone apps, etc.

Podemos recorrer nuestro código del lado del servidor y esto no afectará a nuestro código frontend. Vemos como grandes empresas como Facebook, Google, Twitter y GitHub usan este método. Tienen una API y sus clientes frontend (webs, app móviles y aplicaciones de terceros) se integran con ésta.

Nota: a la práctica de usar tu propia API para construir un cliente frontend se le llama dogfooding (da risa).

Componentes del servidor

  • Base de datos (MongoDB)
  • Servidor/API (Node y Express)

Componentes del cliente

  • Frontend (Angular)

Resumen y esquema del funcionamiento de este stack:

Arquitectura del Stack MEAN

 

Desarrollamos el frontend (lado del cliente) con AngularJS, básicamente es lo que mostramos al usuario en su pantalla. AngularJS hace las llamadas al API REST (Post, Put, Get y Delete) construida con NodeJS y el framework express. Luego este API hace un CRUD (Create, Read, Update y Delete) a la base de datos en MongoDB, que a su vez da la respuesta obteniendo así el API los datos que se le han pedido en la llamada. Estos datos los envía el API a AngularJS (frontend) en formato JSON y se le mostrará al usuario sin necesidad de recargar la página, puesto que AngularJS mantiene los datos actualizados de la base de datos sin necesidad de actualizar la página web.

Y hasta aquí nuestro primer vistazo al Stack MEAN, nos queda un largo pero entretenido camino que recorrer, en la segunda parte de este tutorial instalaremos NodeJS y profundizaremos en los packages.

Listado de tutoriales de “Introducción al Stack MEAN”:

8 Comentarios

  1. Andres 7 septiembre, 2015 Responder
    • amldesign amldesign 7 septiembre, 2015 Responder
  2. Ignacio farre 2 octubre, 2015 Responder
  3. Jorge Calle 23 noviembre, 2015 Responder
  4. condemore 5 marzo, 2016 Responder
  5. Fernando 29 julio, 2016 Responder
  6. SetCain 26 octubre, 2016 Responder
  7. Yoel 15 diciembre, 2016 Responder

Añadir un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *