Looks awesome, but curious if you are going to continue to support and develop Tyk? It seems like it was a side/weekend project. If we are going to integrate this in-front of our API (expose to our paying users), we have to have confidence that you can continue to support, maintain, and handle our traffic.

Frankly, instead of TYK CORE & DASHBOARD being free, make it $12 a month. That gives us confidence you can continue to iterate and improve. We are interested in chatting further and willing to pay. By the way, I read the $150 plan as per month, and didn't really flinch, then I noticed that it is $150 per year. You are significantly under charging.

Thanks - it's not a weekend project and has taken quite some time to build - part of the reason for making the core app open source was to ensure that it could be easily supported long term and empower end users.

With regards to price - we are offering the dashboard for a price, the main application that your users will interact with is completely free, so we're charging what we feel is a fair rate for a piece of software you may use for quite some time...

Maybe if we end up with a hosted service we'll look at higher monthly pricing.

$150/year is not a sustainable price for the market you're operating in. You could and should quintuple your price. This looks like an excellent product and would basically be a core component of any business that chooses to use it.

You should want the kind of customers who don't blink at $750/year, because those are the customers that are going to be ravenous about your product and will continue to pay year after year.

Solid advice. There's an argument for going after large customers and in this market that seems to be the way things have gone. Everything is big enterprise, if not now it is somewhere we are looking to enter once we are ready.

Are you the only developer on this? If that is the case, this is pretty impressive, as you did both the front and back end; along with the business items.

I am, it's me and my business partner - she takes care of the financials / legals, and is the voice of common sense and reason. I handle the dev (with a bit of help from bootstrap).

You could 10x your pricing and likely still be lower than all of the commercial API management tools out there.

We ran the site for two years, it wasn't competitive to keep running.

Agreed -- I read $150/month and thought it was reasonable.

Please consider charging more :)

Are you using something else in front of your APIs?

Nope - they are pretty raw, we leave that up to the person installing the kit - Tyk isn't a service, it's a piece of software to run on your own infrastructure so that your sysops can lock it down however they see fit, like NGinX. You could go meta and put Tyk in front of the Tyk API's, and lock that layer down. though I'm not sure what that would achieve...

Looks great! Is it possible to aggregate a bunch of requests into one (and get a single response with multiple responses)? This is a common pattern and sometimes very useful in web app scenarios to limit latency issues.

Not at the moment, but it can certainly be added.

I assume you mean some kind of pipelining so that if multiple requests that have the same signature come through then only one gets executed and the response is shared amongst all the requesting clients without them ever touching the underlying application?

This could be an interesting use case indeed, but what I need is more like what's described in this paper http://www.infoq.com/minibooks/emag-microservices Page 8. So the usecase is - you have a client that has to call say 8 microservices, but doesn't want to invoke them one by one or in pararell due to nature of HTTP protocol. Rather it wants to execute just 1 request with 8 calls (batch them) and get returned single response that encapsulates 8 responses.

This is for instance how facebook does it: https://developers.facebook.com/docs/graph-api/making-multip...

Got it, yes that would indeed be very useful for heavy-use APIs, and shouldn't be too much of a problem to implement. However it would essentially add a default batch endpoint to an API which isn't defined by the owner. Also, certain things like maximum batched requests would need to be implemented. Also, how would this affect quotas and RPM? Many questions, but well worth investigating, will add to roadmap.

Have you looked at Vulcan Proxy?

http://vulcanproxy.com/

It doesn't have the SaaS thing y'all be doing, but the APIs and structure of the proxy seem pretty well thought out....

Took a closer look at this today, it really does look incredibly flexible, interesting to see how easy it is to add middleware to an endpoint stack.

This might be an approach for us if Tyk functionality expands beyond an API Gateway and adds more reverse proxy features, though I feel this might muddy the waters.

Adding IP-based request limiting to the roadmap.

I haven't, we'll check it out. Though Tyk is not a SAAS, it's meant to be self hosted :-) (though it could be a SAAS if you configure it right. In fact it has design implementations for just such a purpose...

Interesting - A pal of mine was working on one of these in Go as well for his organization; I was contemplating writing one in Go also.

I was your first star; but have no time to look at the code in depth yet!

I find it difficult to compare features as the rows are not aligned.

Really? For me they are all aligned, with the exception of the REST row which isn't present in the basic level.

Firefox-31.0 with no javascript.

In your Readme.md: "We are orking to increae test coverage of features" Do you mean "working to increase"? :)

There's more. On the marketing page:

"developers need ot <-- eat too"

"API's" should not have an apostrophe.

Fixed, thanks for the spot!

Keyboard fail...

You have <meta content="Bootstack - Bootstrap 3 Theme"> still.

Thanks, will pull the boilerplate out... Eek!