Hacker News new | ask | show | jobs
by aaronem 4120 days ago
Maybe I'm missing the point here, but I'm not entirely sure I see the point here.

What can Templar do for me that, say, nginx can't? All else equal, if nginx is already in my stack and Templar is not, why do I want to adopt Templar, or indeed even look twice at it?
1 comments
evanphx 4120 days ago
A great question. Nginx is not typically configured as a normal proxy but it can certainly do it. A difference is that Templar gives you control of options applied to each request differently rather than the same the same to all.

From timeouts to caching, one Templar can be used for all different kinds of upstream APIs.

link
aaronem 4119 days ago
Well, if it's worth adding a whole new layer to my stack to deal with this kind of stuff, surely it's even more worth extending an existing layer to deal with it; as a corollary, if I know enough about the problems I'm having to know what I need Templar to do for me, then I know enough about them to know what I need nginx to do for me, too.

Again, though, maybe I'm just missing the point here. Perhaps it would help to know what use case prompted Templar's development.

link
falcolas 4119 days ago
In my opinion, the draw is the ability to use it when connecting to third party endpoints (so you can't control how they cache or how they respond) with third party libraries (which means you lack fine grained control over timeouts and caching on your end).

Personally, I'd rather gain the necessary control through the request mechanisms, but for a quick-and-dirty solution, this would probably work pretty well.

link
evanphx 4119 days ago
It's very true that things like timeouts are done better within the client library. But Templar can combine timeouts with caching, allowing an API to appear to still be active and returning something even when it's just very slow.

Because a cache is best when it's populated often, it make sense to put that into a service that many different processes on different machines can use.

Everything within templar can be done by adding capabilities to client libraries, no argument. But most client libraries don't provide these capabilities in one programming language, let alone many of them. By having the functional available as a service, Templar provides these capabilities fairly transparently (and even more transparently in the future when there is per/host and per/url configuration).

link
evanphx 4119 days ago
That assumes nginx has the capability to do what Templar does and I don't believe that's true.
link