Desventajas de la plataforma Force.com [cerrado]

Actualmente estamos considerando usar la plataforma Force.com como nuestra plataforma de desarrollo y los vendedores y el sitio web force.com están llenos de razones por las que es la mejor plataforma del mundo. Sin embargo, lo que estoy buscando son algunas desventajas reales de usar una plataforma de este tipo.

Aquí hay 10 para comenzar.

1. Apex es un lenguaje propietario. Aparte del complemento Eclipse de force.com, hay pocas o ninguna herramienta disponible, como refactorización, análisis de código, etc.
2. Apex se modeló en Java 5, que se considera que está rezagado con respecto a otros lenguajes y, sin herramientas (ver el n. ° 1), puede ser bastante engorroso.
3. La implementación sigue siendo bastante manual con muchas trampas y pasos manuales. Esta situación está mejorando lentamente con el tiempo, pero se sentirá decepcionado si está acostumbrado a tener implementaciones automatizadas.
4. Apex carece de paquetes / espacios de nombres. Todas sus clases, interfaces, etc. viven en una carpeta en el servidor. Esto hace que el código esté mucho menos organizado y los nombres de clases / interfaces sean necesariamente largos para evitar conflictos de nombres y proporcionar contexto. Esta es una de mis mayores quejas, y no elegiría libremente construir en force.com solo por esta razón.
5. El "force.com IDE", también conocido como el complemento force.com eclipse, es increíblemente lento. Guardar cualquier archivo, ya sea un archivo de clase, archivo de texto, etc., por lo general toma al menos 5 segundos y, a veces, hasta 30 segundos, dependiendo de cuántos objetos, tipos de datos, archivos de clase, etc. haya en su organización. Guardar también es una acción de bloqueo, que requiere no solo compilación, sino una sincronización completa de su proyecto local con el servidor. Órdenes de magnitud más lento que Java o .NET.
6. La comunidad de desarrolladores online no parece muy sana. He notado que muchas publicaciones en el foro quedan sin respuesta o sin resolver. Creo que esto puede tener algo que ver con el software de foros que usa salesforce.com, que parece ser una mierda.
7. El acceso a datos DSL en Apex deja mucho que desear. Ni siquiera es remotamente competitivo con empresas como (N) Hibernate, JPA, etc.
8. El desarrollo de una aplicación en Apex / VisualForce es un ejercicio de ingeniería de límites reguladores. Fácilmente, la mitad del tiempo del programador se dedica a tratar de optimizar para evitar los numerosos límites reguladores y otras trampas como los límites de estado de vista de Visualforce. Se podría argumentar que si escribe código eficiente para empezar, no tendrá este problema, lo cual es cierto hasta cierto punto. Sin embargo, hay muchas veces que tiene razones válidas para realizar más de x consultas en una sesión, o recorrer más de x registros, etc.
9. El ciclo guardar-> compilar-> ejecutar es extremadamente lento, especialmente. cuando se trata de comprimir y cargar todo el paquete de recursos estáticos solo para hacer algo como probar un cambio menor de CSS o JavaScript.
10. En general, el dolor de una plataforma joven e incipiente sin los beneficios de ser de código abierto. No tiene forma de validar y / o corregir errores en la plataforma. Dicen que lo publiquen en su IdeaExchange. Si buena suerte con eso.

Renuncias / Divulgaciones: Hay muchos beneficios para una plataforma alojada como force.com. Force.com mejora regularmente la plataforma. Hay muchas cosas que me gustan. Gano dinero construyendo con force.com

Veo que ha recibido algunas respuestas, pero me gustaría reiterar cuánto tiempo se pierde eludiendo los diversos límites del gobernador en la plataforma. Por mucho que me guste la plataforma en ciertos niveles, la recomendaría enfáticamente, enfáticamente, como una plataforma de desarrollo de aplicaciones general. Es excelente como una aplicación CRM súper configurable y extensible si eso es lo que desea. Si bien su marketing es excepcional para impulsar la idea de Force.com como una plataforma de desarrollo general, aún no está ni remotamente cerca.

