Para comprender la evolución del desarrollo en SharePoint tenemos que regresar a las primeras versiones  y entender los retos y razones que nos han llevado al día de hoy en el desarrollo de esta increible herramienta.

SharePoint Portal Server 2003

Esta fue primera versión que fue realmente aceptada por los desarrolladores, estaba basada en “SharePoint Team Services 2.0” la cual utilizaron los desarrolladores para empezar a modificarla.

Esta también fue la primera versión que utilizo .NET framework 2.0. Esta versión de SharePoint no contaba con un proceso establecido de programación, la documentación era muy escasa y la mayor parte del tiempo de los desarrolladores se tenían que invertir en realizar ingeniería inversa de los dll’s de SharePoint para lograr entender cómo funcionaban las cosas.

Todo se tenía que realizar utilizando las api’s del servidor que Microsoft utilizaba para traducir las páginas y los sitios, ya que en ese entonces no se contaba con una API que pudiera ser consumida desde el lado del usuario. Por lo tanto, las modificaciones tenían que correr en el mismo contexto que ejecutaba el servidor de SharePoint lo que ocasionaba que los desarrollos tuvieran que correr con privilegios avanzados y modificar cualquier cosa. Esto también significa que se podían hacer modificaciones que interrumpiera el proceso entero del servidor.

Tampoco se contaba con un proceso establecido para implementar los desarrollos dentro del servidor de SharePoint, todo tenía que ser copiado directamente dentro del servidor y en las ubicaciones adecuadas.

Este proceso aplicaba para cualquier cosa que se quisiera desarrollar dentro de SharePoint webparts, paginas, imágenes, etc.

Tomando en consideración todo esto, Microsoft realizo inversiones en mejorar el ambiente para el desarrollo en la siguiente versión.

Office SharePoint Server 2007

Esta versión estaba basada en lo que se conoce como Windows SharePoint Services 3.0 (WSS).

Esta versión de igual manera solo contaba con API’s del lado del servidor, todo desarrollo tenía que ser implementado dentro del servidor ya que no se contaba con accesos desde la parte del usuario.

Esto orillo a los desarrolladores en seguir programando modificaciones que tenían que correr con privilegios elevados en el mismo contexto que el procesamiento general de SharePoint.

Este nuevo concepto sirvió de base a los programadores para realizar más cosas dentro de la plataforma, pero estas características seguían siendo de alto riesgo ya que podían bloquear el proceso entero dentro del servidor.

Esta versión implemento 2 nuevos conceptos que tuvieron un impacto significativo en los desarrolladores de SharePoint.

La primera fue un nuevo modelo llamado “features” el cual permitió a los desarrolladores a realizar y modificar características del ambiente que anteriormente no eran fácil de implementar, como por ejemplo la creación de listas y otros artefactos.

El segundo concepto introducido en esta versión se llama “solutions”, esto se puede identificar como un tipo específico de archivo que actúa como paquete que contiene todas las modificaciones a ser agregadas dentro del servidor.

Esto permitió que, en un solo evento de instalación de la solución, este paquete realizara la misma instalación en todos los servidores dentro de la granja.

Estas dos características permitieron el crecimiento del desarrollo en SharePoint y su propagación, lo cual genero una ola de desarrollos a través de todas las diferentes industrias.

Si tu estuviste dentro del negocio en los años 2009 -2010 seguro recordaras estos días donde buenos desarrolladores de SharePoint podían implementar aplicaciones fantásticas, en esta época las empresas eran responsables de administrar y hospedar SharePoint dentro de su propia infraestructura.

Y también podrán recordar que no era una tarea simpe administrar SharePoint, su administración tomaba una cantidad de tiempo y recursos considerables.

Las empresas comenzaron entonces a analizar opciones de almacenamiento externo y Microsoft empezó a invertir dentro de este mercado ya que la administración de SharePoint para empresas grandes y corporativos era considerada todo un reto, ya que el costo de la implantación era elevado y no se podía compartirse la infraestructura con otros clientes.

