Tap to unmute

GraphQL, gRPC and REST, Oh My! A Method for Unified API Design • Mike Amundsen • GOTO 2020

  Рет қаралды 26,042

GOTO Conferences

GOTO Conferences

Күн бұрын

Пікірлер: 22
@stanislavtsybyshev7453
@stanislavtsybyshev7453 4 жыл бұрын
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...
@AhedEid
@AhedEid 4 жыл бұрын
"application-level profile semantics" is a new concept for me.
@igboman2860
@igboman2860 4 жыл бұрын
I am struggling to see how this simplifies API design. It seems like adding another layer of more complication
@ellenzhao
@ellenzhao 4 жыл бұрын
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.
@web3tel
@web3tel 4 жыл бұрын
how can one generate correct graphql schema from description with no notion of nullability?
@Wenugo1
@Wenugo1 3 жыл бұрын
As long as you don't want your OpenAPI-based HTTP to be RESTful?
@folie-n3t
@folie-n3t 3 жыл бұрын
The problem is that different teams are going to be working on different APIs and the design doc rapidly becomes out of date.
@JumpyMcTwist
@JumpyMcTwist 4 жыл бұрын
What's that tool for proto files on 14:33?
@LJCRIA
@LJCRIA 4 жыл бұрын
How can we find that “unified” tool for generating?
@dviejo
@dviejo 4 жыл бұрын
I think he's using this script github.com/mamund/2020-04-unified-api-design/blob/master/src/index.js
@BruceArmstrong09121997
@BruceArmstrong09121997 4 жыл бұрын
This is really nice one! , I can easily convert between the different tech like graphQL
@ThomasJoeisseint
@ThomasJoeisseint 4 жыл бұрын
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.
@ajooba29
@ajooba29 4 жыл бұрын
all the right keywords in this one
@valour.se47
@valour.se47 4 жыл бұрын
this is awesome , it will definitely going to save time.
@JohnNecirRebellion
@JohnNecirRebellion 4 жыл бұрын
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.
@shawnmclean7707
@shawnmclean7707 4 жыл бұрын
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/
@Lior_Banai
@Lior_Banai 4 жыл бұрын
So we end with more languages instead of less.. Not good.
@keribrahim
@keribrahim 4 жыл бұрын
This one is cool, should let my product guy know about this
@w0083e5c
@w0083e5c 4 жыл бұрын
I could actually see myself using this. After getting the domains right, try to nail the APIs on a high level using ALPS. Hm.
@kapilshekhar
@kapilshekhar 3 жыл бұрын
Great Idea! But .... everything is an abstraction of an abstraction of an abstraction of an abstraction of an ab ......
@charifzahlan7367
@charifzahlan7367 4 жыл бұрын
^^ I also call my linux box penguin. Interesting talk and implementation!
@ggzor
@ggzor 4 жыл бұрын
YAML :/
Жездуха 42-серия
29:26
Million Show
Рет қаралды 2,6 МЛН
$1 vs $500,000 Plane Ticket!
12:20
MrBeast
Рет қаралды 122 МЛН
The Future of Microprocessors • Sophie Wilson • GOTO 2024
57:37
GOTO Conferences
Рет қаралды 4,2 М.
Functional Design Patterns - Scott Wlaschin
1:05:50
NDC Conferences
Рет қаралды 302 М.
I attended Trump’s inauguration yesterday. Here are my thoughts.
7:01
Senator Bernie Sanders
Рет қаралды 4,1 МЛН
Design Microservice Architectures the Right Way
48:30
InfoQ
Рет қаралды 719 М.