La eficiencia de tener una plataforma estable y evitar grandes problemas de rendimiento y estabilidad se desperdicia fácilmente al tratar de codificar alrededor de los límites a los que se refieren las personas. Hay tantos límites para la plataforma que se vuelve completamente enloquecedor. Estos límites no son límites de alto nivel que alcanzará una vez que tenga muchos usuarios, los alcanzará casi de inmediato.

Si bien generalmente existen técnicas para sortearlos, es muy difícil encontrar estrategias para evitarlos mientras también está tratando de desarrollar la lógica comercial de su aplicación real.

Para darle una idea simple de lo poco amigable que es el entorno para los desarrolladores, tome la "falta de entorno de depuración" mencionada anteriormente. Es peor que eso. Solo puede ver hasta 20 de las solicitudes más recientes al servidor en los registros de depuración. Por lo tanto, mientras desarrolla dentro de la aplicación, debe crear una solicitud de depuración "Nueva", seleccionar su nombre, presionar "Guardar", volver a su aplicación, actualizar la página, hacer clic de nuevo en la pestaña de depuración, intentar encontrar la solicitud que albergará su registro de depuración, presione "buscar" para buscar el texto que está buscando. Son como diez clics para ver una salida de depuración. Si bien puede parecer trivial, es solo un ejemplo de la poca atención y consideración que se le ha dado a la experiencia del desarrollador.

Todo lo relacionado con la plataforma de desarrollo es una ocurrencia tardía. Es notable por lo que es, pero un PITA total en su mayor parte. Si no sabe exactamente lo que está haciendo (ya que está certificado y tiene una comprensión muy íntima de Apex), le llevará fácilmente de 10 a 20 veces más tiempo que en otro entorno para hacerlo. algo que parece ridículamente simple, si es que puedes tener éxito.

Los límites del gobernador son realmente tan malos. Tiene una combinación de varios límites (consultas de base de datos, filas devueltas, "declaraciones de script", llamadas futuras, llamadas, etc.) y debe saber exactamente qué está haciendo para evitarlas. Por ejemplo, si tiene un campo de "fórmula" de resumen calculado en un objeto y tiene un disparador en un objeto secundario, ejecutará los disparadores del objeto principal y los contará en función de sus límites. Cosas como esa no son obvias hasta que has pasado por el doloroso proceso de intentarlo y fallar.

Intentarás una cosa para evitar un límite y golpearás otra en un juego sin fin de "golpear un límite". En el proceso, tendrá que rediseñar drásticamente toda su aplicación y enfoque, así como reescribir todo su código de prueba. Tú debe tener 75% de cobertura de código de prueba para desplegar en la producción, que en realidad es algo muy bueno, pero combinado con todos los otros límites, que es muy oneroso. De hecho, alcanzará los límites del gobernador escribiendo su código de prueba que no aparecería en escenarios de usuario normales, pero que le impedirá lograr la cobertura.

Eso sin mencionar toda una serie de otras cuestiones. El empaque no es lo que esperas. No puede empaquetar su aplicación y entregarla a los usuarios sin una significativa intervención y configuración por parte del administrador de la organización. AppExchange es una broma total, e incluso han comenzado a cobrar 5K solo para que su aplicación aparezca en la lista. Importar con el cargador de datos apesta, especialmente si tiene algún desencadenante. No puede exportar todos sus datos en un paso que incluya sus relaciones de tal manera que se puedan volver a importar fácilmente a otra organización en un solo paso (por ejemplo, una organización de desarrollo). Solo puede actualizar una caja de arena una vez al mes desde la producción, sin excepciones, y no puede incluir sus datos en una actualización de forma predeterminada a menos que haya llamado a su ejecutivo de cuenta para desbloquear esa función. Usted puede' t eliminar datos en masa en objetos personalizados. No puede cambiar los nombres de sus paquetes. Ciertas cosas pueden tomar numerosasdías para completar después de haberlos solicitado, como una copia de seguridad de los datos antes de que desee implementar una aplicación, sin un informe de progreso en el camino y sin mucha idea de cuándo ocurrió exactamente la exportación. Dado que existen problemas de sincronicidad de los datos si existen relaciones entre los datos, existen serios problemas de integridad de los datos, ya que no existe una "transacción" que pueda exportar numerosos objetos en un solo paso. Probablemente existen algunas herramientas comerciales para facilitar algo de esto, pero estas no están al alcance de los desarrolladores normales que pueden no tener un gran presupuesto.

