FWH y Mysql. Los nuevos escenarios...

[Carles]

Holaaa,

En esta tarde de verano, mientras unos estan de conferencia en Sillian, aprovecharé ahora que no nos ven para crear este nuevo hilo (distinto al de dbf/cdx y google-drive) a ver si nos lo pasamos bien.

Entiendo que el tema en http://forums.fivetechsupport.com/viewtopic.php?f=6&t=34270&p=203363#p203141 va a redirigirse hacia el uso de nuestras aplicaciones FWH con bases de datos en internet y como crear un modelo de aplicaciones en este nuevo escenario. No quiero ni pretendo deciros que debeis hacer por supuesto, pero si ofreceros mi “poca experiencia” e intentar a quien le sirva ofrecer un poco de luz sobre este apasionante tema, en la que a veces uno encuentra mucha oscuridad cuando empieza...

de acuerdo en que el tema es MUY apasionante.
Tener MySQL en un servidor en internet es sin dudas una de las mejores formas si se desea tener una aplicacion distribuída, pero tambien hay que considerar que la conexión debe estar al menos encriptada (SSL), porque sino los datos viajan en plano y no sería lo adecuado.

Por supuesto ! . Vamos a ver, yo entiendo los que estamos por aqui cuando realizamos una aplicación deseas las maximas garantias de fiabilidad, consistencia, seguridad...pero a veces observas que queremos todo gratis, gratis,...y encima intentamos reinventar la rueda y crear inventos que nos solucione el tema pero al final lo gratis sale caro. No quiero herir la susceptibilidad de nadie aqui evidentemente, pero si quieres ser un buen profesional del sector has de ofrecer unas mínimas garantias. Por ejemplo, un certificado ssl hoy en dia esta tirado de precio, de hecho renove uno hace un mes de un dominio y me costo 10.95€ !!! (irrisorio...), evidentemente hay de todos los precios pero ya puedes acceder a uno con este precio. Un dominio te puede costar 10€ y sobre el tema de hosting tienes de gratis, pero por poco mas, puedes conseguir otros que te ofrezcan mas alternativas de gestion y p.e. con sistema de backups automatizados diarios, tema muy importante a tener en cuenta en la que mucha gente se piensa que el hecho de tener tus bases de datos, tablas, ... en la nube ya esta todo guardadito... falso.

Es decir a grandes rasgos si tu quieres crear una aplicacion distribuida con los datos en la nube, etc... por poco menos de 70€ puedes tener lo mas esencial: hosting, dominio,certificado ssl., por cierto un hosting en el que puedes ir añadiendo tus bases de datos a medida q necesites mas aplicaciones...

Es bueno explicar esto, porque muchos quizas no saben que hay en el “mas alla” y pueden ir descubriendolo aqui. Solo intento en esta “charla de verano” poder exponer mi experiencia y ayudar a descubrir estos nuevos horizontes... y me gustaria poder compartir con el amigo Carlos y quien se apunte para poder ir dando aporte, ideas y sumar estos conocimientos, que sirva para trabajar cada vez mejor en este nuevo escenario. Y la entrada a este mundo implica la entrada a muchos conceptos nuevos que gusten o no tendras que absorverlos para poder poner en marcha tu aplicacion: hostings, servers, ssls, dominios, paneles de gestion, ... (eso para decir los mas básicos)

Asi pues, tenemos este escenario con la que podemos tener nuestra infraestrucutra técnica.

Y ahora... recordais Matrix ? Que píldora quieres la roja o la azul ?

En mi último post abria el nuevo camino al uso de webservices para el manejo de los datos frente a la conexion directa con la base de datos. Para mi es la forma correcta, pero es un camino mas complicado en el que debemos entrar y que necesita un “poco” mas de conocimiento y aprendizaje, pero que es bueno que conozcamos.

Evidentemente la manera mas rápida y sencilla es conectar directamente nuestra app con la base de datos y listos, en esto creo que todos compartimos la misma idea.

