Desvantagens da plataforma Force.com [fechado]

No momento, estamos considerando usar a plataforma Force.com como nossa plataforma de desenvolvimento e os vendedores e o site force.com estão repletos de motivos pelos quais ela é a melhor plataforma do mundo. O que estou procurando, porém, são algumas desvantagens reais de usar essa plataforma.

Aqui estão 10 para você começar.

1. Apex é uma linguagem proprietária. Além do plug-in Force.com Eclipse, há pouco ou nenhum conjunto de ferramentas disponível, como refatoração, análise de código, etc.
2. O Apex foi modelado em Java 5, que é considerado atrasado em outras linguagens e sem ferramentas (consulte o item 1), pode ser bastante complicado.
3. A implantação ainda é bastante manual, com muitas dicas e etapas manuais. Essa situação está melhorando lentamente com o tempo, mas você ficará desapontado se estiver acostumado a ter implantações automatizadas.
4. Apex não tem pacotes / namespaces. Todas as suas classes, interfaces, etc. vivem em uma pasta no servidor. Isso torna o código muito menos organizado e os nomes de classe / interface necessariamente longos para evitar conflitos de nome e fornecer contexto. Esta é uma das minhas maiores reclamações, e eu não escolheria construir livremente na force.com somente por esse motivo.
5. O "force.com IDE", também conhecido como force.com eclipse plugin, é incrivelmente lento. Salvar qualquer arquivo, seja um arquivo de classe, arquivo de texto, etc., normalmente leva pelo menos 5 segundos e às vezes até 30 segundos, dependendo de quantos objetos, tipos de dados, arquivos de classe, etc. estão em sua organização. Salvar também é uma ação de bloqueio, exigindo não apenas a compilação, mas uma sincronização completa do seu projeto local com o servidor. Ordens de magnitude mais lentas do que Java ou .NET.
6. A comunidade de desenvolvedores online não parece muito saudável. Tenho notado muitas postagens de fóruns sem resposta ou sem solução. Acho que isso pode ter algo a ver com o software de fórum que a salesforce.com usa, que parece ser muito ruim.
7. O acesso a dados DSL no Apex deixa muito a desejar. Não é nem remotamente competitivo com os gostos de (N) Hibernate, JPA, etc.
8. O desenvolvimento de um aplicativo no Apex / VisualForce é um exercício de engenharia de limites do governador. Facilmente metade do tempo do programador é gasto tentando otimizar para evitar os numerosos limites do governador e outras pegadinhas como limites de estado de exibição do Visualforce. Pode-se argumentar que, se você escrever um código eficiente para começar, não terá esse problema, o que é verdade até certo ponto. No entanto, muitas vezes você tem motivos válidos para fazer mais de x consultas em uma sessão ou percorrer mais de x registros, etc.
9. O ciclo de salvar-> compilar-> executar é extremamente lento, esp. quando envolve compactar e enviar todo o pacote de recursos estáticos apenas para fazer algo como testar uma pequena alteração de CSS ou javascript.
10. Em geral, a dor de uma plataforma jovem e incipiente sem os benefícios de ser de código aberto. Você não tem como validar e / ou corrigir bugs na plataforma. Eles dizem para postar no IdeaExchange. Sim, boa sorte com isso.

Isenções de responsabilidade / divulgações: há muitos benefícios em uma plataforma hospedada como force.com. A Force.com aprimora regularmente a plataforma. Há muitas coisas de que gosto. Eu ganho dinheiro construindo na force.com

Vejo que você obteve algumas respostas, mas gostaria de reiterar quanto tempo é desperdiçado contornando os vários limites do governador na plataforma. Por mais que eu goste da plataforma em certos níveis, eu a recomendaria fortemente, enfaticamente, enfaticamente contra ela como uma plataforma de desenvolvimento de aplicativo geral. É ótimo como um aplicativo de CRM superconfigurável e extensível, se você quiser. Embora seu marketing seja excepcional em promover a ideia da Force.com como uma plataforma de desenvolvimento geral, ainda não está nem remotamente perto disso.

