
Show HN: Autocode – Automatically generate API code for SaaS apps - keithwhor
https://autocode.com/
======
keithwhor
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](https://www.youtube.com/watch?v=ha3C0X3Vyi0)

Thanks so much! :)

~~~
mclightning
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
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.

~~~
arxpoetica
Yes and no.

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.

------
crabasa
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/](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...](https://carter.api.stdlib.com/open-graph-
api@dev/api/?url=https%3A%2F%2Fgithub.blog%2F2020-02-12-supercharge-your-
command-line-experience-github-cli-is-now-in-beta%2F)

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
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.

------
avip
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
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!

------
_bxg1
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.

------
samblr
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.

~~~
keithwhor
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
>> 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!

------
Jiger104
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

------
SahAssar
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
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").

~~~
SahAssar
How would this work in languages where stdlib is an established way of talking
about the actual built in standard library like
[https://devguide.python.org/stdlibchanges/](https://devguide.python.org/stdlibchanges/)
vs [https://github.com/stdlib/lib-python](https://github.com/stdlib/lib-
python) ?

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

~~~
keithwhor
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?

------
smcguinness
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
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
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
Honest question: what would compel someone into making a decision like this?

~~~
keithwhor
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
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
(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
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...](https://www.twilio.com/blog/html-attributes-two-factor-
authentication-autocomplete)

Discussed on HN:
[https://news.ycombinator.com/item?id=22022106](https://news.ycombinator.com/item?id=22022106)

------
howmayiannoyyou
Excellent. I can FINALLY start migrating away from Zapier.

~~~
keithwhor
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
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
That's a _very_ good idea. We'll definitely be looking into it.

------
jedieaston
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
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](https://github.com/FunctionScript/FunctionScript)

~~~
eropple
Why should somebody use this instead of OpenAPI?

~~~
keithwhor
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.

~~~
eropple
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?

[0] - [https://github.com/modern-project/modern-
ruby](https://github.com/modern-project/modern-ruby)

[1] - [https://github.com/eropple/nestjs-
openapi3](https://github.com/eropple/nestjs-openapi3)

~~~
keithwhor
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 :)

[0] [https://github.com/keithwhor/nodal](https://github.com/keithwhor/nodal)

[1.0] [https://github.com/FunctionScript](https://github.com/FunctionScript)

[1.1] [https://github.com/stdlib](https://github.com/stdlib)

~~~
eropple
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.)

~~~
keithwhor
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.

~~~
eropple
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.

~~~
keithwhor
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.

~~~
eropple
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.

~~~
keithwhor
Alright.

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!

------
tylerrobinson
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.

~~~
keithwhor
Our team is literally itching to build plugins. E-mail us and let us know what
you want!

~~~
dijital
Would the Language Server Protocol make sense for your approach here?

[https://microsoft.github.io/language-server-
protocol/overvie...](https://microsoft.github.io/language-server-
protocol/overviews/lsp/overview/)

Really interesting concept for exploring a new API, but I don't see myself
dropping my IDE of choice for it.

------
gitgud
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!

    
    
        const lib = require('lib');
        lib.yourUsername.hostStatus(...)
    

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...

[1] [https://www.npmjs.com/package/lib](https://www.npmjs.com/package/lib)

[2] [https://github.com/stdlib/lib-
node/blob/bd7cada7ae366c10e316...](https://github.com/stdlib/lib-
node/blob/bd7cada7ae366c10e316795300078182700bd87b/lib.js#L31)

~~~
keithwhor
It’s referred to as a Proxy (type of Object) and they’re relatively
straightforward and a newer addition to JavaScript. :)

------
neeeeees
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
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.

------
zebnyc
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)

~~~
keithwhor
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.

------
superasn
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.

~~~
keithwhor
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.
:)

Coming soon!

------
veeralpatel979
Hey - great work! This project can save me a lot of work writing integrations,
which I find tedious at times, so I'll take a look at it.

One piece of feedback: it's confusing that the org's name is Polybit, the site
is [https://stdlib.com/](https://stdlib.com/), and there's also something
called Autocode.

Please consider choosing one name for all of them (Standard Library,
preferably).

~~~
keithwhor
Polybit Inc. is an implementation detail.

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 :).

------
Noumenon72
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?

------
leesalminen
Looks like a hug of death “service is unavailable” with an on-screen JS stack
trace.

~~~
keithwhor
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.

------
_bxg1
Wow, impressive that they got their hands on stdlib.com

------
zelly
Isn't this what GraphQL was designed to solve?

------
BillSaysThis
Where are the list of existing integrations?

~~~
keithwhor
You can view connector APIs at
[https://stdlib.com/search/](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.

------
jasonhr13
horizontal scrollbar showing on chrome

~~~
keithwhor
Do you mind sharing a screenshot and your Chrome version?

~~~
davidweatherall
Not the same guy but

[https://i.imgur.com/BspPL2H.png](https://i.imgur.com/BspPL2H.png)
[https://whatsmybrowser.org/b/JZAUZ62](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
Aha. So likely a Windows issue / those with visible scrollbars enabled? We'll
add this to the bugs list. Thanks for the info!

~~~
yoavm
Linux + Firefox too :)

------
codeulike
wsdl, right?