Quizas me desvie un poco del clasico método pero tambien porque ahora estoy inmerso en temas de la web. He tenido que aprender en los ultimos años muchos conceptos nuevos y asumir nuevas metodologias de trabajo y mi vision ahora engloba desde el concepto aplicacion win con cliente/server a aplicaciones web con los datos en diferentes motores de datos hasta app de movil que necesitan acceder a los datos usando los “webservices”.

Es entonces que ahora cuando me hablan de crear una nueva aplicacion o proyecto, mi cabeza genera internamente un diagrama con un centro “base de datos” en la cual se conectaran mis aplicaciones independientemente de la tecnologia usada (web,win,app,...) y es por eso que mi cabeza ya piensa en un formato standarizado que son los webservices que serviran para todos por igual.

Para estos webservices (otro tema muy extenso para otro dia...) es que tecnologia usar.

Hoy en día se imponen los microservicios, y las interfaces apuntan a soluciones REST apoyadas en JSON.

Estoy otra vez de acuerdo con el , y realmente es la tecnologia que tambie uso.

Hasta este punto pues se podria dar estos 2 escenarios...



Para cerrar este post ... podriamos abrir otra pinza que cual de los 2 sistema es mejor o cual usar. Quizas no sea la mejor expresion (mejor/peor) sino que quizas en algun momentos nos va mejor uno o el otro. Expongo ventajas e inconvenientes que veo a un nivel muy general...


FWH+MySql
Ventajas:
- Sistema rapidismo de montar.
- Todo el código de la aplicacion es Harbour y FWH
- Reglas de negocio en la propia aplicacion
- No necesitamos asumir nuevos lenguajes y técnicas especiales.

Desventajas
- Encapsulación en un entorno windows
- Sistema mas cerrado en cuanto al acceso a datos.
- Acceso por rangos de Ips que tendras que saber gestionar correctamente para tema de seguridad.

FWH+WebService+MySql
Ventajas
- Seguridad en acceso a datos
- Sistema abierto a cualquier tecnologia: web, win, app
- Cualquier manipulacion de datos es accesible desde los otros entornos y es el mismo para todos. P.e una consulta de un cliente será igual para todos.
- Escalable a otras bases de datos independientemente del code de FWH
- Abierto a las tecnolgias de internet

Desventajas
- Mas laborioso
- Implica conocer nuevo lenguaje de programacion, p.e. php
- Implica aprender el concepto de instalar los fuentes en el hosting, ejecutarlos, depurarlos,...

Pero como primer paso, partiendo del modelo clásico del xBase, es empezar a profundizar en SQL y sus particularidades a través de las librerías que tenemos disponibles, ya sean las nativas de FW, los contribs de Harbour, Dolphin, Eagle, etc

Siiiii, pero sin dejar de perder el horizonte

Creo que al final es que todos puedan entender las piezas del puzle y luego que cada uno monte el que quiera...

Feliz verano a todos !

[hmpaquito]

Estalló la polémica... y ahí vamos...
Vaya por delante que yo de todo, sé más bien poco, y cómo dicen, no soy técnico, sólo soy el conserje.

Ahora bien, yo no lo plantearía como una disyuntiva SQL ó WS, sino más bien SQL Y WS.
¿ Por qué ? Porque el acceso a SQL lo reservaría para enlazar la app escritorio con la webApp.
El WS sería para dar servicio a aplicaciones foráneas.

Creo que utilizar WS entre nuestras aplicaciones es hacerse trampas al solitario: el conjunto de instrucciones SQL es más amplio que el conjunto de WS que podamos programar.


Mis dos céntimos de euro.

[rubenfernandez01]

Amigos: Un tema apasionante. Sigo con dbf's y aquí comenzaría mi aprendizaje a otro mundo mas profesional . Ojalá se sumen más gurús del tema. Gracias.
Saludos
Ruben Diario Fernandez.

