If anyone has any questions about the software please let me know and I’ll do my best to answer.
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!
Looks interesting. I’m confused, though, about the logging limits. On the pricing page, it says “10 log entries per microservice” and in the docs, it says “fifty logging entries per hook”. Besides the different numbers (and different terms: “hook” vs. “microservice”), I’m confused by the limit. Is it a limit per execution of the hook, or a “lifetime” limit of that hook (which is what the cloud storage seems to indicate)?
Also, other similar tools (such as https://webtasks.io) support authentication, is that something on your road map?