
Show HN: Tyk – Open Source API Gateway written in Golang - jively
http://tyk.io
======
nodesocket
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.

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

~~~
zrail
$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.

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

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

~~~
jively
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?

~~~
bumelant
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](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...](https://developers.facebook.com/docs/graph-api/making-multiple-
requests)

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

------
pquerna
Have you looked at Vulcan Proxy?

[http://vulcanproxy.com/](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....

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

------
MoOmer
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!

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

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

~~~
erkose
Firefox-31.0 with no javascript.

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

~~~
zrail
There's more. On the marketing page:

"developers need ot <\-- eat too"

"API's" should not have an apostrophe.

~~~
jively
Fixed, thanks for the spot!

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

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

