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:
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.
UX feedback: Might I suggest that you zoom/crop for the last 2 animations on your front page? They are basically unreadable on a phone.
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.
We allow you to write your own APIs using serverless functions to define the endpoints. If you choose to implement a raw JSON pipe, you’re free to do so — the flexibility is unlimited!
Thanks, we’ll look into communicating this more clearly. :)
Really cool product and a well-done demo. I noticed that the autocomplete didn't work for the co2 service (e.g. host says "I think it's response.ppm" rather than ppm being suggested. This despite the co2 service (presumably) being developed and published with autocode as well. The pervasive auto-complete and composability make the offering really compelling, but it's unfortunate that (at least in that example) the two don't work together.
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.
This is pretty interesting! I've been working on a web scraping API that returns Open Graph information for a URL, and decided to see how easily I could build and deploy this using Autocode.
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
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.
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!
I've developed a personal sniff-test for software development work that exists right now but isn't actually very intrinsically hard. Those areas are ripe for products like this that simplify or partially automate the process. It was only a matter of time before "glue code" got streamlined.
It is not difficult to see there is considerable effort spent building this.
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.
No problem! It's not harsh at all. I think what a lot of savvy professional developers don't necessarily grok is that they're just the tip of the iceberg, or the top of the pyramid, in terms of the types of people writing and delivering solutions with software inside of organizations.
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.
Hi Keith, congratulations on building autocode. I'm by no means a naming expert, probably you should do the opposite of what I say. Also I know building stuff is hard.
But I feel that autocode is a weak way to name the product. If I am a business user, or tinkerer I would want the opposite of an autocode app. I wanted a solution of how to connect APIs. Or how to automate my processes. The name itself is pretty good tbh, but in my opinion it just doesn't speak to your core value proposition.
I think the real market for software like this is large enterprises. There are lots of part-time developers or folks that need things glued together. Solutions like this are quite attractive to those organizations because the limited technical expertise they have is focused elsewhere.
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.
As a power user of no code apps like zapier. This is really amazing, for some of the more complex work flows I've had to write python code and initiate via lambda functions. This seems like it would alleviate that need completely. Would love to see the ide support python as well as js
So, fun fact: our organization name is actually Polybit Inc. -- we do business as "Standard Library" because the registry we've built is pretty much core to everything we do.
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
We're not particularly concerned about typosquatting for now. The name is based on the `.com`, i.e. all APIs / workflows built on Standard Library go to `username.api.stdlib.com`. The packages we use in NPM, RubyGems and Python are just called `lib`.
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.
That’s great feedback, thank you! We’ll definitely see if we can test across a few different password managers / signup experiences to make sure it’s a smoother process.
You mean why would somebody build custom inputs? We need our inputs on Autocode to do a whole ton of custom stuff; support emoji insertion, allow for an autocomplete dropdown, support typeahead autocomplete, have multiple layers for syntax highlighting (code editor).
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.
None of those use cases apply for authentication though right? Or are people using emojis for logins now? Even if they were, standard browser form input I’m sure would handle them fine natively.
(1) Design systems and components. We'd rather use the same thing everywhere, if possible. (Unless of course, it disrupts user login and end-user experience... which is why we'll look into making it better!)
(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 :)
We'd love to help! Feel free to e-mail us (contact@stdlib.com) if you have any questions. We also have a Slack community that you can reach by clicking the Community -> Slack tab at the top of autocode.com. :)
Is workflow import on the roadmap if you’re authenticated to your low/no code provider? With many, you can get the workflow out as a JSON blob their own frontend consumes.
It's just JavaScript. It's absolutely portable. The APIs that run atop us use the Standard Library registry, you can think of it like a package manager / proxy of sorts. But if all you're doing is writing logic to connect things, you could conceivably host it on your own after you prototype with us -- you'll just lose some of the goodies we provide like automatic webhook signing.
Also, our gateway / schema specification is open source and portable as well:
They’re compatible. FunctionScript is just a system for easily adding schemas to JavaScript functions inline. We needed to write a specification that made it easy for people to build Serverless HTTP endpoints strictly from within JS.
That's not an answer, though. Why should somebody use any of this over an OpenAPI specification? I'm biased, as I've written two web frameworks that both generate OpenAPI documentation trivially and inline (for Ruby[0] and for NodeJS[1]), but I've looked pretty deeply into the project you're offering here and I'm not seeing the value over existing, open, collaborative solutions.
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?
Congrats on all your hard work! Those are some impressive libraries. I come from an OSS background, it’s what started all of this, so I appreciate the hustle and contributions! The project that spawned all of this was a Node.js framework for easily building APIs that went viral here four years ago [0].
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 :)
Thanks for the kind words. I don't drop those links to brag or troll for compliments, to be clear--more to establish bona fides. I've spent a lot of time building stuff for an open and interconnected web. I think you should be, too. But it looks like you aren't, and that sure seems like a real bummer.
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.)
This may be a little different than you expect: OAS didn’t meet our needs for defining serverless function schema semantics.
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.
Can you elaborate on how OpenAPI didn't meet your needs for serverless function schema semantics? Because if OAS3 doesn't meet your needs, it clearly needs revision. I'm very happy with my current gig, but I'd certainly be interested in contributing to the OpenAPI specification to be enable it to be flexible enough to express what you need it to express. The community of open and collaborative APIs doesn't need to be fragmented to do encompass whatever's concerning you, does it?
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.
There are thousands of companies with production APIs that don’t adhere to any specification, let alone OAS.
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.
As 'codegladiator indicated, OpenAPI is descriptive, not prescriptive. If you have an API that cannot be described in OpenAPI, that is a bug in OpenAPI. And personally, I've literally never seen an HTTP-based, non-GraphQL API that cannot be expressed, and fairly easily, in OpenAPI and even in a subset that can generate programmatically "acceptable" to "great" API clients in a variety of languages. Heck, it's not even that hard to make a RPC-based API with XML as its lingua franca work just fine in OpenAPI.
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!
This is really cool! As a PM I’m somewhere in your “100x other people trying to automate stuff” category of user. My question is, would many of your features work if provided as a plugin for an existing favorite IDE? Having to use the proprietary IDE would probably be my sticking point, as it’s not easy for me to understand how or if I could start using this with an existing project in VSCode, say.
Very cool product, and could be useful for learning also.
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.
I think you’re vastly underestimating the B2B API tooling space. Large enterprises and SMBs run tons of things atop SaaS APIs, often held together with staples and duct tape.
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.
Interesting project, I went and looked at the [1] npm module "lib" (side note: well done, you guys must have bought it as it was first published 9 years ago)
I saw in the API that you reference in the following manner, which stunned me!
How could you have a dynamic property on a synchronous object like that?! Well it turns out in the [2] source code, you can have some kind of "anonymous getter"?
get: (target, name) => {
return LibGen(...);
}
I've never seen this before and can't find any documentation about it...
Keith, do you plan to support other languages beyond javascript?
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)
Candidly: not immediately. There’s a lot of stuff we do that’s a Hard Problem (TM) to get working across a bunch of different languages, mostly associated with static analysis of code / Abstract Syntax Tree parsing. We’ve foregone multiple language support for now to focus on enabling people to be deeply productive with JavaScript by being highly opinionated.
Nice concept. Please think about adding a showcase to your homepage, i.e made with autocode. This will not only help it make it easier to understand but also show users the possibilities of what can be done with your platform.
It’s next on our list! We support deploying from GitHub already, we just had to chop a few desired homepage features to make sure we shipped this on time. :)
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 :).
So the idea is like, everyone who wants their app to integrate with Stripe has to write their own code that goes "response = /connect/to/stripe/${accountNum} + (json payload)", and this does that for you?
Try again? Everything is looking good for us right now. We run on entirely serverless architecture so any failures should be completely transient. I'll get my co-founder to pay attention and see if he notices anything out of the ordinary.
You can view connector APIs at https://stdlib.com/search/ -- if there's something we don't offer, you can build your own Connector APIs as well. Expect this list to grow substantially: part of our model is that we work with large API companies to ensure they're supported on the Standard Library registry.
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! :)