Erik hand gifted me one of these copies when we spoke at API Days. What a wonderful life I live (and promise to pass on the knowledge and resources to current and new generations). Trying to see if we have OโReilly access here at AWS....so I can reference it digitally
4
21 Jul 2020
2
3
21 Jul 2020
You have two copy of Continues API Management... Hahaha
I need one ๐ญ
Btw great collection ๐
2
3
I am so grateful to know about these resources! Too bad I canโt include the digital versions of even more recent ones including @Luisw19โs Enterprise API Management. Iโll have to find a good โdigital shelfโ app like this...
4
21 Jul 2020
That is exactly what I call a "classic" collection ๐ฅฐ๐ซ๐ฎ #apieconomy101 #apitalous101
1
3
thoughts from my home office ๐ก
2
1
4
21 Jul 2020
Exactly like @MattMcLartyBC said. Throw in APIs on those microservices and you can decouple the teams even across infrastructure and company boundaries. We covered some nice recent empirical research on this in chapters 11 and 19 apieconomy.info/blog/table-oโฆ #apieconomy101
1
5
11 Jul 2020
But I would ask what this classification is intended for. A decision methodology for protocol selection? I think it's more important to make your systems adaptable to changing protocols than to try and pick the perfect protocol at the start. 2/2
1
2
11 Jul 2020
By the Fowler/Lewis/Newman definition, microservices is intended to facilitate the possibility of multistack (AKA polyglot) even if it doesn't always work out that way in practice. Regardless, it's a major goal of microservices to decouple teams.
1
5
11 Jul 2020
In the context of APIs, everyone should have a multistack mindset. At a minimum, you need to consider synch vs asynch protocols. I like to start by ignoring the stack and modeling interactions as queries, commands and events, agnostic of protocol blogs.mulesoft.com/dev/microโฆ 2/3(oops)
1
2
11 Jul 2020
I'll add a little zing to the thread... In my experience, "fullstack" doesn't exist. Most people claiming to be fullstack engineers are hardwired to a particular stack, which makes them inflexible when it comes to evolving technologies. I like the idea of "multistack" instead 1/2
3
1
11 Jul 2020
@DoerrfeldBill you ๐ฅ it. Thanks, for sharing your view ๐.
and @d_gilling your example REST/GraphQL gives a more clarity in thoughts. Thanks for sharing. ๐ฅ
I am sharing the derived context here, please share your views. might be helpful to blog.
11 Jul 2020
Context-2
If we derive this term to API ecosystem, then If engineering is the mixture of various API forms like HTTP/WS or gRPC/MQTT APIs then what would be the best term to represent it? MultiStack API Engineering?
1
11 Jul 2020
In addition, multistack requires knowing when to buy from an API-driven service (Auth0, Algolia, etc) or BaaS (Firebase) vs when building truly makes economic sense (which many times is less than you may think).
1
2
11 Jul 2020
Love @DoerrfeldBill's definition. Multistack to me is someone well versed in multiple technologies. i.e. REST vs GraphQL, a blog using Jekyll, a quick API using Node Mongo, analytics using Spark Scala Druid. Multistack doesn't require knowing both frontend & backend.
1
1
2
Also suggest asking our friends @SlashDataHQ for global and segmented data for objective, data driven views.
2
4
There folks mention stacks they use and love. Less friction for designing, building, deploying APIs, the more adoption is widespread and scales.
1
2
Bill would be great coming back full circle to relate it to various types of APIs..web services to GraphQL to microservices, message based/EDA related ones. recent thread we can draw on is @ASpittel asking โIn your experience, what is the absolute easiest way to make an API?โ
2
4