DataSnap o LAMP

[[Chris]]

Compañeros, me encuentro en un dilema ahora. No sé que camino tomar. Quiero REdesarrollar una aplicación desde cero (me encanta reinventar la rueda ). La aplicación que existe ahora es cliente-servidor con Firebird. Tiene sus defectos por la arquitectura y además cuando la hacía no tenía mucha experiencia en cliente-servidor ni Delphi.

Por esa razón, quiero enmendar los problemas que esa pobre aplicación tiene volviéndola a hacer desde cero. Con su mejoras y funciones nuevas claro! Pero no me decido que arquitectura usar: DataSnap con o sin Intraweb, Cliente-Servidor o simplemente usar LAMP.

Realmente más prefiero hacerla en LAMP (usando Django y PostgreSQL), sinceramente porque me gusta sentir que tengo todo bajo control y puedo incidir fácilmente sobre cada parte de la aplicación y su GUI. Lo que me detiene a hacerla de este modo es tener que empezar a lidiar con JavaScript, CSS y HTML.

Hacerla con DataSnap o cliente-servidor me evitaría tener que aprender un nuevo lenguage, usar mucho del conocimiento ya adquirido en Delphi. Sin embargo, la aplicación heredaría inconvenientes que no los quiero, como no ser multiplataforma por ejemplo. En este sentido, vi que para el cliente se puede usar Intraweb, pero aún así el servidor estaría esclavizado a funcionar en Windows Server.

En sintesis, estos son los pro y los contra que tengo:
LAMP
Pros:

• Multiplataforma (Cliente y Servidor)
• GUI más rica y fácil de hacer gracias a HTML, CSS, Javascript
• Facilmente puede ser accedida desde cualquier parte
• Las estaciones de trabajo no tienen que configurar nada
• Se puede tener acceso desde dispositivos móviles
• Todos los beneficios de la nueve (esto es relativo)

Contras:

• La combinación de HTML, CSS y Javascript es poco productiva comparada con Delphi.
• No se tiene acceso a los recursos del sistema (mi aplicación necesita imprimir y a clientes de correo como Outlook o Thunderbird)
• Hacer una buena GUI me requerirá de un trabajo enorme de ensallo y error.

.

Por el lado de DataSnap
Pros:

• Puedo reutilizar código y conocimiento ya adquirido.
• La creación de la interfaz cliente es más fácil.
• Acceso a los recursos locales (impresoras, clientes de correo y Word por medio de COM)

contras

• No hay mucho control sobre la GUI si utilizo Intraweb
• Pegado en una sola plataforma
• La movilidad del usuario se ve afectada (se necesita disponer del cliente para entrar al sistema)
• Hay que recurrir a la API de Windows para enriquecer la GUI
• Si se quiere en dispositivos móviles, hay que desarrollar el cliente (aunque esto también puede ser necesario en LAMP)

Bueno, esos son los puntos que he considerado, aunque creo que alguno se me escapa.

Realmente espero que me puedan brindar sus opiniones. Yo las consideraré y agradeceré. Quiero ya decidirme porque espero empezar el desarrollo en la próxima semana.

De antemano, muchas gracias

[mcs]

Hola,

La verdad es que este es un dilema que yo también tengo. Debo actualizar una aplicación de escritorio, cliente/servidor. El servidor es un MySQL que está en un server de Internet, y la aplicación está escrita en Java, y todavía no sé por dónde tirar.

En principio quería ir a lo fácil: Delphi + Firebird. Peeeero lo más fácil no es siempre lo más eficiente. Por un lado hay el inconveniente del "lag" en la comunicación aplicación <--> base de datos, y por otra parte hay el detalle de las actualizaciones.

Si se convierte la aplicación a web, todos estos problemas se solucionan (incluso otro que tengo, de ajuntar una web Joomla con datos de esta aplicación). Las actualizaciones, pues nada más simple: se actualiza en el servidor, y el cliente ya lo tiene automáticamente, sin enterarse. Y el lag entre cliente y bbdd tambien desaparece, al correr todo en la misma máquina.

