#InterSystems IRIS

Neste artigo eu gostaria de falar sobre a abordagem de especificação primeiro (spec-first) para o desenvolvimento de APIs REST.

Embora o desenvolvimento de API REST com código primeiro (code-first) tradicional seja assim:

• Escrever o código
• Habilitando-o com REST
• Documentando-o (como uma API REST)

A especificação primeiro (spec-first) segue os mesmos passo, mas ao contrário. Começamos com uma especificação, também usando-a como documentação, geramos uma aplicação REST padrão a partir dela e, finalmente, escrevemos alguma lógica de negócios.

Isso é vantajoso porque:

• Você sempre tem uma documentação relevante e útil para desenvolvedores externos ou front-end que desejam usar sua API REST
• A especificação criada em OAS (Swagger) pode ser importada em uma variedade de ferramentas permitindo edição, geração de cliente, gerenciamento de API, teste de unidade e automação ou simplificação de muitas outras tarefas
• Arquitetura de API aprimorada. Na abordagem de código primeiro (code-first), a API é desenvolvida método a método então um desenvolvedor pode facilmente perder o controle da arquitetura geral da API, no entanto, com a especificação primeiro (spec-first), o desenvolvedor é forçado a interagir com uma API a partir da posição de um consumidor de API, o que geralmente ajuda no design de uma arquitetura melhor da API.
• Desenvolvimento mais rápido - como todo código padrão é gerado automaticamente, você não terá que escrevê-lo, tudo o que resta é desenvolver a lógica de negócios.
• Loops de feedback mais rápidos - os consumidores podem obter uma visão da API imediatamente e podem oferecer sugestões com mais facilidade, simplesmente modificando as especificações
  Vamos desenvolver nossa API em uma abordagem de especificação primeiro!

Desta vez, quero falar sobre algo não específico do InterSystems IRIS, mas que acho importante se você deseja trabalhar com Docker e seu servidor no trabalho é um PC ou laptop com Windows 10 Pro ou Enterprise.

Como você provavelmente sabe, a tecnologia de contêineres vem basicamente do mundo Linux e, hoje em dia, está em hosts Linux onde apresenta potencial máximo. Quem usa o Windows normalmente vê que tanto a Microsoft quanto o Docker têm feito esforços importantes nos últimos anos que nos permitem rodar contêineres baseados em imagens Linux em nosso sistema Windows de uma maneira muito fácil... mas é algo que não é suportado para sistemas em produção e, este é o grande problema, não é confiável se quisermos manter os dados persistentes fora dos contêineres, no sistema host... principalmente devido às grandes diferenças entre os sistemas de arquivos Windows e Linux. No final, o próprio Docker para Windows usa uma pequena máquina virtual Linux (_MobiLinux) para executar os contêineres... ele faz isso de forma transparente para o usuário do Windows... e funciona perfeitamente bem se, como eu disse, você não exigir que seus bancos de dados sobrevivam mais do que o contêiner...

Bem... vamos direto ao ponto... o ponto é que muitas vezes, para evitar problemas e simplificar, precisamos de um sistema Linux completo e, se nosso servidor for baseado em Windows, a única maneira de fazê-lo é por meio de uma máquina virtual. Pelo menos até o WSL2 no Windows ser lançado, mas isso será uma outra história e com certeza levará um pouco de tempo para se tornar robusto o suficiente.

Neste artigo, vou lhe dizer, passo a passo, como instalar um ambiente onde você poderá trabalhar, se precisar, com contêineres Docker em um sistema Ubuntu em seu servidor Windows. Vamos lá...

Olá Comunidade!

É com grande prazer que convidamos todos os desenvolvedores para o o próximo Webinar Inicial do Concurso de Interoperabilidade InterSystems! O assunto deste webinar é o Concurso de Interoperabilidade.

Neste webinar, nós iremos falar a respeito das funcionalidades de interoperabilidade de nossa plataforma de dados InterSystems IRIS, iremos fazer uma demonstração de como criar uma solução de interoperabilidade básica no IRIS e demonstrar como utilizar o PEX. Além disto iremos discutir e responder perguntas de como criar soluções de interoperabilidade utilizando as plataformas de dados InterSystems IRIS e IRIS for Health.

Dara e Horário: Segunda, 2 de Novembro — 12:00 BRT (horário de Brasília)

Palestrantes:
🗣 @Stefan Wittmann, InterSystems Product Manager
🗣 @Eduard Lebedyuk, InterSystems Sales Engineer
🗣 @Evgeny Shvarov, InterSystems Developer Ecosystem Manager

Fala pessoal!

Quero dividir com vocês um projeto pessoal, que iniciou como um simples pedido no meu trabalho:

É possível saber quantas licenças Caché estamos utilizando?

Lendo outros artigos aqui na comunidade, eu encontrei este excelente artigo de David Loveluck

Olá, desenvolvedores!

"objectscript.conn" :{
      "ns": "IRISAPP",
      "active": true,
      "docker-compose": {
        "service": "iris",
        "internalPort": 52773
      }

Quero compartilhar com vocês um novo recurso bem maneiro que descobri no novo lançamento 0.8 do plugin VSCode ObjectScript de @Dmitry Maslennikov e CaretDev.

O lançamento traz uma nova configuração "docker-compose", que resolve o problema com as portas necessárias para fazer o VSCode Editor se conectar à IRIS. Não era muito conveniente se você tivesse mais de um contêiner Docker com a IRIS em execução na mesma máquina. Agora, esse problema foi resolvido!

Veja abaixo como funciona.

Introdução

Hoje em dia existem muitas aplicações que estão usando o Open Authorization framework (OAuth) para acessar recursos de todos os tipos de serviços de maneira segura, confiável e eficiente. O InterSystems IRIS já é compatível com a estrutura OAuth 2.0, na verdade, há um ótimo artigo na comunidade sobre OAuth 2.0 e InterSystems IRIS no seguinte link aqui.