Módulos, Models e APIs

Estive presente no Latinoware 2011, de 19 a 21/10 para apresentar uma palestra sobre WebAPIs para dispositivos móveis. A idéia era mostrar algumas das melhores práticas para o desenvolvimento da API de serviços para Apps mobiles.

Uma das palestras que seguiram foi a do Er Galvão, falando sobre Zend_Acl e de uma implementação bem interessante a que ele chegou.

No fim da palestra dele, um dos congressistas fez uma pergunta muito interessante que eu gostaria de compartilhar. Ele informou que tinha enfrentado muitos problemas com o uso de Acl com módulos do Zend e pediu orientações sobre como resolvê-los.

Como este é um dos assuntos que me interessam e porque minha palestra falava exatamente sobre APIs, pedi licença ao Galvão e me meti na conversa. Tenho visto que o principal benefício “vendido” por quem usa módulos é o reuso da camada model da aplicação. Você pode implementar “sub-aplicações” usando o mesmo conjunto de classes, evitando a reescrita do código de negócios.

Na minha opinião, isto é uma gambiarra para tentar contornar uma limitação clara do modelo MVC, que é o de estar contido em uma aplicação.

Quem acompanhou a evolução dos frameworks, biblioteca de classes e template engines sabe que surgiram diversas tentativas de generalizar controllers e views. A maioria vai bem, obrigado. Mas não faz sentido usar um componente de software para generalizar o model, uma camada que é específica para uma aplicação ou um grupo de aplicações. E esta é a limitação.

A resposta que dei para o congressista e sobre a qual voltei a comentar ontem é sobre um paradigma de desenvolvimento que estamos usando massivamente na Nexy: APIs.

Todos os novos sistemas que estamos desenvolvendo abusam de APIs. Mesmo que sejam apenas para uso interno. O que está lá implementado é a antiga camada model, acrescida de um fino controller apenas para rotear, instanciar, executar e retornar. Existem várias soluções para implementação rápida de APIs. A mais simples que conheço é o GRS, de código aberto e desenvolvido internamente (http://github.com/ramcoelho/grs), onde você implementa apenas as classes do model. Outra, muito mais flexível é o Respect/Rest (http://github.com/respect/rest).

São evidentes as vantagens de usar esta abordagem em todas as aplicações (mesmo as internas). Talvez você não perceba a necessidade de manter o controle de pedido de materiais sob uma API, mas apenas o fato dela existir, torna muito mais fácil a automatização posterior que venha a surgir, além de reforçar o mantra “programe para uma interface”, facilitando a vida de outro programador que seja envolvido na solução.

O resultado direto é que, sem a necessidade de compartilhar o model dentro da aplicação, os módulos viram aplicações distintas, todas compartilhando a mesma API.

Esta idéia é suportada por empresas como Twitter, Foursquare, Google, e certamente estão no cerne do grande sucesso do Facebook e seus aplicativos e jogos.

Be Sociable, Share!

2 ideias sobre “Módulos, Models e APIs

  1. Pelo que entendi, essa abordagem poderia ser aplicada às tarefas CRUD, logs, acl’s e coisas do gênero por exemplo, correto?

    • Também. Na verdade, qualquer operação com os dados passaria por esta camada RESTFul. Isto força a API a evoluir até que seja suficiente manipular todos os dados de maneira segura e em conformidade com a arquitetura. A vantagem mais direta é a centralização das validações e a imposição das regras de negócio a todas as operações de leitura e escrita de dados.

Deixe uma resposta