Gracias y saludos cordiales.
Rubén Dario Fernández
Fwh 16.08 - Bcc 7.2 - Synwrite

[jose_murugosa]

Un hilo interesante......

http://xthefull.blogspot.com.uy/2015/09 ... rbour.html

[Carles]

Hola,

No se trata de usar un sistema u otro. Son dos formas distintas de trabajar que si es necesario se pueden complementar.

Creo que utilizar WS entre nuestras aplicaciones es hacerse trampas al solitario: el conjunto de instrucciones SQL es más amplio que el conjunto de WS que podamos programar.

Vamos a ver, un webservice es un proceso, no una sql, cuando diseñas un webservice, imaginaros que este es un mini programa que se encarga de abrir la base de datos de turno, procesar datos (con SQL !), realizar sus calculos de turno y devolver un resultado. Este se diseña con un standard que cualquier otra aplicacion independientemente del lenguaje que usa, pueda acceder a el. Cuando desde nuestra aplicacion conectamos en este caso a una MySql, ejecutamos una SQL y luego si es necesario procesamos la informacion resultante (lógica de negocio). El WS se encarga de todo, es un mini programa...

Imaginemos un perqueño webservice que se dedica a dar informacion de un cliente.

Por ejemplo la llamada puede ser una url al que le pasamos un parametro que podria ser el id -> http://tu_dominio/tu_servicio/1234 . Nosotros no nos preocupamos desde la aplicacion de abrir la base de datos p.e. , ni siquiera sabemos en que tipo de base de datos esta. Ni sabemos como esta hecho el webservice, incluso internamente que realiza... Sabemos que si hacemos este tipo de llamada, nos devolverá una respuesta (esta puede ser en varios formatos, p.e. xml, json...) y nosotros estos datos los procesaremos en nuestra aplicacion.

Este mismo ws, lo podra consumir si realizamos algun dia una mini web que entre otras, pueda consultar a sus clientes, usando el mismo webservice o incluso si realizas una mini app. Como veis el concepto es distinto, es otra manera de trabajar. Pero como dije al principio, tambien esto tiene un coste a nivel programacion, pero que segun que tipo de proyectos querais realizar te ofrece unas ventajas bestiales.

Y el hecho de aprender a usar la manipulacion de ws, nos abre la posibilidad de usar tambien los ws de terceros.

Comenté al inicio que quizas todo esto tiene sentido si pensamos en crear un proyecto que interfase diferentes plataformas (win,web,app), solo me gustaria que vierais las opciones y las posibilidades que tenemos con harbour+FWH de consolidar este tipo de escenarios.

[hmpaquito]

Carles,

Magníficamente bien explicado.
Gracias por iniciar el hilo.
Estos temas de fondo son los que nos ayudan a progresar.

Saludos

PD. ¿ Veremos algún ejemplo de ws ?

[Carlos Mora]

Es que al Carles casi no le he conocido con esa barba hipster! Jaja.

Paquito: Nos hemos acostumbrado al acceso a niveles más bien bajos de la CPU y los datos, el 90% de los que estamos aquí hemos programado para DOS, entonces subir de nivel de abstracción nos resulta un poco extraño, y ni hablar de diseñar la solución.
Afirmando los conceptos de Carles, y relacionado con los microservicios, las ideas más modernas apuntan a abstraer los datos de forma tal que plataformas heterogéneas como son desktop(win/Mac/Linux), móvil (IOS/Android) o WEB tiren todas del mismo origen de datos, independiente de donde lo estés usando. Pensar en que el acceso a los datos puede ser más rápido en términos de accederlos directamente es un planteo en la dirección contraria, porque aunque puede que si bajo ciertas circunstancias, lo cierto es que un microservicio es mucho más fácil de optimizar, acelerar y cachear, y un acceso genérico a tablas puede resultar óptimo dentro de ciertos límites, pero pagando peajes: te clavas a una tecnología, muy dificil de escalar, etc.
Sé que es una manera distinta de pensar, pero estos modelos de servicios tienen muchas ventajas: independizas el código de la forma en que se almacenan los datos, si tienes problemas de velocidad sabes por donde atacar, si creces puedes escalar actualizando el servicio, si implementas una funcionalidad en el servicio esta estará disponible para todas las plataformas.
A nivel de infraestructura, un servicio puede estar en tu ordenador de forma local, en un servidor local, y de ahí puedes moverlo a la nube segun tus necesidades y eventualmente alquilarle a Amazon, Google o Azure un monstruo de 128 procesadores y 256 Gb de RAM y tendrías la escala que mejor te convenga en cada caso.

