Nuevo modelo de desarrollo para SharePoint Online vs SharePoint OnPremise
Pregunta: Cuando un desarrollador de SharePoint OnPremise empieza a desarrollar para SharePoint Online, ¿cuáles son las principales dificultades a las que se enfrenta?
Respuesta:
Para todos los que llevamos trabajando durante años con SharePoint OnPremise, la aparición y crecimiento de SharePoint Online ha supuesto un cambio de perspectiva muy importante en todos los aspectos relacionados con el desarrollo de soluciones y la administración del sistema. Aunque el producto pueda parecer el mismo por su nombre y para un usuario o gestor de contenidos pueda parecer que entre una versión y otra solo hay pequeñas diferencias en la apariencia, las diferencias son mucho mayores.
Personalmente la principal dificultad que me encontré es tener que cambiar la visión a la hora de buscar la mejor manera de dar solución a las necesidades que me planteaban los clientes. Es cierto, que el tener que usar código de cliente para desarrollar cuando estamos acostumbrados al código de servidor es una dificultad importante, pero al final es adaptarse a un nuevo lenguaje con todas las peculiaridades que tienen javascript y las diferentes librerías y frameworks que lo rodean. Vamos pasando de ser desarrolladores back-end a front-end, algo que yo por lo menos no hubiese imaginado hace unos años.
Volviendo a las principales dificultades que yo me encontré en este cambio y que todavía me encuentro son todas aquellas tareas que podíamos hacer fácilmente antes en nuestro servidor de SharePoint y que en la versión de Office 365 requieren buscar otras alternativas más complejas, principalmente los event receiver y los timer job.
Los event receiver en SharePoint OnPremise nos permiten manejar eventos síncronos, pudiendo, por ejemplo, ejecutar una acción antes de que se actualice un elemento de una lista pudiendo comparar el valor anterior con el nuevo para realizar unas tareas u otras, incluso pudiendo llegar a cancelar la tarea de actualización. Esto en SharePoint Online desde mi conocimiento es impensable. Lo más cercano que he visto han sido webhooks que nos permiten saber cuándo ocurre algo en una lista, por ejemplo, pero que ya sólo para saber el tipo de cambio que se ha producido nos generan bastante trabajo.
Los timer job en SharePoint OnPremise nos permiten ejecutar una tarea personalizada de una manera programada, pudiendo ejecutarla manualmente también cuando lo deseemos y pudiendo hacer un seguimiento de las ejecuciones. El propio SharePoint realiza tareas de sistema mediante trabajos programados, que en SharePoint OnPremise podemos decidir cuándo ejecutarlos, pero en SharePoint Online debemos asumir el comportamiento definido por Microsoft.
En definitiva, para lo bueno y para lo malo, el desarrollo para SharePoint OnPremise es más flexible que para SharePoint Online, lo que nos obliga a cambiar nuestra perspectiva y darnos cuenta de que ni podemos ni debemos personalizar SharePoint Online igual que hacemos con SharePoint OnPremise.
Pregunta: ¿Cómo podemos facilitar esa transición?
Respuesta:
Como todo cambio creo que lo más importante es esforzarse para aprender y adaptarse al nuevo escenario que nos vayamos a encontrar. Aunque cada día sean más los clientes que disponen de Office365 y que por tanto quieren que sus soluciones sean desarrolladas para SharePoint Online, nos seguiremos encontrando proyectos para SharePoint OnPremise. Mi recomendación personal es en todos estos proyectos, en la medida de lo posible, intentar aplicar la misma lógica que seguiríamos si el proyecto se fuese a implementar en SharePoint Online.
Esto mismo nos lo intenta transmitir Microsoft con el trabajo que está realizando con SharePoint Framework para que nos permita realizar soluciones tanto para SharePoint Online como para SharePoint OnPremise 2016. Al ser soluciones de lado cliente, en líneas generales, entre otras cosas serán mucho más fácil de migrar en caso de requerirse.
Desde el punto vista de puro desarrollo, creo que es básico conocer PnP ya que en muchos casos nos ayudará a realizar ciertas tareas, sobre todo en la parte de aprovisionamiento de sitios. Además, hay gente que recomienda aprender typescript para que el salto entre C# y javascript no sea tan grande, ya que nos permite generar código javascript pero mediante un lenguaje que ofrece tipado y objetos basados en clases que son uno de los conceptos que más nos pueden costar al enfrentarnos a javascript.
Hoy en día, y partiendo de la base que constantemente aparecen frameworks y librerías nuevas, mi recomendación para realizar interfaces en SharePoint Online sería React ya que es una librería que el propio Microsoft está utilizando para desarrollar su producto y que, aunque al principio nos requiera un esfuerzo de aprendizaje, es en su base bastante intuitivo. Nos permite desglosar nuestra aplicación en componentes más sencillos y utilizar una sintaxis en ciertos aspectos muy similar a HTML.
Pregunta: ¿Qué ventajas nos ofrece trabajar con SharePoint Online frente a SharePoint OnPremise?
Respuesta:
Desde mi punto de vista, la principal ventaja para un desarrollador es el que los servidores estén alojados en los sistemas de Microsoft y que sean ellos los encargados de mantenerlo. Esto por supuesto en algunos momentos se convierte también en un problema, ya que nos encontraremos con ciertas limitaciones que no teníamos cuando nosotros teníamos el control sobre el servidor.
Todos los que hemos trabajado con SharePoint OnPremise, sabemos los diferentes problemas que nos pueden surgir al preparar una granja de servidores, además de tener que disponer de los recursos necesarios para que el rendimiento de la aplicación sea el correcto. Todas estas preocupaciones en SharePoint Online las olvidamos, y sólo tendremos que hacer configuraciones a nivel de tenant para algunos servicios cómo pueda ser el buscador, pero sin preocuparnos de lo que haya por debajo.
De la misma manera, no necesitaremos realizar una instalación de SharePoint para montar nuestro entorno de desarrollo con todo lo que ello conlleva, “sólo” necesitamos tener un tenant en el que desplegar nuestras soluciones. En función de cómo vayamos a trabajar (SPFx, SharePoint Hosted Add-in…) necesitaremos realizar más instalaciones o menos y necesitaremos más recursos o menos, pero desde una misma máquina podremos desarrollar para diferentes tenants.
Por último, y esto es más una opinión, creo que las soluciones para SharePoint Online son más “limpias” en el sentido de que, al no tener control sobre el servidor, la carga la hacemos en el navegador del usuario y no en el servidor dónde se aloja la aplicación, por lo que evitamos ciertos riesgos que corríamos en las soluciones de SharePoint OnPremise.
Pregunta: ¿Y qué inconvenientes o limitaciones nos encontramos?
Respuesta:
Ya he hecho referencia anteriormente a varias de las limitaciones que nos encontramos con este nuevo modelo. A parte del aprendizaje que nos requiere la adaptación al nuevo escenario, las principales complicaciones las encontramos en todo aquello que requiere tener acceso al servidor que aloja la plataforma.
Por ejemplo, si yo estoy utilizando el buscador de SharePoint, con SharePoint OnPremise si yo tengo necesidad de lanzar un rastreo de un sitio manualmente lo puedo hacer, en SharePoint Online tenemos que esperar a que la tarea que haya definido Microsoft en el servidor se ejecute, y lo peor de todo es que es algo opaco para nosotros, no sabemos cuándo va a ocurrir exactamente. De la misma manera, si la aplicación da un error inesperado (algo bastante común en SharePoint), no tenemos acceso a los logs del servidor para ver el detalle del problema.
Un ejemplo relacionado con esto es que recientemente hubo un incidente que no permitía instalar y desinstalar apps, lo que nos impidió poder desplegar nuestros desarrollos. Ante estos casos sólo puedes abrir incidencia y esperar a que el equipo correspondiente de Microsoft lo solucione.
Pregunta: Para concluir, ¿qué valoración haces del nuevo modelo de desarrollo para SharePoint Online?
Respuesta:
Personalmente y pese a que este cambio nos haya obligado en cierto modo a “reciclarnos”, creo que en líneas generales es bastante positivo. Pienso que Microsoft ha dado durante los últimos años varios bandazos con los modelos de desarrollo, pero este aparentemente lo veo más estable. Ver que el propio equipo de producto utiliza SPFx y React para desarrollar, da bastantes pistas de que vamos por el buen camino.
Por supuesto creo que hay varios puntos que tendrán que ir perfeccionando. Con SPFx hace unos meses que no trabajo y quizás ya se haya mejorado pero que la creación de un proyecto en blanco no se pueda hacer mediante Visual Studio, y que al generarlo con Yeoman tarde varios minutos y cree un proyecto vacío que ocupa más de 200MB, creo que son puntos que se podrían mejorar. De la misma manera sería bueno que los desarrollos realizados con SPFx se puedan incluir en páginas clásicas de SharePoint además de las modernas, esto sé que estaba en el roadmap pero desconozco si ya se liberó.
En definitiva, creo que con SPFx, React, PnP, Office UI Fabric, Office Graph… podemos hacer soluciones profesionales muy atractivas visualmente y adaptadas a las necesidades de los clientes. Luego está Azure, un gigante de mil patas al que tendremos que acudir para otras necesidades, y del que a mí me queda mucho por aprender… ?
Javier Ordóñez
Analista Programador Senior