hook.io supports building webhooks and microservices in Smalltalk.
So we have SmallTalk as a Service.
Here is a quick demo:
How would you compare this to CGI/FastCGI? Also, you’ve got a name collision with the Haskell “stack” tool for dependency management.
I suppose this could be considered a modern CGI, but I never really had that in mind with the design. The interesting parts happen when you start developing better contracts between the HTTP APIs and the Process APIs. This can solve a lot of the issues that CGI/FastCGI has.
I follow this project on Github mostly because of my curiosity.
Does anyone actually use this here?
It seems like a really bad idea. The last thing I want on my command line is a tool trying to auto-correct my mistakes. Seems like it could cause unintended consequences.
The program does not auto-correct mistakes – you are required to actually confirm the correction before it takes any action.
However, as mentioned, it doesn’t execute corrections automatically. I suspect the risk of errors is still slightly higher than fixing the command manually, but well into “safe enough” territory.
Really cool! Someone added Romanian this morning!
Can’t wait to see what other contributions come in.
Excuse the nitpicking, but what’s the point in saying “i18n internationalization” when “i18n” is literally just a short form for “internationalization”?
Not everyone knows what i18n is. Maybe now they do!
YOU LIED, it says you have only added support for TEN programming languages. WHERE IS MY ELEVENTH LANGUAGE? Could I suggest BASIC? :D
Anyway – it looks pretty interesting, and having played around with Lambda, I’m super pleased that there’s other people out there thinking the same way and working on different variations and solutions in this space.
Constructive criticism follows.
your page doesn’t really look professional enough for the audience, in my opinion; if you found a way to hire a graphic designer to look more convincingly corporate and less back-of-the-napkin, it might help out.
And who is that audience anyway? The correct answer may vary, but my answer is “people who are streaming data from place X to place Y and want to do transform Z to it along the way.” You know – corporate types. What I bet it is not, is “people who know 11 languages and want that to be the primary selling point of the software they’re using.” You’re selling an integration nexus, but those sorts of things first have to work, and work well for the business case, and then go into the nitty gritty of how much support they offer to various languages once they’re closing the sale.
To that end, what does this integrate with? How do I get data in and out? What’s the SLA? What do you hook up with? How about encryption? SSL? Can you read the data when I send it to my process? If so, why the hell should I trust you? Does it work with ETL? How many processes can I run at once? What happens if the process gets stuck? Do I pay for time when events aren’t coming in? What’s the latency of the service? What’s the bandwidth of the service? What is this confusingly named ‘AGPL’ thing and why would I ever want to put that on my precious corporate servers?
On that last point – I do know what the AGPL is, but you should make clear: hook.io is dual licensed software. It is free to use and install, as long as any changes are freely returned to the authors for their use (including commercial use). Or, if you are a corporation that does not wish to obey those terms, hook.io is available under a standard commercial license for a fee.
You could probably do a lot better than node.js for the base language for this thing. Node.js is pleasingly fast at some things but it is pragmatically pretty bad at complex tasks involving possibly-blocking 3rd party language integrations. People at the kind of shops that might use Lambda are often grown up enough on the backend not to want to deal with node. Similarly, you can’t ship something based on Github Gists, as brilliant as that is (I had that idea too), because if github ever got mad, that would be bad.
You want non-HTTP integrations too. ActiveMQ, RabbitMQ, Kinesis or whatever. Plaster that all over the front page. That’s the important thing. Nobody cares about your implementation, people only care about how you are solving the actual problem they have.
“A featured section will be created on the hook.io website for all Developer Community Managers to optionally list their profile / website.” Don’t beg. It’s not seemly. Your thing is valuable, and you should be proud of your work so far. Don’t clutter up the value proposition with a bunch of unrelated featured nonsense just because some dude said he would maintain object pascal bindings for you.
All my thoughts only, intended constructively. Good luck!
Thank you so much for your detailed response!
I hear you loud and clear. I’ve brought on a really good really experienced designer as a co-founder. He should be starting next month.
Who are our target users?
Right now, we would like to first target beginner to intermediate developers looking for a quick and cheap way to host microservices. Perhaps even catch a few advanced developers who appreciate the simplicity of the service.
I’d be happy if we had 1,000 throughly happy developers each paying $5 bucks a month. From that base we can further develop the service.
Service Level Agreement
We currently don’t have an SLA. That’s a problem and will have to be resolved relatively soon. The service is actually built to scale and has shown pretty good performance so far.
I don’t want to make any promise I can’t keep. Once we have slightly better reporting metrics and deployment tools, I’m confident we can release an SLA that is accurate and suitable for business usage.
We do have SSL HTTPS communication and are working towards custom SSL certs.
The AGPL license is to protect the project and contributors. I’ve had bad past experiences in the past.
The majority of hook.io’s dependencies are already released as MIT. More hook.io components are refactored into MIT modules everyday. If the AGPL license actually starts to hurt the project, I’ll change it to MIT
What languages people care about?
That’s really only a question our users can answer. I can research metrics all day, but only real user usage will dictate what gets first class support.
I now have open github issues from two new developers this week. One is looking to implement better support for Python, the other Ruby. Moving forward with these implementations now.
I understand your concern for upkeep, but the upkeep is relatively low for me as project maintainer. The pattern for adding new language support is good. Join our IRC channel if you have questions about it.
If users want more features for a language, they are going to ask for them, and as I’ve already seen they will most likely help implement it themselves.
The real cost is confusion for new users by providing too many options or having a lack of documentation for a language. We can fix this with UX.
If enough users are willing to pay for full-featured scheme support, we’ll add it. As for SmallTalk, that was mostly an experiment. We have no further plans to develop.
Choice of node as base language
Do you mean the language it’s built with? I’ve been using Node since 2009 and know a lot of it’s ins and outs. I’ve gone into great detail to map the child process spawn lifecycle of node in order to get streaming support for 3rd party binaries.
Node has been a great tool to get us out the door.
Github gist is not mandatory. You can deploy from a code editor on the hook.io site itself. Github is generally great with this sort of thing. I actually have a dedicated support person at Github who is fully aware of this project for over one year!
You brought up Java a few times. Java is really the one can of worms I don’t want to support. Java will cause the most problems and support issues of any language. If someone is willing to step up and implement it I would consider it, but even that I’m hesitant to do. The entire software stack is setup to run scripting languages and not compiled languages. Adding support for Java / C / C# would most likely require a moderate sized refactor. We actually already have an open issue for this.
Thanks again for your feedback!
AWS Lambda looks really cool! These types of services are the future.
If anyone is interested in an open-source alternative to AWS Lamba ( with no amazon lock-in ) check out my project http://hook.io
I like the look of this but before I used it I’d have to understand more about how it works… how does it establish the connection to the external? is it ssh? is there some other protocol it uses?
As explained in the README file, natman uses Network Address Translation
What it does is open ports on the local machine?
(I expected it to be opening a tunnel somewhere somehow).
It might be a good idea to justify “down-votes” with a select box option.
For a user to down-vote a comment, a simple reason would be required.
You could also optionally justify “up-votes”.
Just a thought! :–)
You can already give a justification for downvotes of both stories and comments. Click any downvote button and you should see the menu drop down – you can click Cancel afterwards.
On the other hand, the possibility of up-vote justifications sounds interesting. I know one issue with Reddit that some people on Hacker News have is that too often, funny comments outrank insightful ones, and they’d prefer to read insightful comments. This way, “insightful” votes can automatically add more to a ranking than “funny”. Or perhaps it would be better to keep all upvotes equal by default, but let those people change their settings to tell the site how much they value each type of upvote – they might rate “insightful” as worth “2” and “funny” as worth “1” for their comment ranking.
For the record, as you didn’t mention it, the up-vote justifications (and down-vote justifications) are in play on Slashdot, so you can differentiate between insightful (good argument), informative (new information), and funny (obvious). (There were probably more options, which might be interesting to check out if you care about thinking more on such a feature.)
One more interesting note about /.: Funny comments do not give you karma. “You have to be smart, not be a smart-ass.”