Todo lo demás que las otras personas dijeron aquí es cierto. A veces, puede llevar entre cinco segundos y un minuto guardar un archivo.

No quiero ser tan negativo porque la plataforma es muy buena de alguna manera y están tratando de hacer cosas en un entorno de múltiples inquilinos que nadie más está haciendo. Es un entorno muy innovador y poderoso en algunos niveles (de hecho, me gusta mucho VisualForce), pero dale uno o dos años más. Se están asociando con VMware, tal vez eso les dé a los desarrolladores un poco más de un parque en lugar de una celda para trabajar.

Aquí hay algunas cosas que puedo darte después de pasar un poco de tiempo desarrollando en la plataforma en la última quincena más o menos:

1. No hay una API RESTful. Tienen una API basada en jabón a la que puedes llamar, pero no hay forma de hacer verdaderas llamadas relajantes.

2. No hay una forma sencilla de tomar sus SObjects y convertirlos en objetos JSON.

3. Las páginas de fuerza visual están bien hasta que quieras personalizarlas y luego es un mundo de dolor.

4. Las páginas de fuerza visual deben estar vinculadas a SObjects; de lo contrario, no hay forma de que los campos de entrada estándar como el selector de fechas o la lista de selección funcionen.

5. El complemento eclipse está bien si desea trabajar solo, pero si desea trabajar en un equipo grande con el complemento eclipse, olvídelo. No maneja la sincronización desde y hacia el servidor, falla y no es realmente útil en absoluto.

6. ¡NO HAY DEPURADOR! Si desea depurar, literalmente se depura mediante declaraciones system.debug. Este es probablemente el mayor problema que he encontrado.

7. Su modelo "MVC" no es realmente MVC. Está mucho más cerca de ASP.NET Webforms. Sus vistas están estrechamente vinculadas no solo a los modelos sino también a los controladores.

8. No es posible almacenar una gran cantidad de documentos. Necesitamos almacenar más de 100 GB de documentos y nos citaron una cifra ridícula. Decidimos implementar nuestro almacenamiento de documentos en la infraestructura de Amazon S3

9. Incluso aunque el lenguaje está basado en Java, no es Java. No puede importar ningún paquete o biblioteca externos. Además, las bibliotecas base que están disponibles son muy limitadas, por lo que nos encontramos implementando un montón de cosas externamente y luego exponiendo esos bits como servicios que son llamados por force.com.

10. Puede llamar a servicios externos basados ​​en SOAP o REST, pero el cuerpo del mensaje está limitado a 100 kb, por lo que es muy restrictivo en lo que puede llamar.

Honestamente, si bien hay beneficios potenciales al desarrollar algo como la plataforma force.com, para mí, no podría usar la plataforma force.com para aplicaciones de nivel empresarial verdaderas. En el mejor de los casos, podría escribir algunas aplicaciones básicas de estilo crud, pero una vez que se mueva a algo remotamente complicado, lo evitaría como la plaga.

Vaya, hay muchas cosas aquí que ni siquiera sabía que eran limitaciones, después de trabajar en la plataforma durante algunos años.

Pero solo para agregar algunas otras cosas ...