A eficiência de ter uma plataforma estável e evitar grandes problemas de desempenho e estabilidade é facilmente desperdiçada em tentar codificar em torno dos limites aos quais as pessoas se referem. Existem tantos limites para a plataforma que se torna completamente enlouquecedora. Esses limites não são limites avançados que você atingirá quando tiver muitos usuários, mas os atingirá quase imediatamente.

Embora geralmente existam técnicas para contorná-los, é muito difícil descobrir estratégias para evitá-los enquanto você também tenta desenvolver a lógica de negócios de seu aplicativo real.

Para lhe dar uma ideia simples de como o ambiente é hostil para o desenvolvedor, considere a "falta de ambiente de depuração" mencionada acima. É pior do que isso. Você só pode ver até 20 das solicitações mais recentes para o servidor nos logs de depuração. Então, conforme você está desenvolvendo dentro do aplicativo, você deve criar uma solicitação de depuração "Novo", selecionar seu nome, clicar em "Salvar", voltar ao seu aplicativo, atualizar a página, clicar de volta na guia de depuração, tentar encontrar a solicitação que abrigará seu log de depuração, clique em "localizar" para pesquisar o texto que você está procurando. São cerca de dez cliques para ver uma saída de depuração. Embora possa parecer trivial, é apenas um exemplo de quão pouco cuidado e consideração foram dados à experiência do desenvolvedor.

Tudo sobre a plataforma de desenvolvimento é uma reflexão tardia enxertada. É notável pelo que é, mas um PITA total na maior parte. Se você não sabe exatamente o que está fazendo (já que você é certificado e tem um conhecimento profundo do Apex), facilmente levará mais de 10 a 20 vezes o tempo que levaria em outro ambiente para fazer algo que parece ridiculamente simples, se é que você consegue ter sucesso.

Os limites do governador são realmente ruins. Você tem uma combinação de vários limites (consultas de banco de dados, linhas retornadas, "instruções de script", chamadas futuras, textos explicativos etc.) e precisa saber exatamente o que está fazendo para evitá-los. Por exemplo, se você tiver um campo de "fórmula" de rollup calculado em um objeto e tiver um gatilho em um objeto filho, ele executará os gatilhos do objeto pai e os contará em relação aos seus limites. Coisas assim não são óbvias até que você passe pelo doloroso processo de tentar e falhar.

Você tentará uma coisa para evitar um limite e acertará outra em um jogo interminável de "quebrar um limite". No processo, você terá que reestruturar drasticamente todo o seu aplicativo e abordagem, bem como reescrever todo o seu código de teste. Você deve ter 75% de cobertura de código de teste para implantar na produção, o que é realmente muito bom, mas combinado com todos os outros limites, é muito trabalhoso. Na verdade, você atingirá os limites do governador ao escrever seu código de teste que não surgiria em cenários normais de usuário, mas que o impedirá de atingir a cobertura.

Isso sem falar em uma série de outras questões. A embalagem não é o que você espera. Você não pode empacotar seu aplicativo e entregá-lo aos usuários sem intervenção significativa do usuário e configuração por parte do administrador da organização. O AppExchange é uma piada total, e eles até começaram a cobrar 5K apenas para listar seu aplicativo. Importar com o carregador de dados é uma droga, especialmente se você tiver gatilhos. Você não pode exportar todos os seus dados em uma etapa que inclua seus relacionamentos de forma que possam ser facilmente reimportados para outra organização em uma única etapa (por exemplo, uma organização dev). Você só pode atualizar um sandbox uma vez por mês a partir da produção, sem exceções, e você não pode incluir seus dados em uma atualização por padrão, a menos que tenha chamado seu executivo de conta para desbloquear esse recurso. Você pode' t excluir dados em massa em objetos personalizados. Você não pode alterar os nomes dos seus pacotes. Certas coisas podem levar váriosdias para serem concluídos depois de solicitados, como um backup de dados antes de implantar um aplicativo, sem relatório de progresso ao longo do caminho e sem muita noção de quando exatamente a exportação ocorreu. Visto que há problemas de sincronicidade de dados se houver relacionamentos entre os dados, há problemas sérios de integridade de dados, pois não existe uma "transação" que pode exportar vários objetos em uma única etapa. Provavelmente, existem algumas ferramentas comerciais para facilitar isso, mas não estão ao alcance de desenvolvedores normais que podem não ter um orçamento enorme.

