[HN Gopher] Show HN: Autocode - Automatically generate API code ...
___________________________________________________________________
Show HN: Autocode - Automatically generate API code for SaaS apps
Author : keithwhor
Score : 123 points
Date : 2020-02-12 08:29 UTC (14 hours ago)
(HTM) web link (autocode.com)
(TXT) w3m dump (autocode.com)
| jedieaston wrote:
| Can I run this code outside of stdlib somehow or does it only
| work there?
|
| Just have to plan around if stdlib went down or something.
| keithwhor wrote:
| 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:
|
| https://github.com/FunctionScript/FunctionScript
| howmayiannoyyou wrote:
| Excellent. I can FINALLY start migrating away from Zapier.
| keithwhor wrote:
| 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. :)
| toomuchtodo wrote:
| 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.
|
| Love the product! Very cool!
| keithwhor wrote:
| That's a _very_ good idea. We 'll definitely be looking
| into it.
| [deleted]
| avip wrote:
| Preliminary feedback: it took me 5s and single downscroll to
| grasp what this does and why it may be useful.
|
| In current climate this by itself is a remarkable achievement so
| wanted to point it out.
| keithwhor wrote:
| Thank you so much!
|
| 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!
| jasonhr13 wrote:
| horizontal scrollbar showing on chrome
| keithwhor wrote:
| Do you mind sharing a screenshot and your Chrome version?
| davidweatherall wrote:
| Not the same guy but
|
| 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
|
| and [control="LandingPage"] .platform-
| information .info-section
| keithwhor wrote:
| Aha. So likely a Windows issue / those with visible
| scrollbars enabled? We'll add this to the bugs list. Thanks
| for the info!
| SahAssar wrote:
| Dev1: "Is that in stdlib?"
|
| 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: "..."
| keithwhor wrote:
| 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").
| brundolf wrote:
| Wow, impressive that they got their hands on stdlib.com
| keithwhor wrote:
| Hey all,
|
| 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! :)
| ryanianian wrote:
| 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.
| keithwhor wrote:
| Thank you. It means a lot.
|
| 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.
|
| [0] https://github.com/FunctionScript/FunctionScript
| mclightning wrote:
| Very cool stuff, so I want to give some feedback hoping it will
| succeed :)
|
| 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
| keithwhor wrote:
| Thank you!
|
| 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.
| Jiger104 wrote:
| 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
| brundolf wrote:
| 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.
| leesalminen wrote:
| Looks like a hug of death "service is unavailable" with an on-
| screen JS stack trace.
| keithwhor wrote:
| 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.
| samblr wrote:
| 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.
| zerkten wrote:
| 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.
| keithwhor wrote:
| 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.
|
| Hope that helps!
| samblr wrote:
| >> 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
|
| 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!
| neeeeees wrote:
| 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.
| keithwhor wrote:
| 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.
| crabasa wrote:
| 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
|
| You can see the docs for this API here:
|
| 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.
| keithwhor wrote:
| Thanks for the feedback!
|
| 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.
| sarakayakomzin wrote:
| >CEO of Standard Library
|
| ah, so you're the asshole who has made things impossible to
| search for based on intention. Thanks for that!
| BillSaysThis wrote:
| Where are the list of existing integrations?
| keithwhor wrote:
| 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.
| smcguinness wrote:
| Very cool.
|
| 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.
| keithwhor wrote:
| 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.
| bestest wrote:
| Same here. Was expecting Safari to suggest a password, yet it
| did not. By inspecting the cause I was appalled to see custom
| inputs! Mother of dragons!
| chairmanwow1 wrote:
| Honest question: what would compel someone into making a
| decision like this?
| keithwhor wrote:
| 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.
| wise_young_man wrote:
| 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.
| keithwhor wrote:
| (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 :)
| presumably wrote:
| For (2), you may find the section 'Other useful
| autocomplete values' from this article helpful:
|
| https://www.twilio.com/blog/html-attributes-two-factor-
| authe...
|
| Discussed on HN:
| https://news.ycombinator.com/item?id=22022106
___________________________________________________________________
(page generated 2020-02-12 23:00 UTC)