Si quieres ejemplos de Web Services, la Agencia Tributaria te provee de varios cientos de ejemplos Igual en Argentina, donde la facturacion electrónica es una realidad. Y creo que Mexico tambien tiene un sistema parecido.

[Carles]

Hi

Es que al Carles casi no le he conocido con esa barba hipster! Jaja.

Cito

La cultura hipster es una subcultura de jóvenes bohemios de clase media-alta que se establecen por lo general en barrios que experimentan procesos de gentrificación.

Gracias por lo de joven . En septiembre ya me caen los 50 , un chavalin !!!

Leo y releo tu post y realmente, para nuestra especie que viene casi del "mas allá", de la época del dos, le ha de dar miedo todo si nunca lo ha visto. Con lo tranquilo que estabamos con nuestro Clipper y dbf's...

Intentaré esta semana q estoy de fiesta preparar un pequeño ejemplo... -> (intentare...)

[quim]

Muy interesante el tema y un mundo de servicios por descubrir...

Las aplicaciones se abren al mundo, con webservices o las API financieras (fintech), creo sinceramente que es el futuro de las aplicaciones, su interconexión, el lenguaje de las máquinas.

Desde cualquier aplicacion se pueden consumir servicios que el universo de la red nos pone al alcance, sin ir más lejos, instituciones y empresas abren al mundo información para ser consumida

Por ejemplo, podemos consultar como datos abiertos, los puntos de acceso a la wifi pública entre un catálogo de más de 400 Datasets, solamente en el ayuntamiento de Barcelona
http://opendata-ajuntament.barcelona.cat/data/es/dataset

Por no decir de loas webservices del INE (Estadística) entre muchos otros

Que tal si nuestra aplicacón se prepara para recibir peticiones remotas, ya sea para consultar el stock de nuestros productos o nuestras tarifas y servicios para comparativos ?

Seguiremos este tema ...

Saludos
Joaquim Ferrer

[Carles]

Bones,

Que tal si nuestra aplicacón se prepara para recibir peticiones remotas, ya sea para consultar el stock de nuestros productos o nuestras tarifas y servicios para comparativos ?r

Exacte Quim !!!. Ya no solo queremos que SOLO nuestra aplicación acceda a los datos o parte de ellos. Debemos ser capaces de poder dar acceso a esta información de una manera flexible y estandarizada e independientemente de la tecnologia usada (win/web/app).

[thefull]

Buenas

Las aplicaciones que están en DBF, por herencia y porque es muy complicado su cambio, el uso del WS que nos provee Harbour, abre tus aplicaciones
al mundo exterior , ya sea como XML o como JSON, lo cual permite hacer aplicaciones 'satelites' que nos permiten compartir/obtener datos de terceros,
que nos permite ser competitivos ahí donde antes, si no era algo como ADS, no podíamos enfrentarnos, quedando nuestras aplicaciones en 'fuera de juego'.

Hoy mismo, seguimos con DBF/NTX, pero con un WS de por medio, podemos hacer prácticamente lo que queramos.

¡¡Mare meva com estas de guapo Carles!!
Ven un día por Barna, y montamos una quedada /cena/ merendola y nos tomamos unas birras

