
Webshell.io: the shell for scripting and combining APIs in Javascript - mehdim
http://webshell.io/home
======
hbbio
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.

~~~
mehdim
Nice to meet you ;)

We would be glad to talk with you.

Contact us team[at]webshell.io if you are interested :)

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

~~~
mehdim
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)

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

~~~
mehdim
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... ;)

~~~
jessedhillon
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._

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

Follow us, more examples soon.

Thank you for your advise.

------
nmcfarl
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/>

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

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

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

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

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

~~~
mehdim
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>

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

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

~~~
mehdim
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"
    

;)

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

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

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

------
gawenr
Ahah, let me make Siri in 10 hours.

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

~~~
mehdim
Mistakes between french and english. We fix it.

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

------
username3
type that for me faster!

~~~
mehdim
done. :)

