Webshell.io: the shell for scripting and combining APIs in Javascript | Hacker News Reader

Webshell.io: the shell for scripting and combining APIs in Javascript

webshell.io

88 pointsmehdim33 comments

Open articleView on HN

Funny there is already a (less advanced) open source application that does this... with the same name :)

https://github.com/hbbio/webshell

Disclaimer: I'm the author of the open source webshell.

Nice to meet you ;)

We would be glad to talk with you.

Cool interface but I'm not sure what sort of value you're going for here.

Is it a set of APIs that make it easier to get stuff done in a repl? If so, it doesn't seem more useful than console so far (looking at the Google Maps and HTTP call examples). Or is it a lightweight IDE -- if so, would this be better done as a browser extension that could circumvent security restrictions? (and also operate on any document, including those served from localhost)

I really like it intuitively, but also, I don't get it.

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)

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

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

To put in a nutshell "the idea is more to be an IFTTT/Zapier for developers but without limited inputs and outputs by Graphical User Interface" ;)

This does seem to need more of a sell. Intuitively it feels cool - but then I’m not sure of what I’d use it for.

My first thought was that it’s the other half of the https://www.webscript.io/

The idea is more to be an IFTTT/Zapier for developers but without limited inputs and outputs by Graphical User Interface.

With the expressiviy of an all language as Javascript and a console interface to explore API and check easilty data response, developers may not be limited when combining APIs and make exactly what they wanted to do.

But Webscript.io is nice too, some similarities but not the same usefulness, not the same paradigm and not the same language : Javascript ;)

> The idea is more to be an IFTTT/Zapier for developers but without limited inputs and outputs by Graphical User Interface.

Is a great description - a very clear value statement there.

Thanks. We will use it to explain better the value next time. ;)

The prototyping shows an example with Twitter but the API Explorer doesn't have Twitter as an option, why not?

Also, with only eight services available having both Latest and Popular tabs in the API Explorer is probably premature. Until all the services need a second screen/page down just show Everything.

Use the hover event to show some sort of highlights box about the API, otherwise make the service icons smaller so more fit for page and at least use the Bootstrap tooltip component to show the service name.

Once you have more than that perhaps add tabs and show the four most recent additions as Latest as the second tab.

Once there are more than 30 or so Popular might be a useful third tab.

Price: What is this going to cost? Can't be free for all uses forever, even if that's true now so at least state that it's 'free while in beta' or similar. Most HNers will agree that a service that's useful is worth paying some amount for to ensure it stays around, after all.

Robustness: You aim to have developers build in a dependency on Webshell but have nothing posted about your infrastructure, uptime or security policies, not even links to privacy policy and terms of service pages.

Bottom line for me is that I think this is very interesting and potentially very useful but beyond using as a playground there's a lot of work yet to do before IMO there can be serious adoption.

Hey I think it's a great idea. I'm a developer evangelist at TokBox and I love playing around with APIs so I think I'll be using this tool quite often. Personally, I think you can create alot more value by opening up a platform so that API companies can write their own interactions into WebShell. This way it's more scalable and we'll be able to do cool mashups with other APIs.

Yes you're right, we are already working on this platform for easy API integration to Webshell. News about it soon.

But for the moment you can share with us your API by sharing a WADL of it and make a pull-request on our Github http://github.com/webshell

It is blasphemous to capture Command+L in a webapp.

I want a self-hosted version. Badly.

Seriously, if you sold this as software that I could run anywhere, it would absolutely make my day. The libraries you guys have written are seriously impressive.

You could use this kind of technology for a more meaningful way to teach code - when you're done, you've written yourself a website.

Also, providing an external "API to rule them all" would be pretty cool, as well.

We want to be an API of APIs, so we are an API for using and combining others ! api.webshell.io

In our doc , you can read how to already use it on webshell.io/docs/reference

  "In the programmable web where APIs lie,
  One shell to rule them all, one shell to find them,
  One shell to bring them all and in the cloud bind them"

;)

You can probably build something similar with eBay's ql.io and jsbin.

Typos, "program the web", I'm not sure what all this means.

edit: I think what we have here is a library that unifies a bunch of APIs, which is cool, and a programmable service which can run scripts for you. You offload API calls to to this service and then can call them from your app and get your customized data. That could be useful.

This is quite cool to play with - nice work.

May I suggest you give the tutorials a solid proof read? There are quite a few typos in the first few pages.

"This APIs is really simple" "Webshell make it simpler."

Also, waaaay too many smiley faces.

Great service guys! Good luck I think you are up on something big

Ahah, let me make Siri in 10 hours.

Nitpick: "example" is misspelled as "exemple" a bunch of places.

Mistakes between french and english. We fix it.

Looks promising. I am thinking to give this a try.

type that for me faster!

done. :)

Reply on news.ycombinator.com