Cual es, entonces, el auténtico problema? En mi caso, el cambio de filosofía de pasar a desarrollar web. Hasta ahora he programado cosas muy simples para página web (un pequeño "cms", algunas modificaciones a paquetes cómo Prestashop, etc). Pero el salto a toda una aplicación web entera es complicado...

Realmente, no creo que haya ninguna respuesta "buena". Todo son ventajas e inconvenientes, por una parte y por la otra...

Saludos,

Marc

P.D.: El tema imprimir es muy simple: generas un PDF y el usuario pulsa el botón "Imprimir".

[[Chris]]

Gracias mcs por tu opinión. También creo que el tema de las actualizaciones es uno de los puntos a favor que tendría hacerla en Web. Además comparto ese, lo que creo es, miedo natural al cambio. Pero no me gusta sentirme así, soy un desarrollador aún muy joven y no puedo estarme permitiendo negarme al cambio. Aún así, creo que me encantaría la experiencia que adquiriría, pero lamentablemente no sólo depende de mí, sé que tendré la presión encima y no sabía si mis jefes soportarán ir al paso de un inexperto como yo. Tomándome mi tiendo haría un clon de Facebook, pero no sólo depende de mí. No es que no me guste que me presionen, pero si lo llegan a ser, me sentiría impotente de hacer algo más rápido por mi falta de experiencia en este tipo de desarrollo.

Empezado por mcs

P.D.: El tema imprimir es muy simple: generas un PDF y el usuario pulsa el botón "Imprimir".

"He allí el detalle" cómo decía Cantinflas. Incurriría en desarrollo extra convertir todos los documentos creados. Pero bueno, tengo que barajar las posibilidades.

[D-MO]

Bueno Chris, en lo personal me inclinaría por la versión con Django, el framework "para perfeccioniscas con tiempo límite"

Haciendo un comparativo de los pros y contras que le ves a ambas soluciones es fácil darnos cuenta que los contras del ambiente web (que no sería LAMP) con Django no son nada comparados con los pros.

La combinación de HTML, CSS y Javascript es poco productiva comparada con Delphi.

Aquí estás en lo cierto, con Delphi diseñas una pantalla muy rápido, sin embargo, html te dá mucha flexibilidad. Para empezar podrías utilizar algún editor para crear los prototipos de pantallas, como dreamweaver en win (aunque para código mas limpio yo, en lo personal, prefiero hacerlo en un editor de texto plano), y utilizas un framework css que te facilite esta tarea, fluid960gs sería mi recomendación, pero hay muchos otros bastante buenos.

No se tiene acceso a los recursos del sistema (mi aplicación necesita imprimir y a clientes de correo como Outlook o Thunderbird)

Acá no entiendo muy bién el problema, si quieres imprimir puedes generar reportes en pdf y que los imprima el cliente, ¿cual es el problema?... para Django/Python reportlab te ayuda en eso.

Lo segundo en esta sentencia no lo he entendido.

Hacer una buena GUI me requerirá de un trabajo enorme de ensallo y error.

Volvemos al primer punto. Diseña tus pantallas con un editor que te genere el (x)Html y luego los editas para incluir las variables que envíes desde las vistas de django hacia las plantillas. Además, esto podrías subcontratarlo si tu empresa lo quisiera para agilizar el desarrollo.

Por último, arriba te escribí que no sería LAMP en esta situación, te lo explico:

LAMP es el acrónimo de Linux + Apache + MySQL + PHP, y aunque al final PHP lo reemplazas por Python, la parte de MySQL la reemplazas por PostgreSQL, entonces ya no sería LAMP

[roman]

Una pregunta: ¿por que cambiar de Firebird a Postgre? Si tu aplicación es tipo web también puedes usar Firebird ¿no?