Microsoft empezó a invertir en infraestructura que permitiera utilizar la misma infraestructura a varios clientes, pero el tipo de desarrollo que se tenía en este tiempo representaba un problema, ya que tenía que ser implementado dentro del servidor y una simple modificación podría tirar no solamente el ambiente del cliente que la implemento, si no la de todos los clientes que estuvieran utilizando la misma infraestructura.

Esto fue tomado en cuenta para el desarrollo de la siguiente versión.

SharePoint Server 2010 

Esta versión esta implementada sobre la versión gratuita de SharePoint Foundation 2010

Esta versión introdujo muchas nuevas características para poder ser compartidos por varios clientes o áreas y con ello se introdujo el término “tenants”.

Fue alrededor de estas fechas cuando Microsoft empezó a ofrecer lo que ahora conocemos como Office 365 o SharePoint online. También se le conocía como BPOS (business productivity Online Services).

Ahora, para los desarrolladores, esta versión trajo un nuevo paradigma llamado “sandbox solutions” las cual no necesitaban tener privilegios avanzados. Este tipo de solution tambien fueron llamados “partially trusted solutions” ya que no tenían que ser instalados directamente en SharePoint, en lugar de eso utilizaban un proxy que filtraba las acciones a las cuales se tenía acceso. Este proxy tenía varias tareas.

La primera era filtrar que a qué área del api de SharePoint se podían utilizar y a su vez limitar el acceso que se tenía como usuario, como por ejemplo el borrar sitios o el servidor o agregar código customizado programáticamente. El proxy funcionaba de barrera para que en dado caso de que la implementación fallara, la falla pudiera ser aislada y permitir al servidor seguir funcionando adecuadamente para los otros clientes utilizando la misma infraestructura.

El tipo de desarrollo que se realizaba anteriormente ahora era nombrado como “full trust solutions” y todavía eran permitidas dentro de esta versión de SharePoint.

Desafortunadamente este nuevo esquema de desarrollo no fue bien recibido por los desarrolladores, ya que este nuevo esquema era muy limitante ya que solo permitían el uso de las api’s con el contexto de la colección de sitios (site collection) donde se estaba ejecutando.

Cabe mencionar que en esta versión fue introducida la api del lado del usuario “client side object model“ (CSOM), esto permitió la integración de desarrollos utilizando librerías como JavaScript y otras más; así como el desarrollo desde el lado del usuario por primera vez.

Poco a poco esto empezó a volverse más popular como ejemplo el desarrollo de una librería muy conocida llamada SPServices.

SharePoint Server 2013/SharePoint Online 

Esta versión está basada en SharePoint Foundation 2013, esta nueva versión tuvo una inversión considerable siguiendo la meta de poder ser utilizada como un ambiente multi cliente.

Debido a esto, la nueva versión expandió considerablemente las acciones que se podían realizar desde la API de usuario y también tuvo pie la implementación de la llamada REST API.

Esto se puede interpretar como la base del tipo de desarrollo que tenemos hoy en dia y que empezó a implementarse en la versión de SharePoint 2013. La versión local de SharePoint aun soportaba los antiguos esquemas de desarrollo, pero la versión online ya no permitía soluciones de privilegios avanzados “sandbox solutions” por razones obvias.

Microsoft introdujo un modelo completamente nuevo de desarrollo llamado “Add-in Model” esto inicialmente fue llamado el “app Model” pero fue rápidamente renombrado ya que Microsoft empezaron a tener problemas, ya que generaba confusión con su nueva implementación del modelo de office también llamado “apps”.

Este nuevo esquema permitió a los programadores implementar dos nuevos tipos de soluciones.