Tudo o mais que as outras pessoas disseram aqui é verdade. Às vezes, pode levar de cinco segundos a um minuto para salvar um arquivo.

Não quero ser tão negativo porque a plataforma é muito legal em alguns aspectos e eles estão tentando fazer coisas em um ambiente multilocatário que ninguém mais está fazendo. É um ambiente muito inovador e poderoso em alguns níveis (na verdade, gosto muito do VisualForce), mas espere mais um ou dois anos. Eles estão fazendo parceria com a VMware, talvez isso leve aos desenvolvedores um pouco mais de um cercadinho em vez de uma cela de prisão para trabalhar.

Aqui estão algumas coisas que posso dar a você depois de passar um bom tempo desenvolvendo na plataforma na última quinzena ou mais:

1. Não há API RESTful. Eles têm uma API baseada em sabão que você pode chamar, mas não há como fazer chamadas verdadeiramente tranquilas

2. Não há uma maneira simples de pegar seus SObjects e convertê-los em objetos JSON.

3. As páginas de força visual estão ok até que você queira personalizá-las e então é um mundo inteiro de dor.

4. As páginas de força visual precisam ser vinculadas a SObjects, caso contrário, não há como fazer com que os campos de entrada padrão, como o selecionador de data ou a lista de seleção, funcionem.

5. O plugin do eclipse está ok se você quiser trabalhar sozinho, mas se você quiser trabalhar em uma grande equipe com o plugin do eclipse, esqueça. Ele não lida com a sincronização de e para o servidor, ele trava e não é muito útil.

6. NÃO HÁ DEBUGGER! Se você deseja depurar, ele é literalmente depurado por instruções system.debug. Este é provavelmente o maior problema que encontrei

7. Seu modelo "MVC" não é realmente MVC. Está muito mais próximo de ASP.NET Webforms. Suas visualizações estão fortemente acopladas não apenas aos modelos, mas também aos controladores.

8. Armazenar um grande número de documentos não é viável. Precisamos armazenar mais de 100 GB de documentos e fomos citados como uma figura ridícula. Decidimos implementar nosso armazenamento de documentos na infraestrutura Amazon S3

9. Mesmo que a linguagem seja baseada em java, não é java. Você não pode importar quaisquer pacotes ou bibliotecas externas. Além disso, as bibliotecas básicas disponíveis são severamente limitadas, então nos encontramos implementando um monte de coisas externamente e, em seguida, expondo esses bits como serviços que são chamados por force.com

10. Você pode chamar serviços externos baseados em SOAP ou REST, mas o corpo da mensagem é limitado a 100kb, então é muito restritivo no que você pode chamar.

Com toda a honestidade, embora haja benefícios potenciais em desenvolver algo como a plataforma force.com, para mim, você não poderia usar a plataforma force.com para verdadeiros aplicativos de nível empresarial. Na melhor das hipóteses, você poderia escrever alguns aplicativos básicos de estilo crud, mas quando você passar para qualquer coisa remotamente complicada, eu estaria evitando como uma praga.

Uau, há muita coisa aqui que eu nem sabia que eram limitações - depois de trabalhar na plataforma por alguns anos.

Mas só para acrescentar outras coisas ...