Otra cosa sin importancia: creo que el término LAMP no es el más adecuado pues se refiere a Linux, Apache, MySQL, PHP.

Edito: Se me adelantó D-MO con lo de LAMP

// Saludos

[D-MO]

Empezado por roman

Una pregunta: ¿por que cambiar de Firebird a Postgre? Si tu aplicación es tipo web también puedes usar Firebird ¿no?

Obvié esta parte en mi post anterior, Django también tiene soporte para Firebird de manera extraoficial, con la biblioteca django-firebird


Saludos.

[[Chris]]

Muchas Gracias por tus observaciones D-MO

Lo de LAMP, pues decidí usar el termino por simpliciad, ya que muchos después podría ser que no entiendan de sus variaciones. Me entiendes?

No se tiene acceso a los recursos del sistema (mi aplicación necesita imprimir y a clientes de correo como Outlook o Thunderbird)

Aquí he redactado mal. Me refería a que no tendría acceso directo a las impresoras y también acceso a los clientes de correo por medio de MAPI a cómo lo he venido haciendo ahora. Por ejemplo, lo que hago es presentar una ventana de redacción de correo ya rellenada con el asunto, contenido e incluso adjuntos. Esta funcionalidad no la podría reproducir en la Web porque las API Web no están tan avanzadas, eso creo.

Por otro lado, cuando trabajo con HTML y CSS suelo utilizar poco los editores visuales. Soy programador y me gusta trabajar a nivel de código. Además que tengo hasta el más mínimo control sobre lo producido. Es por eso que te digo que hacer una interfaz rica (así como Facebook) requiere de bastante código en HTML, CSS y ni mencionar Javascript, que en ése sí que estoy "crudo".

Pero aún así estoy abierto a probar editores que me ayuden en el trabajo. Siempre y cuanto me hagan sentir en control.

[D-MO]

Empezado por roman

...Se me adelantó D-MO con lo de LAMP

Por apenas unos segundos...

Y hablando de lo mismo, la parte de la "P" podría referirse a Perl, PHP, Python y cualquier otro lenguaje que empiece por p, lo que si no encaja acá es la "M" que si es exclusiva de MySQL.

Saludos

[[Chris]]

Empezado por roman

Una pregunta: ¿por que cambiar de Firebird a Postgre? Si tu aplicación es tipo web también puedes usar Firebird ¿no?

A cómo ha dicho D-MO, si puedes usar Firebird. Lo que pasa es que no es oficial hasta dónde entiendo y no me quiero llevar "sorprecitas" después. Ustedes talvez me entenderán.

Además quiero usar un motor algo más "popular", en caso de tener que mover el servidor o alquilar uno virtual o compartido al final -lo más probable sería compartido porque aquí son tacaños-. En ese sentido, nuestro apreciado Firebird aún no es ofrecido por muchos vendedores de servicios en la nube. Además, de Postgre me gusta lo de crear procedimientos almacenados en lenguajes de alto nivel.

[[Chris]]

Empezado por D-MO

... podrías subcontratarlo si tu empresa lo quisiera para agilizar el desarrollo.

Eso, DESCARTADO!

[roman]

Empezado por Chris

Aquí he redactado mal. Me refería a que no tendría acceso directo a las impresoras y también acceso a los clientes de correo por medio de MAPI a cómo lo he venido haciendo ahora. Por ejemplo, lo que hago es presentar una ventana de redacción de correo ya rellenada con el asunto, contenido e incluso adjuntos. Esta funcionalidad no la podría reproducir en la Web porque las API Web no están tan avanzadas, eso creo.

Pero, para qué quieres mandar un correo a través de un cliente como Thunderbird o Outlook si puedes mandarlo directamente desde tu aplicación? Y esto aplica tanto para una aplicación web como para una de escritorio.

// Saludos

[D-MO]

Empezado por Chris