[Carlos Mora]

Hi

Es que al Carles casi no le he conocido con esa barba hipster! Jaja.

Cito

La cultura hipster es una subcultura de jóvenes bohemios de clase media-alta que se establecen por lo general en barrios que experimentan procesos de gentrificación.

Gracias por lo de joven . En septiembre ya me caen los 50 , un chavalin !!!

Ahora entiendo! Lo que me confundió era ese aire de niño de familia bien!
No le hagas caso a los 50, muchas espectativas y al final no cambia nada, la vida es un continuo. Da por culo cambiar a veces de casillero en las estadísticas, pero no va más allá. Tu inquietud mental demuestra que tienes neurones muy jóvenes aún.

Tengo un ejemplo que muestra hacia adonde van las apps y como vamos a integrarlas, muy a la fintech. En pocos días me meto con integrar microservicios bancarios a la app de contabilidad (FW+Harbour) con los microservicios de la banca. El primero será el BBVA, del cual me estoy empollando las APIs. El usuario habilita el acceso a la API del banco con su usuario, contraseña, y un token de 6 dígitos que recibe en la app del BBVA en el momento de entrar. A partir de allí puedo consultar los extractos bancarios de todas sus cuentas, lo que me permite hacer la conciliación y/o registro de las cuentas bancarias. Luego veré como se hace con otros bancos, pero seguramente todo va igual.

Este ejemplo del banco representa el 'consumo' de un microservicio. Ahora bien ¿Que tal si nuestra aplicacion de facturación publica las facturas y los vencimientos y cobros para que los clientes los puedan consultar desde su aplicación? No importa como esté hecho tu ERP, tienes que publicar información a la que se accede luego de autenticarte, y usas JSON o XML para la respuesta. Cuando tengas creado ese microservicio, no solo podrás hacer que los clientes puedan integrar su aplicacion con la tuya, sino que además podrías encargarle a alguien que escriba una app web de acceso para los clientes donde pueden consultar la misma informacion, pero en un Portal del Cliente. Y el programador WEB no tiene que conocer donde estan las facturas ni si estan en DBF/NTX o en una BBDD Oracle, le da igual, solo necesita conocer como acceder al microservicio y como le devuelve las respuestas. Además, imaginaros que el ERP, que lo tenias escrito con DBFNTX, ahora lo migras a SQL con TDolphin o Eagle. Solo cambias el microservicio, el resto de las aplicaciones 'clientes' ni se enterará del cambio ni tendra que reprogramar nada.
Y, ojo, esto no es un delirio: me consta que Rafa tiene puñados de cosas como estas usando el webserver de Harbour. ¿Es así Rafa?

Los cambios apuntan a la integración de las aplicaciones, y tenemos que empezar a ver nuestras aplicaciones como servicios integrados, y que esa integracion sea una ventaja competitiva.

[quim]

Perfecta explicación Carlos ...

Y que decir de una vieja aplicacion que a través de un WS puede alimentar artículos o recibir pedidos de un Prestashop, por WS REST a traves de la API que nos provee?

Realmente es otra dimensión

Saludos

[thefull]

Correcto Carlos.

Tengo APIs programadas en Harbour bajo el WS, tanto propias como de terceros, de modo cliente como de servidor, atacan a DBFs como a SQL Server,
ya sea de JSON o XML.

Por eso, tal y como has atrás publicó Jose a un enlace unos post más atrás sobre los WS en Harbour, es solo la punta del Icerberg.

[José Luis Sánchez]

Hola,
Supongo que sería mucho pedir a Carles y demás que teneis experiencia en el tema, pero me gustaría que escribierais algo para Harbour Magazine al respecto independientemente de que lo publiqueis donde os parezca oportuno. Si estais interesados, escribirme a mediumharbourmagARROBAgmailPUNTOcom. Muchas gracias.

Saludos,
José Luis