4 ms·

API connector products are pretty much ubiquitous and that's the biggest sign, to me, that there needs to be centralization and consolidation in the market. Zap

API connector products are pretty much ubiquitous and that's the biggest sign, to me, that there needs to be centralization and consolidation in the market. Zapier, Mulesoft, Integromat, IFTTT, Automate.io, [...]. And then every at-scale SaaS product ends up building their own automation platform internally. The list goes on and on. In a lot of ways it's an extremely fragmented market. Every single one of these products starts out with the same epiphany we had, which is some variation of, "there needs to be an API for APIs...". People keep putting a band-aid when what's really needed is an architectural refactor of how we deliver and connect APIs, full-stop. The problem is there's very little market incentive to standardize how API integration works because it requires the complex coordination of thousands of companies and millions of developers. The barrier to transformation is extremely high, so the catalyzing agent has to be spectacular. A product (or set of products) needs to come along that completely changes the game and creates a real incentive to standardize and adopt a common integration scheme and format. The worst-case scenario for Autocode, as I see it, is becoming just another integration tool for some specific vertical. What we're striving to deliver is an open ecosystem for integrations that's accessible to non-developers who are going to derive the most immediate value from it as an introduction to development, but attractive to professionals as a development target as well. That's an extremely difficult balance to achieve but the rewards are just as large as the problem, technically the entire industry could be made more efficient at scale.

paulryanrogers 6y ago
My guess is the devil is in the details. And the more powerful and flexible the more consensus would be needed. Which can slow innovation. Still it kind of echos back to the semantic web. That could be a foundation to empower users and their agents to consume and produce in a more tool agnostic way.
heroprotagonist 6y ago
Check out OpenAPI. It's more than just automatic documentation and mocking/testing. Clients can write code to the OpenAPI spec and not necessarily worry about underlying changes to the target API unless they are significant (in which case they are likely versioned anyway).
- keithwhor 6y ago
  There are a lot of problems with OpenAPI that are more pragmatic than ideological. “If we build to this spec, we get all this for free!” is the dream. It’s not the reality. You’re a large tech company. Your front-end of engineers want to build with GraphQL. Your legacy API is 80% REST with some SOAP endpoints strewn about. Who gets saddled with the job of building to the OpenAPI spec and why? Where is it creating customer value? You introduce it and then what, what value did you actually unlock from your customer ecosystem? I’m not saying that it doesn’t create value — but which stakeholders can you explain that to and how long does it take to convince them? On the other hand, if you start a new company, you’ll find that your API evolves organically. Locking yourself into a specification ahead of time is like writing all the unit and integration tests before a product ever gets in customer hands. Does anybody even want this? Are we even going to expose this API? What if we need to change it? OpenAPI isn’t bad — quite the opposite, it’s fantastic. When we encounter an API that adheres to the OpenAPI spec it makes our lives a lot easier. The problem is what I outlined above: for OpenAPI to permeate the market there has to be some sort incentive so powerful that it spontaneously aligns thousands of companies and millions of developers to accept it as the One True Specification. That’s just never going to happen. So “standardization” can only come from something that creates an economic incentive so great that everybody agrees to it without hesitation. Which is a Herculean effort; it requires something like a product that’s never existed before, or an entirely new class of web developer. When you start thinking down that path you start seeing through our eyes at Autocode. I’m not saying we have the exact right answer today, but I’m saying this is how we think about the space.
hypermachine 6y ago
Hi Keith, I still remember when Autocode was called Stdlib. I liked the old name a lot better :) For us at Hypermachine, we are tackling the problem by upgrading an existing low code platform - VB6/VBA. Our hypothesis is that pure no-code platforms are too limiting and inflexible for anything outside of the predefined connectors/widgets/use cases. There is a still a large gap between "call any arbitrary API and program" and "build a CRUD tool quickly". It is also a lot easier to convince users to use a platform that has been tried and tested for having a low barrier of entry than trying to teach full stack web development from scratch.

paulryanrogers 6y ago

My guess is the devil is in the details. And the more powerful and flexible the more consensus would be needed. Which can slow innovation. Still it kind of echos back to the semantic web. That could be a foundation to empower users and their agents to consume and produce in a more tool agnostic way.

heroprotagonist 6y ago

Check out OpenAPI. It's more than just automatic documentation and mocking/testing. Clients can write code to the OpenAPI spec and not necessarily worry about underlying changes to the target API unless they are significant (in which case they are likely versioned anyway).

keithwhor 6y ago
There are a lot of problems with OpenAPI that are more pragmatic than ideological. “If we build to this spec, we get all this for free!” is the dream. It’s not the reality. You’re a large tech company. Your front-end of engineers want to build with GraphQL. Your legacy API is 80% REST with some SOAP endpoints strewn about. Who gets saddled with the job of building to the OpenAPI spec and why? Where is it creating customer value? You introduce it and then what, what value did you actually unlock from your customer ecosystem? I’m not saying that it doesn’t create value — but which stakeholders can you explain that to and how long does it take to convince them? On the other hand, if you start a new company, you’ll find that your API evolves organically. Locking yourself into a specification ahead of time is like writing all the unit and integration tests before a product ever gets in customer hands. Does anybody even want this? Are we even going to expose this API? What if we need to change it? OpenAPI isn’t bad — quite the opposite, it’s fantastic. When we encounter an API that adheres to the OpenAPI spec it makes our lives a lot easier. The problem is what I outlined above: for OpenAPI to permeate the market there has to be some sort incentive so powerful that it spontaneously aligns thousands of companies and millions of developers to accept it as the One True Specification. That’s just never going to happen. So “standardization” can only come from something that creates an economic incentive so great that everybody agrees to it without hesitation. Which is a Herculean effort; it requires something like a product that’s never existed before, or an entirely new class of web developer. When you start thinking down that path you start seeing through our eyes at Autocode. I’m not saying we have the exact right answer today, but I’m saying this is how we think about the space.

hypermachine 6y ago

Hi Keith, I still remember when Autocode was called Stdlib. I liked the old name a lot better :) For us at Hypermachine, we are tackling the problem by upgrading an existing low code platform - VB6/VBA. Our hypothesis is that pure no-code platforms are too limiting and inflexible for anything outside of the predefined connectors/widgets/use cases. There is a still a large gap between "call any arbitrary API and program" and "build a CRUD tool quickly". It is also a lot easier to convince users to use a platform that has been tried and tested for having a low barrier of entry than trying to teach full stack web development from scratch.