Aquí he redactado mal. Me refería a que no tendría acceso directo a las impresoras y también acceso a los clientes de correo por medio de MAPI a cómo lo he venido haciendo ahora. Por ejemplo, lo que hago es presentar una ventana de redacción de correo ya rellenada con el asunto, contenido e incluso adjuntos. Esta funcionalidad no la podría reproducir en la Web porque las API Web no están tan avanzadas, eso creo.

Acá el problema no es que las "bibliotecas WEB" no estén tan desarrolladas para acceder a la agenda del cliente de correo, sino que por razones de seguridad ninguna aplicación web debe acceder a tu equipo sin autorización. Remarco la parte de sin autorización porque podría decirse que (estoy imaginandome un caso) puedas desarrollar un plugin para el navegador que haga de "puente" entre el cliente de correo y la web cada ves que encuentre una cabecera en el html , nunca lo he hecho, solo se me ocurre que así podría hacerse.

Otra posibilidad sería que la agenda de clientes esté almacenada en un servidor, no en los clientes de correo. Una, de muchas soluciones de este tipo sería utilizar un servidor LDAP y configurar todos los clientes para que utilicen este como repositorio de contactos y a la vez a Django para que lea estos datos cada vez que lo necesite.

Acá hay un poco de la sincronización de los clientes de correo con el LDAP: http://www.sudleyplace.com/LDAP/index.en.html

Empezado por Chris

Por otro lado, cuando trabajo con HTML y CSS suelo utilizar poco los editores visuales. Soy programador y me gusta trabajar a nivel de código. Además que tengo hasta el más mínimo control sobre lo producido. Es por eso que te digo que hacer una interfaz rica (así como Facebook) requiere de bastante código en HTML, CSS y ni mencionar Javascript, que en ése sí que estoy "crudo".

Concuerdo en esto, yo también prefiero la edición en texto plano . Prueba con un framework CSS, como el que cite arriba, fuild960gs, 960gs, blueprint, y una lista larga de sitios que hablan al respecto. Te darás cuenta de la facilidad con que terminarás desarrollando/diseñando interfaces web.

Saludos.

[[Chris]]

Empezado por roman

Pero, para qué quieres mandar un correo a través de un cliente como Thunderbird o Outlook si puedes mandarlo directamente desde tu aplicación? Y esto aplica tanto para una aplicación web como para una de escritorio.

Lo que pasa es que se necesita tener la posibilidad de que el usuario revise y haga modificaciones al correo generado. Adjunte nuevos archivos o modifique el contenido del mensaje. :-/

[D-MO]

Empezado por Chris

Eso, DESCARTADO!

... Y yo que esperaba el trabajo

Saludos.

[roman]

Empezado por Chris

Eso, DESCARTADO!

No veo porqué del enojo. Puedo entender que no exista la opción pero negarse sólo por querer tomar el control total no me parece una buena razón.

Gran parte de las aplicaciones WEB requieren de un diseñador profesional. Dudo mucho, por ejemplo, que Facebook esté diseñado por un programador.

// Saludos

[roman]

Empezado por Chris

Lo que pasa es que se necesita tener la posibilidad de que el usuario revise y haga modificaciones al correo generado. Adjunte nuevos archivos o modifique el contenido del mensaje. :-/

¿Y? Todo esto lo puedes hacer, con aplicaciones web o de escritorio. No entiendo.

// Saludos

[[Chris]]

Empezado por D-MO

Acá el problema no es que las "bibliotecas WEB" no estén tan desarrolladas para acceder a la agenda del cliente de correo, sino que por razones de seguridad ninguna aplicación web debe acceder a tu equipo sin autorización. Remarco la parte de sin autorización porque podría decirse que (estoy imaginandome un caso) puedas desarrollar un plugin para el navegador que haga de "puente" entre el cliente de correo y la web cada ves que encuentre una cabecera en el html , nunca lo he hecho, solo se me ocurre que así podría hacerse.