La razón por la que no tiene un depurador línea por línea es precisamente porque es una plataforma de múltiples inquilinos. Al menos eso es lo que dice SFDC: parece que en esta era de programación rica en subprocesos, eso no es una gran excusa, pero aparentemente esa es la razón. Si tiene que escribir código, tiene "System.debug (String)" como depurador. Recuerdo tener herramientas de depuración de servidor más sofisticadas en Java 1.2 hace unos 12 años.

Otra cosa que realmente odio del sistema es el control de versiones. El marco de Spring no se usa para lo que generalmente se usa Spring; en realidad, es más una herramienta de configuración en SFDC que un control de versiones. SFDC proporciona control de versión CERO.

Puede quedarse atrapado durante días haciendo algo que debería parecer tan ridículamente fácil, como, por ejemplo, programar un informe SFDC para exportarlo a un archivo CSV y enviarlo por correo electrónico a una lista de destinatarios ... Bueno, la forma más fácil de hacerlo es cree un objeto personalizado con un campo personalizado, con una regla de flujo de trabajo y una plantilla de correo electrónico de Visualforce ... y luego, para el código, debe escribir un componente de Visualforce que transmita los datos del informe a la plantilla de correo electrónico de Visualforce como un archivo adjunto y usted escribe APEX anónimo actualización de campo de programación de código del objeto personalizado ... Para los desarrolladores de SFDC, esto es casi una tarea diaria ... tratar de unir cinco tecnologías diferentes para realizar tareas que parecen tan simples ... Y esto puede causar dolores de cabeza en la administración y tensiones también. Por lo general, lo descubrirías después de recibir una sugerencia para hacer algo que noNo trabaje en la comunidad de usuarios (como alguien ya ha dicho) y luego pruebe muchas cosas que, después de desarrollarlas, descubrirá que simplemente no funcionan por alguna razón extraña, como "no puede programar una Página de VisualForce ", o" no puedes llamar a getContent desde un contexto programable "o alguna otra razón misteriosa.

Hay tantos, muchos pequeños problemas enloquecedores en la plataforma SFDC, que una vez que sabes POR QUÉ están ahí, tiene sentido ... pero siguen siendo muy malas limitaciones que te impiden hacer lo que tienes que hacer. Aquí hay algunos míos;

1. No puede obtener la información del propietario del registro "lista para usar" en prácticamente cualquier tipo de registro; debe escribir un activador que vincule al propietario al crear el registro con el registro que está insertando. ¿Por qué? Respuesta corta porque un propietario puede ser una "persona" o una "cola", y las dos son entidades drásticamente diferentes ... Tiene sentido, pero puede poner un proyecto literalmente patas arriba.

2. Modelo de seguridad enloquecedor. Ejemplo: el permiso "Administrar informes públicos" es muy diferente de "Crear y personalizar informes" y eso básicamente se aplica a todo en la plataforma ... especialmente a las carpetas de cualquier tipo.

3. Como se mencionó, el soporte es básicamente inexistente. Si es una persona extremadamente autosuficiente, o tiene muchos recursos de SFDC, o tiene mucho tiempo y / o un gerente muy indulgente, o está a cargo de un sistema de SFDC que funciona bien, está bastante bien forma. Si no se encuentra en ninguna de estas posiciones, puede encontrarse en serios problemas.

SFDC es una propuesta comercial muy seductora ... sin huella de equipo, bastante buena seguridad, precio fijo, sin infraestructura, Y obtienes CRM basado en la web con procesamiento por lotes y programable ... Pero como dijeron los otros carteles, realmente es un gran aumento en el aprendizaje de desarrollo, y si opta por la consultoría, creo que el precio más bajo que he visto fue de $ 200 / hora.

Salesforce tiende a integrarse con otras cosas años después de que algunas tecnologías se conviertan en un lugar común: JSON y jquery vienen a la mente ... y si tiene otras infraestructuras comunes con las que desea hacer una integración, como JIRA, espere pagar mucho más, y pueden tener bastantes errores.

