Hacker News Reader

Comment by mehdim | Hacker News Reader

Our idea is to help web and mobile developers

- to sandbox API workflow (server-side APIs and/or client-side APIs) into the REPL interface "prototype"

- and then create a new API based on this API workflow(or "prototype")

- use this new API in production into their own application and share it with other developers

we want to bring fast API discovery and exploration, easy multiple API mashups or scripting, then new API creation for use in production. We make for them maintenance, and one-line-of-code authentication and some cool builtins.

This with server side APIs as Client side APIs, in the same shell interface, Javascript, Coffeescript, or even Typescript.

But is seems not obvious apparently... ;)

Can you share with us what and why you did'nt understand it when testing the tour?

PS: Everybody can also brings to Webshell API explorer its own API (you can read the doc on how to add your own API to be scripted and used by developers)

View on HN

Ok, but why should I use your service instead of writing JavaScript in Vim? Apart from the fact of seeing the output more or less on the fly the result is the same (but I'll never abandon my editor for that).

What do you mean by "to sandbox API workflow"?

Why should I get a script from your server in my production application instead of serving it myself? It's one dependency more.

The only real value i see is the fact of having a library that gives me some syntactic sugar to query third party apis (like twitter, foursquare, gmaps, ...) but for that I would need only a very little part of your service, and maybe I'd prefer an open source solution.

I like that you can use their API keys for low volume/one-off queries, then add your own on an as needed basis as your volume increases

You can use it as an IDE but it’s not the Webshell’s job ! Our job is to make an “API mashup factory” for people which want to make fast applications based on APIs.

It would be impossible to make a lib which maintain all third party APIs (arround 8000 today), it’s for that we made it as a platform where everything is always working.

Please note that Webshell is an API too, and you can call scripts as a REST/JSON API.

“Sandbox API workflow” : we have a REPL prototyping part for helping you to see very fast a result of API scripting results, as for server side API (Facebook, Spotify...) as for Client side (GoogleMaps, Youtube player etc...)

After you have two choices.

- Make it again by yourself, with the different API protocols, Oauth1.0 or Oauth2.0 , manage rate limits and keep an eye for maintenance on all your APIs in your application.

- Or push the “create API” button on top right of the Webshell prototyping REPL, so generating a new API of your mashup, use it in production and share it with other developers which would like to use it too.

Our job is to keep an eye for you on API maintenance, easy Oauth integration, APIkeys and rate limit management, analytics. We will be implement each feature step by step during the public beta.

Dependancy? We are an API like other APIs. We behave like Back-end-as-as Service as Parse for example. You could do it yourself to not be dependant, but if you implement it fast for your application, with lot of integrated tools, you will keep it in production.

You can see us as a kind of API-as-a-service backend... ;)

I think you need more examples of something complex that is made easily accessible. And show some of the advantage involved in using you as an API around third-party APIs.

Plainly, show, don't tell.

We are working on it. We gived some explanations because each people wasn't not understanding the same value, we are in a step by step explanation of what we've done.

You're definitively right.

Thank you for your advise.

some feedback: The homepage is visually cluttered. it took me a while just to parse the page and figure out what I'm supposed to do. even now that I do know what the page is about, my eyes still don't know where to look.

"Currently, you are in a shell that allow you to program the web in Javascript, Coffeescript or Typescript!" is an unnecessary detail. Just say "javascript* repl" and "*also runs coffeescript & typescript" at the bottom of the page.

I don't think the byline is working. I do a lot of front end work and have used a lot of these apis. "the shell for combining web apis" isn't putting a clear image into my mind. I don't know what it means to "combine web apis", nor do I know why I'd need a shell for it. Something like "the easiest way to work with popular web APIs" might be better--even though it is less technically accurate, it has a few advantages.

   - it gives me a concrete idea that my mind can latch onto
   - it piques my curiosity. "oh neat. why is this the easiest way to do XYZ?"  
   - it gives me a framework from which I can evaluate the rest of the page.

Thanks for this feedback! I love the "easy way to work with popular web APIs". We changed it ;)

How do I use typescript? I seem to be getting syntax errors.

Reply on news.ycombinator.com