![\"\"](\"http:\/\/blogs.encamina.com\/desarrollandosobresharepoint\/wp-content\/uploads\/sites\/8\/2016\/09\/SharePoint-Framework-algunas-dudas.jpg\")
<\/p>\n<\/p>\n
Una vez\u00a0 hemos empezado a entender cu\u00e1l es el contenido que tiene este framework o, mejor dicho, esta nueva forma de desarrollar sobre SharePoint, empiezan a surgir las preguntas:<\/strong>\u00a0\u00a0\u00bfEs compatible con todos los frameworks JS: ReactJS, Angular, Knockout, etc… ? \u00bfD\u00f3nde alojo nuestros desarrollos: en una librer\u00eda de SharePoint o en un CDN?\u00a0\u00bfEs compatible con PNP u\u00a0otros proyectos Open Source?<\/p>\n En este art\u00edculo vamos a intentar resolver todas estas preguntas.<\/p>\n <\/p>\n Para empezar, en mi opini\u00f3n el nombre de la herramienta no es el m\u00e1s acertado<\/strong>.Utilizar Framework<\/em> da pie\u00a0a confusi\u00f3n.<\/p>\n Creo que no han querido plasmar que es una nueva forma de desarrollar sobre SharePoint \u00a0(actualmente solo v\u00e1lida para la versi\u00f3n 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. \u00a0Partiendo de esta base, la \u00fanica forma de hacer un desarrollo sin utilizar c\u00f3digo de servidor es utilizando JavaScript.<\/p>\n <\/p>\n Ahora bien, para esta nueva forma de desarrollar, el principal objetivo que se marco el equipo de SharePoint \u00a0fue que no tuviera dependencia de ning\u00fan FrameWork JavaScript,<\/strong> es decir, que cada desarrollador pudiera utilizar el que el quisiera, si bien existe una corriente que indica que debemos utilizar ReactJS<\/strong>.<\/p>\n Esta pregunta, tiene la misma respuesta que cuando estamos utilizando JavaScript dentro de SharePoint. Depende de en qu\u00e9 consista nuestro desarrollo.<\/strong><\/p>\n Si queremos implementar un Widget, nos decantaremos por un Framework m\u00e1s ligero como ReactJS, KnockoutJS. Incluso es posible que no necesitemos ning\u00fan Framework ya que con las capacidades que tiene JavaScript, tendr\u00edamos m\u00e1s que suficiente.<\/p>\n En el caso de que queremos montar una Single Page Application (SPA), podemos decantarnos por frameworks m\u00e1s complejos como AngularJS 1 o 2, Backbone, etc…<\/p>\n Una de las mayores cr\u00edticas que se le ha echo a SharePoint es que la carga de los ficheros JavaScript era demasiado lenta comparada con\u00a0una aplicaci\u00f3n Web<\/strong>. El motivo est\u00e1 claro: para acceder a una biblioteca de SharePoint hay que autenticarse, y este proceso tarda un tiempo (lo que constituye\u00a0la principal diferencia respecto a estas aplicaciones).<\/p>\n Ahora bien,\u00a0 en el momento que generamos el paquete .sapp en el nuevo Framework, no se incluyen estos ficheros JavaScript, sino que deja su ubicaci\u00f3n\u00a0 a elecci\u00f3n del desarrollador.<\/p>\n Si mir\u00e1is la documentaci\u00f3n del FrameWork, en los ejemplos, cuando desplegamos la aplicaci\u00f3n en un entorno, obliga a tener nuestro servidor local arrancado para que pueda servir estos ficheros. Naturalmente, \u00e9sta no es una opci\u00f3n para poner nuestro desarrollo en un entorno productivo.\u00a0 La opci\u00f3n que nos recomiendan desde el equipo de producto es ubicar nuestros ficheros en un CDN de Azure<\/strong> y que nuestra aplicaci\u00f3n los consuma directamente desde all\u00ed.<\/p>\n Si lo traducimos del ingl\u00e9s, es una red de entrega de contenido, es decir, en alg\u00fan sitio de Azure disponemos de un sitio donde almacenamos nuestros ficheros y \u00e9stos se sirven de una forma muy r\u00e1pida una vez lo solicitan las aplicaciones que \u00a0los necesitan.<\/p>\n El principal problema de los CDN es la seguridad.\u00a0<\/strong>Para que los podamos consumir desde un SharePoint Online, \u00e9stos deben estar en modo p\u00fablico, con lo cual es posible que nuestros c\u00f3digos puedan caer en manos no adecuadas. En la mayor\u00eda de los casos, el obtener dicho c\u00f3digo puede que no aporte valor a terceros, ya que para acceder a los contenidos es necesario que est\u00e9n en el propio entorno. Pero pensad en el caso de que tenemos un producto en SharePoint y nuestra competencia intenta encontrar el c\u00f3digo para incluir esas mejoras en\u00a0 su producto. Est\u00e1 claro que en este caso s\u00ed que es un problema y debemos pensar muy bien la ubicaci\u00f3n del mismo.<\/p>\n El nuevo FrameWork de desarrollo es una grand\u00edsima noticia para los desarrolladores de SharePoint, pero no es algo tan novedoso como pudi\u00e9ramos pensar en un principio.<\/p>\n Es m\u00e1s el adaptar a un nuevo \u00abtooling\u00bb de herramientas que muchos de los desarrolladores de SharePoint no est\u00e1n acostumbrados a usar, como son NodeJS, TypeScript, Gulp, Visual Studio Code o Git.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n<\/span>","protected":false},"excerpt":{"rendered":" Una vez\u00a0 hemos empezado a entender cu\u00e1l es el contenido que tiene este framework o, mejor dicho, esta nueva forma de desarrollar sobre SharePoint, empiezan a surgir las preguntas:\u00a0\u00a0\u00bfEs compatible con todos los frameworks JS: ReactJS, Angular, Knockout, etc… ? … Continue reading ![\"framework\"](\"http:\/\/blogs.encamina.com\/desarrollandosobresharepoint\/wp-content\/uploads\/sites\/8\/2016\/09\/framework.jpg\" "\\"framework\\"")
<\/p>\n\n
\u00bfQu\u00e9 Framework utilizar?<\/strong><\/h2>\n
\u00bfD\u00f3nde ubicar los ficheros JavaScript?<\/strong><\/h2>\n
\u00bfQu\u00e9 es un Content Delivery Network (CDN)?\u00a0<\/strong><\/h2>\n
\u00bfCu\u00e1l es el problema de los CDN?<\/strong><\/h2>\n
Conclusi\u00f3n<\/strong><\/h1>\n