Keops Project

O Keops Project nasceu da tentativa de permitir que o Django suportasse o desenvolvimento de Business Apps, ERP, CRM, etc. Como mencionei anteriormente, depois de algumas tentativas de sanar obstáculos existentes, percebi que seria necessário algum tipo de desconstrução pesada, uma vez que o Django não foi construído para suportar casos bem específicos de sistemas modulares corporativos (abordarei aqui esse tema superficialmente, uma vez foi melhor abordado em postagem anterior).

O Keops foi nascendo a medida que fui retirando aspectos essências para construção de sistemas modulares extensíveis. O resultado acabou me chamando atenção por permitir a escrita de excelentes painéis administrativos para projetos Django, de forma semelhante ao que temos no Admin padrão. Podendo-se dizer inclusive que o Keops é uma poderosa alternativa ao Admin, que apesar de ainda estar em status alpha (em desenvolvimento), já oferece recursos modernos essenciais para o mercado web, como:

  • Criação simplificada de APIs
  • Client-side com tecnologia AngularJS v 1.5
  • Controle de permissão em nível de menu
  • Forms com tecnologia Ajax
  • Forms customizáveis (jinja2 templates por models, apps e geral)
  • Painéis administrativos customizáveis (jinja2 template)

O processo de separação gerou 1 Framework adicional, o Framework Katrid (https://github.com/katrid/katrid), que apesar de transparente para o Keops, é essencial para construção de aplicações que rodam no client-side. Este Framework será melhor abordado em breve, pois ele agrada a “gregos e troianos”, por permitir que outras tecnologias e linguagens integrem com seu ambiente de forma bastante simplificada.

O forms possuem uma especificação diferenciada do html 5 convencional. Por possuir tags “shortcuts”, o processo de escrita de forms CRUD foi intensamente simplificado. A especificação foi inspirada na mesma especificação disponível no OpenERP/Odoo, e segue bem o princípio DRY do Django, ex:
<form><field name="name"/><field name="description"/></form>

No exemplo acima somente os campos name e description serão exibidos no formulário, as tags são substituídas por widgets pré-configurados no Framwork Katrid.

Continuo em breve.

Orun Framework

Retomo os meus posts, desta vez trazendo novidades sobre o desenvolvimento do nosso Framework Keops.

Quando iniciei o desenvolvimento do Framework Keops (por volta de 2009), era a necessidade de alguma ferramenta que realmente ajudasse a acelerar o desenvolvimento de aplicações empresariais. Apesar do framework ser utilizado desde sua concepção alpha em alguns clientes, nunca recomendei, e ainda não recomendo seu uso em produção, uma vez que ainda há muito por ser feito.

Naquela época, iniciei estendendo o Django e usando o ExtJS como camada de apresentação. O objetivo fundamental do projeto era:

  • Modularização (Permitir que desenvolvedores criem seus próprios módulos)
  • Fácil codificação (por isso escolhi python)
  • ORM (codificar totalmente, ou o máximo possível, sem necessidade de SQL direto)
  • SQL Direto (quando não for possível usar o ORM, permitir o uso de RAW SQL)
  • Herança de Modelos
  • Comunicação com o client/server através de uma API simples através de HTTP Request
  • Apresentação através da web com html5, css3 e Javascript
  • Comercialmente viável (permitir que desenvolvedores e clientes integrem seus aplicativos com libs comerciais)

Resumindo, desenvolver algo tão prático quanto o OpenERP (agora Odoo), e tão decente quanto o Django.

Antes de continuarmos, que tal uma breve comparação entre o melhor dos 2 Django e Odoo (ponto de vista ERP e CRM):

Prós Django

  • ORM fantástico (facilidade de abstração)
  • Código limpo
  • Bem estruturado
  • Database Backend (novos drivers)
  • Fácil codificação
  • Fácil internacionalização
  • Lógica de funcionamento simples
  • Incrível plataforma de testes
  • Migrations

Contras Django:

  • Modularidade pobre
  • Aplicações monolíticas
  • Herança limitada dos modelos (permite apenas heranças criando novos objetos de banco de dados ou proxies, que não adiciona campos… até tentei abrir um ticket tentando enviar um patch com a solução para esta limitação, e se me recordo bem, eles não aceitaram alegando que não era o objetivo do Django)

Prós OpenERP

  • Permite Meta-Herança de modelos (muito bom, apenas fora dos padrões _inherit?)
  • Extensão de módulos
  • Aplicações versáteis
  • Incríveis views herdadas (uso do xpath)
  • Incríveis ideias para acelerar a produtividade do usuário (muitas das ideias são comumente encontradas nos ERP’s profissionais existentes: SAP, Dynamics…)

Contras OpenERP

  • ORM pobre
  • Código pobre
  • Difícil codificação
  • Somente PostgreSQL (não permite novos drivers)
  • Confusão entre False e None
  • Funcionalidades sem lógica, ou não funcionam como deveriam
  • Internacionalização somente fazendo carga no banco de dados

Obs:

Apesar da nova Odoo API 9.0, ter melhorado bastante a camada de codificação, ainda não vi vantagens suficientes para me fazer aproveitar o core.

Ora, mas o que quero dizer com decente?

Antes que muitos gritem, que eu não acho o OpenERP decente, eu acho sim, só quem conhece o código-fonte do OpenERP, entenderia o motivo de não considerar aquele código utilizável, apesar de conter um pacote de ideias incríveis.

Em contrapartida eu reafirmo, com meus quase 18 anos de experiência em desenvolvimento de softwares, o Django, é hoje, na minha opinião, sem dúvida, de longe, o melhor Framework para desenvolvimento Web disponível.

Já o Odoo apresenta estranhezas, tentei até mesmo ajustar, e melhorar o que já existe dentro código-fonte dele. Percebi que seria mais viável fazer isso com o Django, modificar o Django para que funcione voltado ao desenvolvimento de Aplicações Empresarias (ERP’s, CRM’s etc…).

Adaptando o Django… Isso foi bem chato… Veja bem, o Django é perfeito para construção de Web Portals, Web Apps, etc… Mas não necessariamente o acesso ao tipo de aplicações que eu deseja facilitar. Encontrei principalmente obstáculos no ORM, que apesar de excelente para o que se propõe, não permite extensões. Em outras palavras, o objetivo principal de um ERP, modularização, seria parcialmente atendido usando o Framework Atual do Django.

Neste caso, o Odoo sai na frente, o framework é bem versátil, permite extensões através de herança emulada através de meta-programação. Como superado anteriormente (não voltaremos ao assunto do motivo de não usar o Odoo), sigamos enfrente identificando mais dificuldades.

Já em 2014, percebi que me custaria muito tempo desconstruir certas partes do Django, e que seria mais fácil utilizar algumas libs externas para acelerar, foi o caso principalmente do Flask (meu segundo favorito).

Criei um novo repositório, com o codinome Orun (Object Runtime) somente para ser um App Server e um segundo projeto chamado Katrid, para ser uma camada para construção de Admin Panels usando javascript com AngularJS

Eu já conhecia o Flask, tendo inclusive desenvolvido alguns projetos para clientes. Achei um framework incrível, não tão completo quanto o Django, mas faz muito bem o que se propõe, além do mais possui ótimos recursos para quem pretende desenvolver aplicações modulares, como por exemplo os Blueprints.

Blueprints serviriam muito bem para acomodar os Add-ons do nosso Framework, são equivalentes aos AppConfig’s do Django eles já possuem por natureza configurações como diretório de templates e outras configurações que me fizeram poupar algum tempo.

As views solucionei bem com o uso do Jinja2, e uma implementação do xpath, como no OpenERP ajuda bastante, a criar herança de views. Apesar do Django Template ser muito bom, foi muito prático colocar Jinja2 pra funcionar, posso afirmar tranquilamente que foi a decisão mais acertada.

A pior parte SEM DÚVIDA, foram, ainda são, as mudanças no ORM, principalmente o comando makemigrations e migrate.

A herança de Models ficou bem padronizada, bem no estilo python, como a seguir:

class Company(Partner):

company_field = models.CharField()

 

Neste caso ao invés de criar uma nova tabela para o modelo Company, como o Django faz, o Orun adiciona os campos adicionais na tabela Partner.

Muitos podem questionar esse approach, mas é o método mais eficiente para construção de extensão entre módulos, é possível como visto, criar módulos herdando características de módulos diferentes, em novos módulos, o sistema consegue até mesmo detectar a ordem dos migrations.

Esse tipo de herança nos leva até mesmo a modificar campos existentes. Também por este motivo, elegi o Flask como camada servidora, ele permite múltiplas instâncias de aplicações wsgi no mesmo servidor, assim podemos ter vários modelos com o mesmo nome, e com diferentes estruturas construídas a partir dos módulos instalados em uma determinada instância.

Resumo

Com o passar dos anos temos visto muitas novas tecnologias para facilitar o desenvolvimento de aplicações empresariais, com os novos modelos de negócios sistemas antigos devem dar espaço aos novos e robustos sistemas de gestão através da web.

Pensando em evolução resolvi criar o projeto Keops que deu origem ao projeto Orun, que tenho o orgulho de afirmar que tomei as decisões assertivas quando combinei Flask e Django, criando um projeto derivado do Django e transformando-o num poderoso Business Framework.

Orun on github: Orun Project