“SharePoint Hostes Add-ins”, estas eran soluciones que podían ser almacenadas dentro del ambiente de SharePoint, pero no permitía la ejecución de ningún tipo de código que tuviera que ser compilado dentro del servidor. Este desarrollo solo podía utilizar código del lado de cliente como JavaScript haciendo uso de las nuevas api’s desarrolladas por Microsoft.

“Provider Hosted add-ins”, fue el otro tipo de solución permitida, esta solución tenía un desarrollo almacenado fuera del ambiente de SharePoint y podía tratarse de un desarrollo completo o de un simple componente, permitiendo a los desarrolladores el poder utilizar cualquier tipo de tecnología para la implementación de estos cambios. Al final la solución era integrada en SharePoint utilizando un pequeño paquete que le permitía ser agregado dentro del ambiente; pero al final su comunicación con SharePoint era realizada también utilizando solamente los api’s del lado del cliente.

Esto tenía sus propios retos, uno de los principales era que, al implementar cualquier solución de este tipo, SharePoint creaba un sub sitio oculto dentro del sitio implementado lo cual permitía aislar la solución del resto de SharePoint. Desafortunadamente esto no era lo que la comunidad de desarrolladores estaba buscando, ya que todo el desarrollo corría en un contexto externo al sitio en el que se ejecutaba, ya fuera en un ambiente externo o en un sub sitio creado para el aislamiento de la aplicación. Y las soluciones eran simplemente mostradas como pequeñas ventanas dentro de las paginas para poder tener interacciones(iFrames).

Esto origino que los desarrollos fueran lentos ya que tenían que realizar un proceso completo de autenticación e interpretación del código antes de poder ser presentados al usuario final. Esto también dificulto el crear sitios compatibles con móviles.

Debido a estas limitantes los desarrolladores empezaron a utilizar la inyección de JavaScript dentro de las paginas, lo que permitía realizar el mismo proceso de manera mucho más simple, pero también tuvo sus retos.

Este tipo de modificaciones eran muy frágiles, ya que podían caer en errores fácilmente si no se tenía practicas adecuadas de programación y también permitía a cualquier usuario con privilegios avanzados pudiera ver y modificar el código.

Este tipo de desarrollos no eran fácilmente replicables, ya que se tenía que implementar página por página realizando copias del código desarrollado y no permitía una actualización masiva.

Y finalmente no siempre era permitido la inyección de código en todos los sitios, existían cierto tipo de páginas en las cuales SharePoint impedía la inyección de código como las páginas del perfil entre otras.

SharePoint Framework (SPFX) 

Este nuevo concepto fue desarrollado con la finalidad de proveer un soporte completo para las modificaciones utilizando código de usuario como API’s y REST. Este esquema permite empaquetar y distribuir las modificaciones de la misma manera que los Add-ins funcionaban en versiones anteriores.

Estas soluciones también tienen un fácil acceso a los datos de SharePoint, sin esto significar que las soluciones estén limitadas al uso del contexto de SharePoint. Este nuevo concepto permite el uso de cualquier otro API disponible como Microsoft Graph y Office Graph.

Todas las modificaciones utilizan el contexto del usuario actual y las credenciales y accesos que se tienen, permitiendo una ejecución más rápida y eliminando las limitantes que tenía un iframe, esto sin limitar el uso de soluciones implementadas y ejecutadas desde otros sitios.

Estas nuevas implementaciones también permiten la integración de HTML responsivo y accesible a casi cualquier dispositivo.

Microsoft ha decidido ya no limitar del desarrollo de SharePoint a herramientas propias como Visual Studio, en lugar de esto ha adoptado las nuevas herramientas del mercado para el desarrollo web lo cual abre las opciones a los desarrolladores ya que no están limitados al uso de Windows.

En post subsecuente me adentrare más en los detalles de este nuevo esquema de desarrollo para SharePoint, ¿qué se necesita?, ¿cómo se configura?, y los nuevos retos que representa.

 

Leave a Comment

Your email address will not be published. Required fields are marked *