Hace unos meses escribí un completo tutorial sobre cómo utilizarlo
el SDK Java de Couchbase para crear una aplicación en torno a los datos de muestra de Couchbase 4.0. Sin embargo, nunca expliqué el proceso de pensamiento
detrás del desarrollo de una aplicación de este tipo o por qué el SDK Java de Couchbase es tan conveniente.
Con este artículo pretendo recorrer el proceso de reflexión que hay detrás del diseño de una aplicación y luego
cómo podrías desarrollarlo con Java y Couchbase. Por supuesto que no será tan exhaustivo como mi tutorial, pero verlos
juntos te pondrán definitivamente en el buen camino.
Crear un proceso de diseño
Supongamos que quieres crear la próxima gran aplicación de reservas de viajes. Tienes una gran idea,
pero no está seguro de qué tipo de proceso seguir para ejecutar la idea. Probablemente sea una buena idea
dividir la idea en partes.
Lo más probable es que su solicitud de reserva de viajes contenga las tres partes siguientes:
- Una capa API backend
- Una capa de interfaz de usuario orientada al cliente
- Una capa de datos
Hablemos un poco más de cada capa.
La capa de datos
Una base de datos, en este caso Couchbase, actuará como capa de datos de tu aplicación. ¿Por qué elegimos
para utilizar Couchbase como nuestra base de datos NoSQL, o para el caso, nuestra base de datos en general? Voy a cepillar en esto pronto,
pero en resumen, estamos usando NoSQL porque nuestra aplicación será RESTful y servirá datos JSON. Estamos utilizando
Couchbase porque queremos la libertad de utilizar consultas SQL u operaciones clave-valor (k-v).
¿SQL y valores clave en NoSQL?
Con las bases de datos de documentos NoSQL, cada uno de tus documentos tiene una clave de búsqueda o id. Al introducir la clave en el campo
se obtiene un valor o, en nuestro caso, datos JSON. Si eres nuevo en bases de datos este concepto puede no ser demasiado
difícil de entender, pero si usted viene de una base de datos como Oracle o MySQL podría sonar como puro
locura.
En los sistemas de gestión de bases de datos relacionales (RDBMS) como Oracle o SQL Server si desea obtener datos del
puede ejecutar consultas SQL.
Con Couchbase 4.0, ahora tienes lo que se llama N1QL que te permite ejecutar consultas SQL contra tu NoSQL
con la opción de utilizar también búsquedas de clave-valor. Lo mejor de ambos mundos al ser
de elegir por ti mismo.
Algunos ejemplos de documentos
Dado que se trata de una aplicación de reservas de viajes, es probable que trabaje con compañías aéreas.
e información sobre aeropuertos. Por supuesto, probablemente tendrá mucha más información, pero
para el caso de este artículo, en realidad no importa.
Basándonos en lo que sabemos que necesitamos conseguir, los documentos NoSQL para nuestros datos pueden tener un aspecto parecido a
esto:
Aeropuertos
|
1 2 3 4 5 6 7 |
{ "tipo": "aeropuerto", "nombre": "San Francisco Internacional", "tag": "OFS" } |
Líneas aéreas
|
1 2 3 4 5 6 |
{ "tipo": "aerolínea", "nombre": "United Airlines" } |
Cada uno de esos documentos JSON contendrá probablemente mucha otra información en realidad, pero el documento reducido
las versiones anteriores deberían estar bien.
Ahora deberíamos tener suficiente información sobre nuestra capa de datos para empezar a aprender sobre la capa de backend.
La capa API backend
El objetivo del backend es servir de puente entre los datos y la interfaz de usuario que cada usuario utiliza.
que utiliza tu aplicación ve en su pantalla. En este caso, el backend sería Java.
La capa Java realizará peticiones a la base de datos, formateará las respuestas y las devolverá.
al usuario final para su visualización. El usuario final que realice las peticiones a la capa Java lo hará a través de endpoints
en el backend. Piense en un punto final como una URL diferente en su aplicación, cada una respondiendo con
datos diferentes.
La capa de interfaz de usuario orientada al cliente
El objetivo de la capa de interfaz de usuario orientada al cliente es ofrecer al usuario final algo agradable con lo que trabajar en lugar de
que procesar código en bruto. Alguien que visita un sitio web de viajes como Expedia puede no tener ningún desarrollador
experiencia en absoluto. La capa de front-end consistirá normalmente en un lenguaje como AngularJS, ReactJS o
jQuery.
Desarrollo de la aplicación
Sabemos que nuestro proceso de desarrollo se va a dividir en partes. Principalmente, un front-end y un
back-end. En lugar de construir la aplicación completa desde cero vamos a hablar de lo que es
necesarios para cumplir cada parte.
Servir una API RESTful
Java no puede aceptar ni responder a peticiones HTTP. Hay muchas opciones
para lograr esto, pero una opción podría ser utilizar Spring Boot porque puede obtener rápidamente una API
funcionando. Con Spring Boot, puede crear puntos finales de API con este aspecto:
|
1 2 3 4 5 6 7 |
@RequestMapping(valor="/línea aérea", método= RequestMethod.GET) público Objeto inicio de sesión(@RequestParam Cadena airlineid) { // Procesar la solicitud // Devolver una respuesta } |
Si el usuario pulsa www.yourapp.com/airline en su navegador o aplicación front-end, el
airlineid será procesado con alguna lógica que usted defina y luego alguna respuesta
se devuelven los datos. La lógica que defina puede implicar la consulta de datos.
Consulta de datos
Digamos que tienes unos cuantos de cada tipo de documento en tu base de datos Couchbase. Por cada tipo de documento me refiero a
aeropuerto y aerolínea. Ahora digamos que su back-end Java recibió un
desde el front-end para obtener información sobre el Estados Unidos avión. Tenemos dos
opciones para obtener esta información:
Obtener una línea aérea con K-V Lookup
A continuación suponemos que cada documento de línea aérea lleva como prefijo el nombre de la clave aerolínea:: y
que el airlineid desde el front-end.
|
1 2 3 4 |
JsonDocument doc = cubo.consiga("aerolínea::" + airlineid); JsonObject responseContent = JsonObject.crear().poner("datos", doc.contenido()); |
Hacemos una búsqueda basada en esa clave compuesta y creamos un JsonObject a partir del resultado. En este punto
podemos crear algo de código Java para devolver el resultado al front-end.
Conseguir una línea aérea con N1QL
Al igual que en la búsqueda k-v, suponemos que las claves de los documentos son compuestas y llevan el prefijo
aerolínea::. También estamos asumiendo que el id de la clave se pasa desde el front-end.
|
1 2 3 |
Resultado de la consulta resultado = cubo.consulta("SELECT * FROM `" + cubo.nombre() + "AS a WHERE META(a).ID = 'aerolínea::" + airlineid + "'"); |
Arriba hay una consulta N1QL que es muy similar a la que encontrarías con SQL. Ambas opciones son válidas para
obtener información sobre la compañía aérea. Sin embargo, en escenarios en los que se consultan datos de diferentes
tipos de documentos (tal vez una unión), puede ser más beneficioso utilizar N1QL en lugar de búsquedas. Las razones
ser:
- Couchbase Server hace todo el trabajo pesado en lugar del back-end
- Menos código en su back-end
Para terminar
Ya ha adquirido una idea de lo que se necesita para servir puntos finales HTTP en Java y de cómo consultar datos mediante
el back-end Java, pero ¿dónde nos deja eso ahora?
Sólo tiene que añadir más endpoints a su API Java, cada uno de los cuales realizará diferentes consultas o
contra Couchbase.
Conclusión
Cuando diseñas una aplicación web vas a tener varias capas que juegan juntas. Couchbase es siempre
una buena elección porque es una base de datos de documentos JSON, lo que facilita la creación de API. El Couchbase Java
SDK es genial porque te deja un montón de opciones sencillas para consultar datos.
Aunque no se trata de un artículo exhaustivo sobre la creación de una aplicación de principio a fin, recomiendo
el tutorial que escribí sobre crear un viaje
aplicación.