O motivo pelo qual você não tem um depurador linha por linha é exatamente porque é uma plataforma multilocatária. Pelo menos é o que SFDC diz - parece que nesta era de programação rica em threads, isso não é uma boa desculpa, mas essa é aparentemente a razão. Se você tiver que escrever código, terá "System.debug (String)" como seu depurador - lembro-me de ter ferramentas de depuração de servidor mais sofisticadas em Java 1.2 há cerca de 12 anos.

Outra coisa que realmente odeio no sistema é o controle de versão. A estrutura Spring não é usada para o que Spring é normalmente usado - é realmente mais uma ferramenta de configuração em SFDC do que controle de versão. SFDC fornece controle de versão ZERO.

Você pode ficar preso por dias fazendo algo que deveria parecer tão ridiculamente fácil, como, digamos, agendar um relatório SFDC para exportar para um arquivo CSV e enviar por e-mail para uma lista de destinatários ... Bem, sobre a maneira mais fácil de fazer isso é crie um objeto personalizado com um campo personalizado, com uma regra de fluxo de trabalho e um modelo de email do Visualforce ... e então, para o código, você precisa escrever um componente do Visualforce que transmite os dados do relatório para o modelo de email do Visualforce como um anexo e você escreve APEX anônimo atualização de campo de programação de código do objeto personalizado ... Para desenvolvedores SFDC, esta é uma tarefa quase diária ... tentar colocar cerca de cinco tecnologias diferentes juntas para fazer tarefas que parecem tão simples ... E isso pode causar dores de cabeça de gerenciamento e tensões também - Normalmente, você descobriria isso depois de receber uma sugestão para fazer algo que nãot trabalhar na comunidade de usuários (como alguém já disse) e, em seguida, tentar muitas coisas que, depois de desenvolvê-los, você descobrirá que simplesmente não funcionam por algum motivo estranho - como "você não pode agendar um Página do VisualForce "ou" você não pode chamar getContent de um contexto programável "ou algum outro motivo misterioso.

Há tantos, muitos pequenos problemas enlouquecedores na plataforma SFDC, que uma vez que você sabe POR QUE eles estão lá, faz sentido ... mas eles ainda são limitações muito ruins que o impedem de fazer o que você precisa fazer. Aqui estão algumas das minhas;

1. Você não pode obter informações do proprietário do registro "fora da caixa" em praticamente qualquer tipo de registro - você deve escrever um gatilho que vincule o proprietário na criação do registro ao registro que você está inserindo. Por quê? Resposta curta porque um proprietário pode ser uma "pessoa" ou uma "fila", e os dois são entidades drasticamente diferentes ... Faz sentido, mas pode virar um projeto literalmente de cabeça para baixo.

2. Modelo de segurança enlouquecedor. Exemplo: a permissão "Gerenciar relatórios públicos" é muito diferente de "Criar e personalizar relatórios" e basicamente se aplica a tudo na plataforma ... especialmente pastas de qualquer tipo.

3. Conforme mencionado, o suporte é basicamente inexistente. Se você é um indivíduo extremamente autossuficiente, ou tem muitos recursos do SFDC, ou tem muito tempo e / ou um gerente muito complacente, ou é responsável por um sistema SFDC que está funcionando bem, você está muito bem forma. Se você não estiver em nenhuma dessas posições, poderá se ver em sérios problemas.

SFDC é uma proposta de negócio muito sedutora ... sem pegada de equipamento, segurança muito boa, preço fixo, sem infraestrutura E você obtém CRM baseado na web com processamento em batalha e agendável ... Mas como os outros participantes disseram, é realmente um aumento considerável no aprendizado de desenvolvimento, e se você for com consultoria, acho que o preço mais baixo que vi foi de US $ 200 / hora.

O Salesforce tende a se integrar com outras coisas anos depois de algumas tecnologias se tornarem comuns - JSON e jquery vêm à mente ... e se você tiver outras infraestruturas comuns com as quais deseja fazer uma integração, como JIRA, espere pagar muito mais, e eles podem ter muitos erros.