En realidad me refería a una aplicación Web accediendo a otra aplicación web por medio de una API, a cómo accedes a datos de Facebook, Twitter o Google. Además necesito más que simplemente acceder a una lista de contactos. Necesito poder hacer un correo y permitirle al usuario hacer una revisión final a éste. Es como si yo desde mi aplicación pudiera redirigir al usuario a una ventana de redacción de GMail previamente auto rellenada con datos proporcionados por mi aplicación.

Pero me gusta e interesa esa idea de la PlugIn que me has mencionado. :-/

Bueno, al final creo que podría prescindir de esta funcionalidad y mandar a todos a hacerlo a la antigua, que redacten sus correos manualmente a cómo lo hacían hasta hace unos años.

[[Chris]]

Empezado por roman

No veo porqué del enojo. Puedo entender que no exista la opción pero negarse sólo por querer tomar el control total no me parece una buena razón.

Gran parte de las aplicaciones WEB requieren de un diseñador profesional. Dudo mucho, por ejemplo, que Facebook esté diseñado por un programador.

// Saludos

Es que no es por mí Roman, es porque sé que mis jefes lo descartarán. Ni se los propondría de hecho.

[[Al González]]

Hola Chris.

Dada tu situación y experiencia con Delphi, mi consejo en cuanto a las interfaces de usuario sería que hagas en Web lo que estrictamente hablando deba poder usarse desde cualquier computadora con navegador y conexión a Internet. El resto, mientras no haya reparos para usar Windows, en Delphi. Es un error común creer que toda la interfaz de usuario debe estar en una misma plataforma.

En cuanto a las capas en la parte Delphi, si no hay una necesidad real de contar con un servidor de aplicaciones, entonces usa tres capas "lógicas": en un módulo de datos los componentes de acceso directo a la base de datos (recomiendo dbExpress) y sus proveedores, y en otro los objetos TClientDataSet; y las clases debidamente separadas en unidades .pas de lógica de negocios por una parte, y en otras unidades las clases, rutinas y manejadores de eventos que tienen que ver directamente con la interfaz de usuario. Todo compilado como una sola aplicación.

Pero cuando sea inminente el establecimiento de tres capas físicas, divides tu aplicación Delphi en dos partes: tomando por un lado los elementos que son necesarios para compilar un servidor de aplicaciones y por otro lado lo que corresponde a la interfaz de usuario. Y agregas entonces los elementos DataSnap adicionales para lograr la comunicación entre las dos aplicaciones.

Lo que no tengo claro del todo, y con este comentario me uno a tus inquietudes esperando alguna orientación de quienes ya lo han logrado, es cómo hacer que una interfaz de usuario Web tenga franca comunicación y aprovechamiento de un servidor de aplicaciones Win32 creado en Delphi. Es decir, que el servidor de aplicaciones (capa intermedia) sirva tanto a interfaces de usuario Windows, como a interfaces de usuario Web. ¿Han visto algún material por ahí que lo explique con claridad?

Saludos.

Al González.

[D-MO]

Empezado por Chris

Bueno, al final creo que podría prescindir de esta funcionalidad y mandar a todos a hacerlo a la antigua, que redacten sus correos manualmente a cómo lo hacían hasta hace unos años.

¿Porqué prescindir si puede estar integrada en la aplicación?, te planteaba el caso porque pensé que era de si o si trabajar con el cliente de correo, pero si este no es el caso, concuerdo con Román, integrar toda la funcionalidad en la aplicación, deríamos que creas un pequeño CRM que almacena información de los usuarios y puedas enviarle un correo, con una plantilla predefinida le muestras al usuario un "textarea" con este texto para que modifique o lo deje así y pueda cargar archivos para enviarle. Esto es mucho mas fácil que integrarlo con el LDAP o el Plugin para el navegador.

Saludos.