That's somehow reminds me of UML and Rational set of code-generation tools from the 90s... That's all great, but what happens when your API need to evolve (the part seemingly missing from the demo)? You need to modify the ALPS definition, right? And because it is high-level, it naturally wont include the specifics of OpenAPI (or GraphQL, or protobuf, or whatever) - so you need to update ALPS, then regenerate API definitions one layer below (lets say OpenAPI or whatever), then (manually) carefully retrofit the all the details present in the previous version of OpenAPI in a new version of schema and so on. I have a feeling this process may become quite cumbersome and the ALPS OpenAPI will inevitably diverge...
another layer of abstraction actually. I would hardly say it's more complicated. If you compare it to the OpenAPI specs, ALPS actually is simpler and hides details.
This talk is about the concept of designing API without being stuck with HTTP or any protocols for transferring data. The talk is about how it'll be easy for someone to implement an API in any specifications (REST, GraphQL, gRPC, etc.) without changing a lot of code when changing specifications mentioned. So I think the tool presented here is not the whole, one-tool fix-all, solution. The tool demonstrates the statements I wrote above. If you want a tool like that, then build yours that suit your needs. Or if you understand the talk, then you should try building APIs with a certain specification then switch specification and see the difference in how fewer line of codes/logic was changed.
Maybe I missed something but I don't really understand how you can fully generate one API implementation from a generic (simpler) API description (ALPS), you would obviously lose some implementation details (like http codes, http methods...etc... taking openAPI as an example). It's like saying you would use pseudo code to generate a Java or Clojure application, maybe you could but you would lose many of the interesting features each language as to offer, and certainly end up with something that Java or Clojure developers would find pretty bad ("Hmm yeah actually there is a better way to do that...") because you would need to use stuff that can be generically used by both in the same pseudo code. So to summarize I guess you end up with big limitations and only using the common part of each implementation, which is rarely the determining factor in choosing that particular implementation (you most often choose it for some specificities that another doesn't propose). In think that image represent pretty well what I am trying to say en.wikipedia.org/wiki/Intersection_(set_theory)#/media/File:Venn_0000_0001.svg the center in red being that simpler API description, using things that are commonly present in each implementation but losing many of the uncommon/specific parts of each. On the contrary I think you could use ALPS the other way around, to be fully generated from the implementation description and easily read by someone not used to this specific implementation but fluent in ALPS.
This was a bit hard to find on google but the website is here, not much is there except a spec it seems. It would be nice if this tool takes off though. alps.io/
That's somehow reminds me of UML and Rational set of code-generation tools from the 90s... That's all great, but what happens when your API need to evolve (the part seemingly missing from the demo)? You need to modify the ALPS definition, right? And because it is high-level, it naturally wont include the specifics of OpenAPI (or GraphQL, or protobuf, or whatever) - so you need to update ALPS, then regenerate API definitions one layer below (lets say OpenAPI or whatever), then (manually) carefully retrofit the all the details present in the previous version of OpenAPI in a new version of schema and so on.
I have a feeling this process may become quite cumbersome and the ALPS OpenAPI will inevitably diverge...
I am struggling to see how this simplifies API design. It seems like adding another layer of more complication
another layer of abstraction actually. I would hardly say it's more complicated. If you compare it to the OpenAPI specs, ALPS actually is simpler and hides details.
how can one generate correct graphql schema from description with no notion of nullability?
"application-level profile semantics" is a new concept for me.
The problem is that different teams are going to be working on different APIs and the design doc rapidly becomes out of date.
As long as you don't want your OpenAPI-based HTTP to be RESTful?
How can we find that “unified” tool for generating?
I think he's using this script github.com/mamund/2020-04-unified-api-design/blob/master/src/index.js
What's that tool for proto files on 14:33?
This talk is about the concept of designing API without being stuck with HTTP or any protocols for transferring data.
The talk is about how it'll be easy for someone to implement an API in any specifications (REST, GraphQL, gRPC, etc.) without changing a lot of code when changing specifications mentioned.
So I think the tool presented here is not the whole, one-tool fix-all, solution. The tool demonstrates the statements I wrote above.
If you want a tool like that, then build yours that suit your needs. Or if you understand the talk, then you should try building APIs with a certain specification then switch specification and see the difference in how fewer line of codes/logic was changed.
This is really nice one! , I can easily convert between the different tech like graphQL
Maybe I missed something but I don't really understand how you can fully generate one API implementation from a generic (simpler) API description (ALPS), you would obviously lose some implementation details (like http codes, http methods...etc... taking openAPI as an example).
It's like saying you would use pseudo code to generate a Java or Clojure application, maybe you could but you would lose many of the interesting features each language as to offer, and certainly end up with something that Java or Clojure developers would find pretty bad ("Hmm yeah actually there is a better way to do that...") because you would need to use stuff that can be generically used by both in the same pseudo code.
So to summarize I guess you end up with big limitations and only using the common part of each implementation, which is rarely the determining factor in choosing that particular implementation (you most often choose it for some specificities that another doesn't propose).
In think that image represent pretty well what I am trying to say en.wikipedia.org/wiki/Intersection_(set_theory)#/media/File:Venn_0000_0001.svg
the center in red being that simpler API description, using things that are commonly present in each implementation but losing many of the uncommon/specific parts of each.
On the contrary I think you could use ALPS the other way around, to be fully generated from the implementation description and easily read by someone not used to this specific implementation but fluent in ALPS.
all the right keywords in this one
this is awesome , it will definitely going to save time.
This was a bit hard to find on google but the website is here, not much is there except a spec it seems. It would be nice if this tool takes off though. alps.io/
So we end with more languages instead of less.. Not good.
Great Idea! But .... everything is an abstraction of an abstraction of an abstraction of an abstraction of an ab ......
I could actually see myself using this. After getting the domains right, try to nail the APIs on a high level using ALPS. Hm.
^^ I also call my linux box penguin.
Interesting talk and implementation!
This one is cool, should let my product guy know about this
YAML :/