E, como um dos outros pôsteres mencionados, você está constantemente lutando contra os limites do governador que podem te deixar maluco ... um anexo NÃO pode ter> 5 MB. Período. E às vezes <3 MB (se codificado em base64). Dez textos explicativos HTTP em uma classe. Período. Existem dezenas de limites do governador publicados, e muitos que não são, você sem dúvida encontrará e só vai querer sair correndo do seu escritório gritando.

Eu realmente gosto da plataforma, mas acredite em mim - pode ser uma amante realmente cruel.

Mas, para ser justo com o SFDC, eu diria o seguinte: o maior problema que encontro com a plataforma não é a plataforma em si, mas as expectativas gigantescas que quase qualquer pessoa que vê a plataforma, mas não desenvolveu nela tem ... e essas pessoas tendem a ocupar posições de grande autoridade nas organizações empresariais; marketing, vendas, gestão, etc. Ocorrem enormes desconexões e cabeças rolam ou ameaçam rolar diariamente - tudo porque existe uma grande plataforma com pegadinhas estranhas e milhares de pessoas lutando diariamente para entender por que as coisas deveriam funcionar quando eles simplesmente não querem e não querem.

EDITAR:
Só para acrescentar comentários de lomaxx sobre o MVC; Na terminologia SFDC, isso está intimamente relacionado ao que é conhecido como "viewstate" - e pode ser realmente problemático, já que o que está na página VF não é o que está na classe de controlador da página. Então, você tem que passar por giros estranhos para sincronizar o que está na página com o que o controlador vai escrever no SF quando você clica no botão "salvar" (ou faz seu callout HTTP ou o que quer que seja) ... cara, é irritante .

Acho que outras pessoas cobriram as desvantagens com mais profundidade, mas para mim, não parece usar o paradigma MVC ou suportar muito na forma de reutilização de código. Fazer qualquer coisa além de simples aplicativos é um exercício de frustração em comparação com o desenvolvimento de um aplicativo usando algo como ASP.Net MVC.

Além disso, as ferramentas, a camada de dados e a frustração de tentar refatorar código ou renomear campos durante o processo de desenvolvimento não ajudam.

Acho que como um CMS é muito legal, mas como uma plataforma para aplicativos não CMS, não faz sentido para mim.

O modelo de segurança também é muito restritivo ... mas essa não é a pior parte. No momento, você não pode afirmar se um usuário tem a capacidade de realizar uma ação específica.

Você pode verificar qual é a sua função, mas não pode verificar se essa função tem permissão para executar a ação atual.

Pior ainda é a resposta do suporte técnico para "tente a ação e se houver uma exceção, pegue-a"

Considerando que Force.com é uma plataforma de "nuvem", sua capacidade de agir como um cliente para um serviço externo definido por WSDL é bastante desanimador. Consulte http://force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ para o que você pode acabar tendo que fazer.

Para todos os itens acima, estou curioso para saber como o lançamento do VMforce, permitindo que o programador Java escreva código para Force.com, muda as desvantagens acima.

http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071

Acho que eles estão tentando resolver esses problemas. No dreamforce, eles mencionaram que estamos tentando diminuir os limites do governador para apenas 4. Não tenho certeza de quais são os detalhes. Eles têm uma API REST para acesso antecipado e compraram o heroku, que é um desenvolvimento ruby ​​na nuvem. Eles dividem o banco de dados, com database.com, para que você possa fazer todo o seu desenvolvimento web e suas chamadas de banco de dados usando database.com.

Acho que eles estão tentando torná-lo o mais agnóstico possível. Mas, neste momento, todos esses são anúncios e acesso antecipado, então, assim como suas declarações de Safe Harbor, não compre pelo que eles dizem, apenas pelo que eles têm atualmente.