- O TypeSpec é uma nova linguagem para desenvolvimento orientado a API, projetada para atender às necessidades de desenvolvedores, designers e gerentes de API
- Foi desenvolvido em um contexto no qual se torna cada vez mais complexo e importante oferecer APIs e experiências de API consistentes de alta qualidade
- O TypeSpec não é apenas uma linguagem simples; é uma plataforma que permite abstração, incentiva reutilização de código e usa ferramentas modernas para permitir um desenvolvimento ágil
Principais características do TypeSpec
- Interoperabilidade
- O TypeSpec não é apenas uma linguagem de descrição de API, mas uma linguagem de definição de alto nível capaz de definir APIs e emitir simultaneamente vários protocolos, clientes, servidores e documentos
- É interoperável com linguagens padrão da indústria para definição de API, reduzindo a lacuna entre diferentes alternativas
- Produtividade
- O TypeSpec oferece uma ótima experiência de desenvolvedor ao tornar o processo de dados e definição de API agradável e produtivo
- A linguagem é concisa e permite definir dados e formatos de API complexos com o mínimo de entrada possível
- Padrões de API
- O TypeSpec melhora a qualidade de API encapsulando componentes reutilizáveis de alto nível, como tipos de dados, padrões de API e diretrizes, que podem ser compartilhados em todo o time ou ecossistema
- Familiaridade
- O TypeSpec é inspirado em TypeScript e C#, então é fácil de aprender e familiar para muitos desenvolvedores
- Extensibilidade
- O TypeSpec pode ser expandido com vocabulário de decoradores personalizados e templates de tipos, permitindo modelar APIs em domínios de lógica de negócio ou aplicação
- Ecossistema
- Com TypeSpec, é possível empacotar tipos comuns, extensões de linguagem, linter e emitters e distribuí-los no NPM em toda a organização ou ecossistema
Comunidade e colaboração
- Em uso na Microsoft
- A Microsoft está usando o TypeSpec para revolucionar seu processo de desenvolvimento de API
- Muitos serviços da Azure adotaram o TypeSpec, e esse número aumenta diariamente
- O time do Microsoft Graph está aproveitando o potencial do TypeSpec para aumentar a produtividade e simplificar a personalização
- Convite à participação
- O TypeSpec é mais que uma linguagem: é uma comunidade
- Convida desenvolvedores de todas as formações a participar da beta pública para experimentar em primeira mão o potencial do TypeSpec
Opinião do GN⁺
- O TypeSpec parece ser uma linguagem de definição de API de alto nível de abstração que tem potencial para melhorar de forma inovadora a forma de desenvolver APIs
- O suporte à abordagem "API First" deve ajudar a aumentar a eficiência de desenvolvimento e a qualidade do produto final
- Devido ao suporte a múltiplos protocolos, extensibilidade e ecossistema robusto, espera-se que seja aplicável em uma ampla gama de cenários de desenvolvimento
- No entanto, como a adoção de uma nova linguagem sempre gera custo de aprendizado, deve haver capacitação adequada antes da adoção no time
- É positivo que tenham se esforçado para reduzir a curva de aprendizado ao adotar sintaxe de TypeScript e C#
- Parece necessário deixar mais claros os diferenciais frente a linguagens de definição de API com papéis semelhantes, como Swagger, RAML e API Blueprint
- Como ela supera limitações de linguagens existentes, se a migração é simples e assim por diante
- A prática de uso interno na Microsoft para melhora contínua passa confiança
- Porém, como ainda foi aberta como projeto open source há pouco tempo, a continuidade de evolução e o suporte da comunidade nos próximos anos se tornarão críticos
- A direção de padronizar o desenho de API e elevar a reutilização é correta, mas passa a impressão de que tenta resolver demais de uma vez
- Seria melhor fortalecer os recursos de forma progressiva, com priorização
1 comentários
Opiniões no Hacker News
Já tínhamos tipos TypeScript para APIs, então criei o https://github.com/vega/ts-json-schema-generator, que gera esquemas JSON diretamente a partir do código-fonte.
Os conjuntos de recursos das duas linguagens são um pouco diferentes, então há algumas partes estranhas, mas o usamos bem há anos. Se você não usa TypeScript, ou se a superfície da API é pequena o bastante para valer a pena escrever os tipos de novo, vale dar uma olhada no TypeSpec. Com certeza é melhor do que escrever esquemas JSON à mão.
Qualquer coisa parece boa ao lado do YAML do OpenAPI, então isso parece meio injusto. Ainda assim, considero o OpenAPI uma das melhores mudanças.
Por outro lado, há algum tempo venho torcendo para que o TypeScript se estabeleça como uma linguagem de esquemas. Mais precisamente, aquele subconjunto surpreendentemente grande que não é imperativo nem funcional. Minha primeira impressão é algo como: “e se removêssemos o JavaScript do TypeScript, deixando apenas tipos para JSON, e acrescentássemos descrições de metadados de endpoints para que ele se tornasse o sucessor prático do OpenAPI e do WSDL?”
https://github.com/bufbuild/protovalidate/blob/main/examples...
Tenho usado TypeSpec em uma API recentemente e estava procurando uma ferramenta que, como GraphQL, descrevesse a API, mas permitisse uma abordagem design-first.
Todos os editores de OpenAPI eram lentos demais, e as relações entre os dados dentro da API não ficavam bem evidentes. TypeSpec era exatamente a ferramenta que eu estava procurando, e realmente ajudou aqui.
A Microsoft diz acreditar no valor do “dogfooding”, isto é, usar internamente os próprios produtos, mas, olhando para o ecossistema bagunçado de desenvolvimento desktop nativo para Windows ou para a adoção de Xamarin/MAUI em apps móveis, não parece ser bem assim.
Já tentei gerenciar e-mails com o Microsoft Graph, e ficaria bastante surpreso se o Outlook usasse isso.
Como veio da Microsoft, parece uma resposta ao GraphQL. Se eles fazem dogfooding internamente, talvez a qualidade das ferramentas seja razoavelmente melhor do que algo montado às pressas por um consórcio open source.
Ainda não tenho certeza, mas parece ter potencial para receber mais atenção.
GraphQL traz muitas premissas fortes, como o protocolo, o tratamento de erros e a semântica de consultas necessários para construir uma aplicação concreta. Já o núcleo do TypeSpec é mais próximo de uma DSL sem premissas para descrever APIs. Bindings para protocolos específicos são adicionados como bibliotecas, e uma biblioteca para GraphQL é algo que já consideramos há bastante tempo.
Em resumo, se a Microsoft criasse um conjunto de premissas para resolver cenários parecidos com os do GraphQL, TypeSpec poderia ser usado nesse contexto como linguagem de descrição de API. Mas não é correto tratar essas premissas como se fossem o próprio TypeSpec.
Não consegui encontrar a pergunta central: quais são as linguagens de saída suportadas? A única opção é exportar para OpenAPI e depois usar um daqueles geradores horríveis de lá?
Parece um WSDL na versão TypeScript.
https://en.wikipedia.org/wiki/Web_Services_Description_Langu...
Será que vai sobreviver mais do que o WSDL?
WSDL e SOAP são definidos em XML, e SOAP descreve XML. A popularidade dessas tecnologias acompanhou a alta e a queda da popularidade do XML em geral. TypeSpec descreve JSON e protobuf, então, se a popularidade desses formatos esfriar, é bem provável que TypeSpec também perca popularidade.
Hoje, grandes empresas preferem lançar suas próprias soluções no mercado para tentar dominá-lo, em vez de trabalhar juntas. Como resultado, às vezes surge uma abordagem de melhor qualidade, porque uma única equipe se concentra em um objetivo único. É melhor do que tentar satisfazer 10 fornecedores, cada um com sua própria agenda.
Seria bom se fosse possível simplesmente importar arquivos TypeSpec no TypeScript ou em outras linguagens e obter tipos TypeScript automaticamente.
Geração de código é trabalhosa e propensa a erros.
Pelo contrário, pode facilitar a depuração, porque os erros não ficam escondidos em duas camadas de abstração. Com código gerado, você também pode adicionar uma etapa de build para contornar limitações ou bugs do gerador; em abordagens que não geram código, muitas vezes é preciso simplesmente aceitar essas limitações.
Entendo a parte de ser “trabalhosa”. Feedback imediato é obviamente melhor do que rodar o build de novo, então, em áreas com muita iteração, as vantagens do outro lado também ficam grandes.
/openapi.Será que dá para converter YAML para a toolchain desejada?
Assim como o CORBA IDL fazia 25 anos atrás, acho que seria bem-vindo ter uma IDL de alto nível que gerasse schemas e stubs para várias linguagens
Foi bem tranquilo, porque ele oferece uma API que converte para documentos OpenAPI (https://github.com/mnahkies/openapi-code-generator/pull/158)
Estou focando tanto na geração de SDKs de cliente quanto de stubs de servidor, mas por enquanto só há suporte a TypeScript. Quando eu ficar satisfeito com a maturidade dos templates de TypeScript, quero adicionar outras linguagens algum dia
É difícil convencer as pessoas a adotarem uma linguagem dedicada, e isso também exige um esforço adicional considerável da equipe que a cria
As pessoas não querem aprender uma linguagem dedicada. Além disso, é preciso criar todo o ferramental do ecossistema da linguagem, como compilador, documentação, language server, integração com IDE e gerenciamento de dependências
Há tentativas parecidas, como WaspLang e DarkLang, mas ainda não vi uso significativo na prática ou no HN. É melhor usar uma linguagem existente e focar no valor agregado
Pessoalmente, também trabalhei em algo com valor parecido, isto é, “fonte da verdade -> tudo”, e passei por parte dessas dores
https://github.com/hofstadter-io/hof
A ideia é CUE + text/template = ferramenta de geração não limitada a APIs