Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
API Management / Microservices / Serverless

AsyncAPI Looks to Unify API Workflow under Linux Foundation

Apr 7th, 2021 4:00pm by
Featued image for: AsyncAPI Looks to Unify API Workflow under Linux Foundation
Image by Steven Liao from Pixabay.

The AsyncAPI Initiative recently joined the Linux Foundation, bringing both its specification around asynchronous application programming interfaces (APIs), as well as its collection of open source tools that help create documentation, coding, and more for asynchronous API developers. With the move, the AsyncAPI Initiative joins alongside the OpenAPI Initiative at the Linux Foundation, bringing both sides of a single coin into the fold at the foundation, where Chris Aniszczyk, CTO and vice president of developer relations at the Linux Foundation, says he expects to see increased collaboration.

“We’re already a primary host for things like GraphQL, OpenAPI and gRPC. AsyncAPI has some ambitious goals of providing an abstraction for a lot of these different systems, so for us, we’re happy to serve this community and kind of bring together the API community under one neutral place where they’re going to collaborate and learn,” said Aniszczyk. “Once you get a bunch of smart people in a room together, collaboration tends to happen.”

When it comes to APIs, there exists a wide variety to choose from, such as those mentioned by Aniszczyk. But there is one key characteristic that separates all APIs into one of two camps: whether or not the application awaits an API response before moving on or not. With synchronous APIs, there is a request/response pattern, wherein a request is made and the application awaits the response before moving on. Asynchronous APIs, by comparison, most often use a publish/subscribe (often referred to as pub/sub) model, wherein an application subscribes to a topic and then the API provides updates to all subscribers whenever any message is posted to that topic. With an asynchronous API, the key factor is that the application continues moving forward, not awaiting a response, and these types of APIs have become the backbone for serverless and microservices architectures.

AsyncAPI creator Fran Méndez describes the AsyncAPI Initiative as comparable to that of OpenAPI, but for this other realm of APIs.

“The specification provides a common language for defining these types of interfaces. The landscape of protocols and messaging in asynchronous APIs is super wide. There are lots of protocols, unlike with HTTP APIs, which will only have HTTP,” said Méndez. “AsyncAPI provides this language that everyone can agree with, this contract if you want, and then tooling can benefit to generate documentation, generate code, to do pretty much anything you can do with OpenAPI right now, but for asynchronous APIs.”

Described in a release as a “sister project” to the OpenAPI Initiative, the AsyncAPI Initiative has many of the same functions as OpenAPI, but Méndez says the project’s ultimate goals go one step further.

“The problem that we’ve been seeing in the past years, from a user perspective, is that whenever you want to work with APIs, it is a very fragmented world. Imagine you have to define the data model for a user. This data model is most probably going to be used in many systems, not just on your REST APIs or on your GraphQL API or on your Kafka API,” said Méndez. “So it’s like, I’m doing the same thing over and over. As a user, I have to adapt to the tool, instead of the tool adapting to my workflow. What we’re trying to accomplish here is, basically, about unifying the workflow.”

To this end, both Méndez and Aniszczyk mentioned some future initiatives that they hope will work toward unifying those working on API tooling and specifications under the Linux Foundation’s tutelage. First, Aniszczyk mentioned an “API-related conference later in the year” that would potentially have tracks for different API protocols and specifications. AsyncAPI, Aniszczyk noted, has greater ambitions to include some other API systems in order to eventually offer a common layer, and events such as this, as well as collaboration at the Linux Foundation itself, would provide a way to move forward on that effort.

Mendez, meanwhile, explained that AsyncAPI joined the Linux Foundation not only to assure potentially hesitant enterprises that the AsyncAPI Initiative was something greater than a project under the direction of a single individual, but also to again work with other members of the API community.

“We want to also make it easier for people to collaborate and to take ownership of certain initiatives inside AsyncAPI,” said Mendez. “It’s about providing trust.”

In addition to joining the foundation, Méndez said they also hope to create an API working group to provide a place for not only API spec authors, but also developers and tooling creators, to meet monthly and discuss the problems faced by themselves and users alike.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.