Y como mencionó uno de los otros carteles, estás constantemente luchando contra los límites del gobernador que pueden volverte loco ... un archivo adjunto NO puede ser> 5 MB. Período. Y a veces <3 MB (si está codificado en base64). Diez llamadas HTTP en una clase. Período. Hay docenas de límites de gobernador publicados, y muchos que no lo son, que sin duda encontrará y solo querrá salir corriendo de su oficina gritando.

Realmente, REALMENTE me gusta la plataforma, pero confía en mí, puede ser una amante realmente cruel.

Pero para ser justos con SFDC, diría esto: el mayor problema que encuentro con la plataforma no es la plataforma en sí, sino las gigantescas expectativas que tiene casi cualquiera que ve la plataforma, pero no se ha desarrollado en ella ... y esas personas tienden a ocupar puestos de gran autoridad en las organizaciones empresariales; marketing, ventas, administración, etc. Se producen enormes desconexiones y las cabezas ruedan, o se amenaza con rodar a diario, todo porque existe esta gran plataforma con trampas extrañas y miles de personas que luchan diariamente para entender por qué las cosas deberían funcionar cuando simplemente no lo hacen y no lo harán.

EDITAR:
Solo para agregar a los comentarios de lomaxx sobre el MVC; En la terminología SFDC, esto está estrechamente relacionado con lo que se conoce como "viewstate", y puede tener muchos errores, ya que lo que está en la página VF no es lo que está en la clase de controlador de la página. Entonces, tienes que realizar giros extraños para sincronizar lo que está en la página con lo que el controlador va a escribir en SF cuando haces clic en el botón "guardar" (o haces tu llamada HTTP o lo que sea) ... hombre, es molesto .

Creo que otras personas han cubierto las desventajas con más profundidad, pero para mí, no parece usar el paradigma MVC o apoyar mucho en la forma de reutilización del código. Hacer cualquier cosa más allá de las aplicaciones simples es un ejercicio de frustración en comparación con el desarrollo de una aplicación usando algo como ASP.Net MVC.

Además, las herramientas, la capa de datos y la frustración de intentar refactorizar el código o cambiar el nombre de los campos durante el proceso de desarrollo no ayudan.

Creo que como CMS es bastante bueno, pero como plataforma para aplicaciones que no son CMS, no tiene sentido para mí.

El modelo de seguridad también es muy, muy restrictivo ... pero esta no es la peor parte. Actualmente no puede afirmar si un usuario tiene la capacidad de realizar una acción en particular.

Puede verificar cuál es su función, pero no puede verificar si esa función tiene permisos para realizar la acción actual.

Peor aún es la respuesta del soporte técnico de "probar la acción y, si hay una excepción, captarla".

Teniendo en cuenta que Force.com es una plataforma "en la nube", su capacidad para actuar como cliente de un servicio externo definido por WSDL es bastante decepcionante. Consulte http://force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ para conocer lo que podría terminar teniendo que hacer.

A todo lo anterior, tengo curiosidad por saber cómo el lanzamiento de VMforce, que permite al programador de Java escribir código para Force.com, cambia las desventajas anteriores.

http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071

Supongo que están tratando de abordar estos problemas. En Dreamforce, mencionaron que estamos tratando de reducir los límites del Gobernador a solo 4. No estoy seguro de cuáles son los detalles. Tienen una API REST para acceso anticipado y compraron heroku, que es un desarrollo rubí en la nube. Dividen la base de datos, con database.com para que pueda hacer todo su desarrollo web y sus llamadas a la base de datos utilizando database.com.

Supongo que están tratando de hacerlo lo más agnóstico posible. Pero en este momento, todos estos son anuncios y acceso temprano, por lo que sus declaraciones de puerto seguro no compran en lo que dicen, solo en lo que tienen actualmente.