Templar: A proxy to improve HTTP API interactions • Hacker News Board

Re: Templar: A proxy to improve HTTP API interactions

#21

Post by evanphx » Thu, Mar 05, 2015, 5:14 PM UTC

jfindley wrote: post #16

The HTTPS implementation looks dangerous at first sight - it looks like an attacker could very easily just strip the X-Templar-Upgrade out from the request, and then end up with everything being un-encrypted - without the client throwing any warnings. Could you possibly provide more details of how you avoid this?

Templar is designed to be used within your own infrastructure on a trusted network, where you talk to it and it talks to the outside world.

An attacker would have to be already within your private network, and if they were, they could observe the traffic in plain text already.

I think the confusion is around where Templar sits in relation to your app making HTTP API calls and the services you want to talk to. I'm going to draw up a diagram to help explain this better.

Re: Templar: A proxy to improve HTTP API interactions

#22

Post by evanphx » Thu, Mar 05, 2015, 5:15 PM UTC

VeejayRampay wrote: post #17

Note that this is by the excellent Evan Phoenix, creator of Rubinius, the Puma concurrent web server for Ruby and tons of other awesome projects.

Thanks Veejay!

Re: Templar: A proxy to improve HTTP API interactions

#23

Post by evanphx » Thu, Mar 05, 2015, 5:17 PM UTC

paulspringett wrote: post #18

The caching part looks really interesting -- have you considered adding support for more fine-grained caching control, such as respecting etags and last-modified times? Thanks for sharing this!

Yup! That's on the todo list. Auto-caching, as I'm calling it, would figure out a how long to cache something for and then be able to later on use HEAD to check if the url in question has changed.

That cache time could be as long as 5 seconds, so that Templar is checking pretty often if the upstream has changed.

Re: Templar: A proxy to improve HTTP API interactions

#24

Post by evanphx » Thu, Mar 05, 2015, 5:18 PM UTC

ing33k wrote: post #15

Request collapsing looks like a nice feature . Regarding HTTPS support, I am not really sure if I understood the details mentioned in the Docs properly . Does Templar implement SSL Termination ?

Templar does not do SSL termination because it does not terminate requests for your api. It's designed to mediate connections between you and any APIs that you use, protecting you against those APIs being unreliable.

Re: Templar: A proxy to improve HTTP API interactions

#25

Post by evanphx » Thu, Mar 05, 2015, 5:20 PM UTC

aaronem wrote: post #19

evanphx wrote: post #9

Earlier quoted context omitted.

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.

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 t…

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

Re: Templar: A proxy to improve HTTP API interactions

#26

Post by evanphx » Thu, Mar 05, 2015, 5:24 PM UTC

falcolas wrote: post #20

aaronem wrote: post #19

Earlier quoted context omitted.

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 t…

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.

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