Una vez  hemos empezado a entender cuál es el contenido que tiene este framework o, mejor dicho, esta nueva forma de desarrollar sobre SharePoint, empiezan a surgir las preguntas:  ¿Es compatible con todos los frameworks JS: ReactJS, Angular, Knockout, etc… ? ¿Dónde alojo nuestros desarrollos: en una librería de SharePoint o en un CDN? ¿Es compatible con PNP u otros proyectos Open Source?

En este artículo vamos a intentar resolver todas estas preguntas.

Para empezar, en mi opinión el nombre de la herramienta no es el más acertado.Utilizar Framework da pie a confusión.

Creo que no han querido plasmar que es una nueva forma de desarrollar sobre SharePoint  (actualmente solo válida para la versión Online). El SharePoint Framework es una serie de herramientas que nos facilitan la vida para personalizar SharePoint sin la necesidad de utilizar Farm Solution en las granjas. Con lo que por primera vez podemos tener un desarrollo compatible tanto en el Cloud como en On premise.  Partiendo de esta base, la única forma de hacer un desarrollo sin utilizar código de servidor es utilizando JavaScript.

Ahora bien, para esta nueva forma de desarrollar, el principal objetivo que se marco el equipo de SharePoint  fue que no tuviera dependencia de ningún FrameWork JavaScript, es decir, que cada desarrollador pudiera utilizar el que el quisiera, si bien existe una corriente que indica que debemos utilizar ReactJS.

1. En primer lugar porque el propio equipo de Microsoft ha mostrado la arquitectura con la que han implementado Delve y está implementada con ReactJS.
2. En segundo lugar, porque el propio FrameWork lo han implementado con ReactJS.
3. Y tercero, que una herramienta como Office UI parece que solo se va a poder utilizar con este Framework.

¿Qué Framework utilizar?

Esta pregunta, tiene la misma respuesta que cuando estamos utilizando JavaScript dentro de SharePoint. Depende de en qué consista nuestro desarrollo.

Si queremos implementar un Widget, nos decantaremos por un Framework más ligero como ReactJS, KnockoutJS. Incluso es posible que no necesitemos ningún Framework ya que con las capacidades que tiene JavaScript, tendríamos más que suficiente.

En el caso de que queremos montar una Single Page Application (SPA), podemos decantarnos por frameworks más complejos como AngularJS 1 o 2, Backbone, etc…

¿Dónde ubicar los ficheros JavaScript?

Una de las mayores críticas que se le ha echo a SharePoint es que la carga de los ficheros JavaScript era demasiado lenta comparada con una aplicación Web. El motivo está claro: para acceder a una biblioteca de SharePoint hay que autenticarse, y este proceso tarda un tiempo (lo que constituye la principal diferencia respecto a estas aplicaciones).

Ahora bien,  en el momento que generamos el paquete .sapp en el nuevo Framework, no se incluyen estos ficheros JavaScript, sino que deja su ubicación  a elección del desarrollador.

Si miráis la documentación del FrameWork, en los ejemplos, cuando desplegamos la aplicación en un entorno, obliga a tener nuestro servidor local arrancado para que pueda servir estos ficheros. Naturalmente, ésta no es una opción para poner nuestro desarrollo en un entorno productivo.  La opción que nos recomiendan desde el equipo de producto es ubicar nuestros ficheros en un CDN de Azure y que nuestra aplicación los consuma directamente desde allí.

¿Qué es un Content Delivery Network (CDN)? 

Si lo traducimos del inglés, es una red de entrega de contenido, es decir, en algún sitio de Azure disponemos de un sitio donde almacenamos nuestros ficheros y éstos se sirven de una forma muy rápida una vez lo solicitan las aplicaciones que  los necesitan.

¿Cuál es el problema de los CDN?

El principal problema de los CDN es la seguridad. Para que los podamos consumir desde un SharePoint Online, éstos deben estar en modo público, con lo cual es posible que nuestros códigos puedan caer en manos no adecuadas. En la mayoría de los casos, el obtener dicho código puede que no aporte valor a terceros, ya que para acceder a los contenidos es necesario que estén en el propio entorno. Pero pensad en el caso de que tenemos un producto en SharePoint y nuestra competencia intenta encontrar el código para incluir esas mejoras en  su producto. Está claro que en este caso sí que es un problema y debemos pensar muy bien la ubicación del mismo.

Conclusión

El nuevo FrameWork de desarrollo es una grandísima noticia para los desarrolladores de SharePoint, pero no es algo tan novedoso como pudiéramos pensar en un principio.

Es más el adaptar a un nuevo «tooling» de herramientas que muchos de los desarrolladores de SharePoint no están acostumbrados a usar, como son NodeJS, TypeScript, Gulp, Visual Studio Code o Git.