SharePoint 2013 e seus modelos de desenvolvimento

Olá SharePointers,

Passando por alguns projetos recentes e após várias dúvidas comuns a profissionais do ramo, resolvi escrever um post sobre o assunto.

Com a introdução do SharePoint 2013, a Microsoft nos apresentou um recurso muito interessante: Apps for SharePoint. Durante todo o tempo em que esse conceito era apresentado para nós, era comum notarmos que a mensagem que era divulgada é “Apps é o futuro”.

Após esse período inicial, quando todos começaram a trabalhar com o produto, notamos uma grande resistência da comunidade em utilizá-lo. Para mais informações sobre como criar componentes reutilizáveis no SharePoint, veja: https://msdn.microsoft.com/en-us/library/office/jj163953(v=office.15).aspx.

Entretanto, nós profissionais, devemos filtrar a mensagem e entender o que está por trás disso tudo: Office 365. A Microsoft tem investido cada vez mais em sua plataforma de nuvem e é natural que ela concentre os seus esforços em sua “menina dos olhos”. Dessa forma, com os “famosos” apps, ela consegue resolver um problema crítico em um cenário de nuvem (com ambiente compartilhado entre os clientes): permitir que cada cliente possa customizar o seu espaço sem interferir nos demais e não ter um time para validar cada pacote, antes de ser colocado no ambiente SharePoint, para garantir que ele não contenha nenhuma operação potencialmente perigosa para o ambiente.

Com os apps não perdemos o nosso poder de customização e não dependemos de algum IT Pro para instalar, gerenciar os Change Requests no ambiente e potencialmente causar indisponibilidade no mesmo. Fantástico, não? 😀

Sendo assim, a Microsoft conseguiu criar um ambiente muito mais estável e gerenciável, permitindo entregar muita qualidade e evitando que um cliente degrade performance de outro. Combinação matadora para um ambiente de nuvem.

E quem não utiliza essa plataforma e ainda prefere/quer investir em sua plataforma on-premises?

Embora para alguns casos o modelo de Apps possa ser utilizado também, por exemplo em ambientes muito controlados onde customizações não são permitidas, esse modelo é super válido. Permite agregar valor para o usuário de forma rápida e, ainda em uma futura migração de versões do produto, é bem fácil migrar a solução.

Em um cenário onde você tem outras alternativas de desenvolvimento, como farm solutions, avaliá-las pode e deve fazer parte das atividades dos arquitetos de sistema. Escrevi um post uma vez comparando Farm Solutions com Apps (SharePoint 2013 : Farm Solution x Apps), ele aborda os detalhes técnicos com mais detalhes.

Mas, para um time que já investiu tempo (e dinheiro) criando uma série de framework e utilitários para farm solutions, não vale a pena investir esforço migrar para esse modelo novo (a não ser que tenha previsão de migrar para o Office 365 um dia). Além de termos muito mais controle com Farm Solutions, conseguimos evitar alguns comportamentos, na minha opinião, estranhos. Exemplo:

Utilizando REST APIs, ao referenciarmos um campo, devemos utilizar o Display Name do campo sem espaços; Se o campo tem o InternalName: NomePai e o Display Name: Nome do Pai, devo utilizar NomedoPai. Se o display name desse campo mudar, tem que alterar o código..

Não posso deixar de comentar que o investimento que a Microsoft está fazendo em APIs client é absurdo, buscando chegar no mesmo nível do Server Object Model. No mundo ideal, todas as APIs que temos disponíveis no lado do server estará disponível no Client. 🙂

A própria adição do “JSLink” (https://msdn.microsoft.com/en-us/magazine/dn745867.aspx) é sensacional.

Além disso, para uma farm on-prem suportar o modelo de Apps, é necessário realizar uma série de configurações adicionais no ambiente (inclusive no DNS – https://technet.microsoft.com/en-us/library/fp161236(v=office.15).aspx).

Autenticação não funcionará com Kerberos. É impossível lidar com tantas URLs diferentes que são geradas quando utilizamos Apps.

É muito rápido e fácil criar customizações server-side. Em pouco tempo estamos com uma solução pronta para utilização do usuário.

 

Para mim, sempre que possível, o modelo de desenvolvimento para ambientes on-prem é através de Farm Solutions.

 

Para ajudar na decisão de qual modelo escolher, recomendo a leitura desse link: https://msdn.microsoft.com/en-us/library/office/dn268593(v=office.15).aspx

Essa é uma discussão bem longa, gostaria de saber mais de vocês que utilizam o SharePoint no dia-a-dia. O que acham desse assunto? Qual modelo de desenvolvimento utilizam e porquê?

 

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *