Show HN: Autocode – Automatically generate API code for SaaS apps
autocode.com
autocode.com
Keith here, founder and CEO of Standard Library (we made this <3). The problem we're focused on solving is simply -- building modern integration software is too difficult. (1) For professional engineers, it's mundane work nobody wants to do and (2) for non-developers, best-in-class integration tools that rely on visual workflows just don't cut sophisticated use cases for modern businesses, they often need some code.
Autocode solves these problems by providing an IDE that professional engineers can use to ship simple integrations in minutes and new (or "low code") devs can use to automatically generate API integration code without needing to know much to start with. We provide a ton of features: an API registry, API autocomplete, code generation, serverless hosting for your APIs, an in-browser execution engine for your workflows, observability + logging, complete revision history. It's kinda like Heroku and Zapier had a really, really ambitious child.
We've been at this, somewhat quietly, for four years and Autocode is what we're the most proud of to date. We've been very fortunate to have the opportunity to work with some of the best companies in the industry to support our vision -- Slack and Stripe have been investors since (nearly) day one. That said, we're a small team -- just five people -- and we still have a hell of a lot of work ahead of us. We would love thoughts and feedback!
YouTube video here for anybody that wants to see the full demo:
https://www.youtube.com/watch?v=ha3C0X3Vyi0
Thanks so much! :)
1 - Some playground prior to signup, similar to Runkit could get you more users.
2 - Some simpler signup by Github etc. would get you more users.
3 - Right click is taken over by the site, which blocks LastPass context menu which adds another layer of difficulty to signup.
Good luck, thanks
Ooh! Right click / context menu. I gotta fix that. D'oh.
I think there are different schools of thought re: providing a playground. We certainly have done that before with smaller launches. Our experience (anecdotally, I haven't measured exactly) is that while "playground" type experiences can sometimes increase signup volume, they tend to result in lower engagement rates overall.
I believe the basic underlying hypothesis is that if you can solve a problem somebody is having and they know that, they don't care how it works: they'll sign up and figure it out. However, if you provide a playground, you artificially select for a much higher proportion of folks who enjoy the novelty of new technology / products and aren't necessarily likely to stick around.
Food for thought, anyway. Don't have raw numbers here.
This particular product probably has broader appeal than you think—
For a broader audience you'd definitely want to dumb down the entry point. If you're still in the smaller audience/specific traction stage, it probably makes sense to stay more technical.
On a related note it would be lovely to use (or allow) typescript and publish TS declaration files and thin generated clients for APIs deployed on autocode.
These are both minor nits in an otherwise impressive offering. Both are likely "next iteration" features since it seems like you've already solved a lot of the hard problems and these would be connecting existing dots together.
The reason `result.ppm` didn't autocomplete was because I didn't specify a return schema when I built the service. It's up to the developer who builds the API to specify nested object schemas via the FunctionScript specification [0] and I hadn't. It was a long day and I didn't feel like re-recording the entire video. :) Long way of saying -- it'll work if you want it to.
TS could be neat, it's conceptually not difficult, the question of implementation is ultimately: where does our team's time go as we continue to roll out features for business users? About half of our users are not professional developers so balancing between pro / not-pro is part of what makes our roadmap planning interesting.
I'm also having trouble grokking what "build your own connector apis" is supposed to mean. I'm assuming you have more detailed docs/posts explaining your value pitch here, but I don't see any links to them on the page. Are you providing a nice wrapper over oauth/saml sso handshakes? Are you just opening a raw json pipe? I truly have no idea.
Thanks, we’ll look into communicating this more clearly. :)
In about 15 minutes I ported the code I had written to Autocode. A few things that felt pretty magical:
- auto recognized and imported required NPM modules to my project
- ability to run code in-line (via Runkit)
- auto-generated documentation
https://stdlib.com/@carter/lib/open-graph-api/
...and can see an example API GET request which returns the Open Graph information for one of the top stories on HN today:
https://carter.api.stdlib.com/open-graph-api@dev/api/?url=ht...
I'm pretty curious to see where this product goes! It would be super cool to be able to easily tack on auth and a pricing model for heavier (enterprise) users of this API.
We do indeed have custom auth and pricing in the works :). Can’t give an outline on delivery because we have so much other stuff to take care of, but the API registry is already built to handle these use cases.
In current climate this by itself is a remarkable achievement so wanted to point it out.
I will say it hasn’t been a small effort. We’ve been working on the suite of products that have led up to Autocode for years. At this point I’ve personally done hundreds of 1 - 2h sessions with customers to figure out what works and what doesn’t, and I think that has sort of enabled us to focus on the features that matter and why they’re important.
As you play around, I’d be interested to learn what you like and what you think is missing!
However, why would anybody use it ? I see following issues
- Editors are getting mighty powerful. So why would a developer trade their favourite tool to your editor in browser ? I wouldn't switch to another editor even somebody is going to pay me more.
- The process-and-cost of deploying backend has gotten way easier-and-so-cheaper - why would anybody write trivial code in autocode and then deploy on your servers ?
Having said the above - I liked autocomplete provided for different apis in your editor. Sorry, if that was harsh.
The process and cost of deploying backends is still significant for them. It is only a mostly solved problem for startups and medium-sized organizations. There is validation for this with Microsoft's "Power" platforms (Flow, PowerApps, etc) effort. This tool seems to have attached itself to competing platforms (Slack, etc.) Right now, an enterprise customer probably wouldn't get all of the pitch since the examples don't tie together their boring tech, but I guess the pitch is that they'll invest in that later.
Let's say BIGCO pays you $X00k to build big, awesome production systems. There are 10x as many professional developers as you building small, hacky transient code within enterprise cos and SMBs and 100x as many tinkerers, creatives, admins, product managers and more just slapping together Airtable and Zapier as fast as possible to automate their jobs.
Autocode isn't designed for the top of the pyramid. I mean, all the features can (and should!) certainly be used by folks at the top. You'll find that for a huge # of simple tasks -- tasks that don't matter where they live, like one-off daily crons -- Autocode is just plain faster. But the important thing to think about is the folks a bit downstream of the "top", the ones implementing solutions less focused on architecture and more focused on solving immediate business problems... that's where Autocode is designed to play well.
Hope that helps!
This is what you are building. Perhaps title of post is totally misleading/off-putting - 'Automatically generate API code for SaaS apps' ?
Title could have been easily 'A serverless platform with zapier abilities' ? :) - could you argue why autocode is not ? :)
Getting your message to early adopters is so important.
I hope it helps!
Dev2: "Yeah"
Dev1: "Then why isn't it working?"
Dev2: "Because unlike EVERY OTHER THING called stdlib you need to install this one because it's not actually a stdlib"
Dev1: "..."
I expect the easy way to get around this is for folks to refer to us, when speaking technically, as "stdlib.com" ("standard lib dot com").
Also you aren't worried at all about confusion or typosquatting (or what you would call it with a common name) with all the variations of standardlibrary, standardlib, stdlib?
The npm package name standardlibrary was open, let me know if you want it transferred. No charge or bullshit, of course. I just claimed it because it was free and I guessed that somebody would typosquat it sooner or later considering your company name. If not I'll just release it
The way 99.99% of developers have used us to date is starting with our in-browser or CLI tooling which installs / requires the correct package automatically. So I think that removes some of the risk you're talking about. :)
You can hold on to the NPM package for now if you'd like! That's a good one. If we do find typosquatting becomes an issue, do you mind if I reach out?
I just signed up, but was a bit frustrated by the hijacked experience for sign-up as it broke my LastPass plugin to generate and save my password. Just wanted to point this out.
So we roll our own components for a lot of this stuff. We don't have problems with every password manager; the raw HTML input element is still there. I think it's probably an easy fix, we just gotta look into it.
(2) I actually think this can be fixed with a few HTML attribute changes but I won't know for sure until I dig in. If you can imagine, we have a laundry list of items piling up to take care of :)
https://www.twilio.com/blog/html-attributes-two-factor-authe...
Discussed on HN: https://news.ycombinator.com/item?id=22022106
Learned a lot
Love the product! Very cool!
Just have to plan around if stdlib went down or something.
Also, our gateway / schema specification is open source and portable as well:
I have a strong interest in APIs being very good and very accessible (as those links hopefully demonstrate), but I also have a very strong interest in APIs not being intermediated unnecessarily. What does any of this do that can't be effectively done with current, broadly accepted technologies?
Put another way, and forgive the bluntness: why should people give your company a vig for this?
If it helps clarify, Autocode is for people looking to solve integration problems (A to B) for businesses easily. We can talk all day about which specification we use, but that argument is adjacent to the fact that the combination of tools we offer are faster by one — if not two — orders of magnitude at just delivering business value — a finished software product that connects A to B (to C to D).
We’ve spent years of work developing this tooling and thousands of hours talking directly to both API companies and end-users about what they need. This is the result, and we’ve worked at making sure the tools we use — even if bespoke — are open source for others to learn from [1].
P.S. If this is your jam, reach out! We are hiring :)
[0] https://github.com/keithwhor/nodal
I get that it's both unsexy and probably a little uncomfortable, but the thing is, the demand for control that you're expressing here by going against open and collaborative standards really and truly does matter. Like--fundamentally and inescapably, the messaging I'm getting from you is "it's 'open source' but we demand to own it." Why do you need to own the specification to do what you do? What is OpenAPI stopping you from doing? Did you try to work with the OAS folks to improve it to enable whatever (if anything) can't be expressed? Did you evaluate stuff like vendor extensions to it to express those things?
I get that the core of your Standard Library is open-source--but "open source" and "community collaboration" are pretty far apart. I understand the process for OpenAPI's evolution and change over time. What's yours? Whose commits get in? Who decides?
I realize that the likely answers to these questions are trivial in the power-politics/realpolitik sense. Which is why my hackles are up, TBH. Not playing in the sandbox with all the other kids is a clear indication that you have it in you, whether you are or not right this second, to raise barriers to entry against anyone else who'd consider doing something with your tech. And that leads to a fragmentation ("welp, we'll have to fork") that this space well and truly doesn't need. If this was using standard tools and standard approaches--which all totally work with this, by the way, I've written a simpler but spiritually similar thing just by using openapi-js to dynamically generate clients--I'd be cheering you on. As-is? This sure looks like pissing in a community pool for your own benefit.
How am I wrong? (Because, to be clear: I'd love to be. Stuff like this is important.)
We considered an open approach, but we then watched numerous small companies die trying to convince standards bodies to adopt their innovations. Like, raised money, convinced nobody, stagnated or died, and highly paid engineers at BigCos that were unintentionally unempathetic to the excitable new founders — whose dreams just evaporated in smoke — kept attending open spec design-by-committee meetings with little forward progress.
So we decided to work directly with API companies — not standards bodies — and figure out how to deliver the right product(s) to solve real customer needs.
That’s all there is to it. We stand on the shoulders of giants and we certainly love working with companies that adhere to existing standards — as mentioned, the things we’ve contributed are completely compatible! We don’t have an ego about our specifications, we just have a desire to deliver value and not die — and waste the most productive years of our lives — waiting on standards bodies.
I'm happy to make that offer because, frankly, I have also spent a pretty long time observing the OAS3 work, and it is not a committee where things get "bogged down" for years. The characterization strikes me as pretty unfair--the prevailing attitude certainly seems to be open, inclusive, and driven towards solutions. Everyone wins when the OAS stuff gets better, so the drive is to just do that. It's not an XML standards body or something.
Beyond that, OpenAPI certainly doesn't require a company to adopt a single thing about it in order for somebody to write a spec and to generate a client from that spec. It helps, but there's no need to advocate anything. It sounds like a misdiagnosis to claim it as the reason a company would fail as an integration partner given the significant help that being able to work directly with that company actually is.
Tearing down OAS for what have to be pretty minor flaws (and I use "minor" judiciously; if they're impactful upon "serverless function schema semantics", it's a niche of a niche--and AWS's API Gateway sure doesn't seem to have a problem building OpenAPI specifications off of serverless functions, either via import or export) and a downright fictional characterization of the process of its evolution is really unfortunate.
On top of that, Companies that were considering OAS now have GraphQL APIs instead — or even JSONAPI. When we need to respond to the needs of one of these companies, we need to move quickly.
I think we’re just comparing apples and oranges. We’re working on solving API integration issues in a real way, which means we build the tool for the job. OAS is an idealized, democratic position that — while absolutely a best -in-market solution — does not directly and meaningfully incentivize companies to rely upon it.
OAS is not a specification to adhere. It is a specification to describe.
> OAS now have GraphQL APIs instead — or even JSONAPI
OAS is orthogonal to GraphQL/JSONAPI. With OAS you describe what the API is which could be JSONAPI or some custom API adhering no standard.
Now, you're correct about GraphQL, but it's also apparently not super relevant, as the APIs you're trumpeting on your site are overwhelmingly either RESTful or adjacent to RESTful. But even so? You could pretty easily have vendor extensions (`x-` properties) for GraphQL--ones that in the future maybe even become canonical ones!--in OpenAPI while using it for standard APIs, an approach whose deficiencies you've consistently chosen to retreat from after you state them.
This fundamental misapprehension about specification versus description, and the way you dropped your "serverless function schema" claims like a hot rock (and I want to underline that the offer to work to improve OAS wherever it happens to lack is genuine and is work I am very happy to do) and the absolute unwillingness to address any question that touches on your obvious attempts at barriers to entry, frankly, makes you think you're just bullshitting me.
I'd like to wish you well, but you have demonstrated to my satisfaction your intent to piss in the public pool for your own benefit. I wish you wouldn't be so bound and determined to do so.
To be direct, I don’t really understand your criticism — we’re a small team working like crazy to create value for folks. I get that you don’t like the way we’ve implemented our own specifications, and that’s okay, but to be honest I’m a little offput that you’re accusing me of bullshitting when I believe I’ve been straightforward with you.
If you’d like to use the product / platform and work with us to make things better, we’d love the support!
https://microsoft.github.io/language-server-protocol/overvie...
Really interesting concept for exploring a new API, but I don't see myself dropping my IDE of choice for it.
I suspect the fundamental [business] limitation of a tool like this is that those willing to pay recurring big bucks (medium to large software shops) tend to rely minimally on 3rd party APIs.
Those who benefit the most (weekend projects, learning, rapid prototyping) where time is of the utmost value generally wouldn’t end up using it enough to become recurring customers.
We have businesses that run on top of us today that are only just beginning to automate huge chunks of their operations with us, Airtable, Slack and other tools. Previously these things were hacked together in an unmaintainable fashion. It’s a big space.
I saw in the API that you reference in the following manner, which stunned me!
const lib = require('lib');
lib.yourUsername.hostStatus(...)
get: (target, name) => {
return LibGen(...);
}
[1] https://www.npmjs.com/package/lib
[2] https://github.com/stdlib/lib-node/blob/bd7cada7ae366c10e316...
This brings me back to 2004 when I used to work for Safeco. Business analysts / insurance agents would write business rules in VB.NET. Engineers would write application / integration code which would execute the business rules (both languages compiled to the .NET runtime so were compatible)
Coming soon!
One piece of feedback: it's confusing that the org's name is Polybit, the site is https://stdlib.com/, and there's also something called Autocode.
Please consider choosing one name for all of them (Standard Library, preferably).
Standard Library is the platform / registry and Autocode is the IDE. We’ll keep these two. Outside of legal docs and filings you probably won’t see Polybit that much at all :).
https://i.imgur.com/BspPL2H.png https://whatsmybrowser.org/b/JZAUZ62
Appears to be caused by using 100vw, which doesn't factor in the width of the scrollbar.
Notably on the selectors:
[control="LandingPage"] .hero-header
[control="LandingPage"] .platform-information .info-section