Viewing profile — evanphx
evanphx
HN member- Joined
- Wed, Mar 10, 2010, 2:27 AM UTC
- HN karma
- 434
- Public activity
- 81 items
- HN profile
- View on Hacker News ↗
About evanphx
No profile information was provided.
Recent public activity
-
comment
Comment #48942563
The honest answer to your question about where the line is: it's when you start writing your own health checks, restart logic, and deployment orchestration on top of compose. That'…
-
comment
Comment #47876871
If you're open, love to get your thoughts on https://miren.dev . We've doing similar things, but leaning into the small team aspects of these systems, along with giving folks an op…
-
comment
Comment #47876824
Are you doing that across a fleet of machines or just one?
-
comment
Comment #47876789
Totally, it's all about the primitives. I'm curious where exe.dev is gonna build on the the base, or just leave it up to folks to add all their own bespoke stuff to do containers, …
-
comment
Comment #43572334
Agree and so I went looking and here is the reason: https://github.com/InitWare/InitWare/commit/3ee721035525dbb1... . They started with a specific version of systemd and have been …
-
comment
Comment #40460396
Upon hearing this (and seeing the software that you've got listed on the website) I went and bought one. Looks great!
-
comment
Comment #29194103
Hi, Evan Phoenix, Rubinius creator here. I just wanted to stop in and say thank you for this comment. It means a lot to me, even after all these years that Rubinius helped you out.…
- story
- story
- story
- story
-
comment
Comment #9152213
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 …
-
comment
Comment #9152183
That assumes nginx has the capability to do what Templar does and I don't believe that's true.
-
comment
Comment #9152163
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 …
-
comment
Comment #9152153
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 quest…
-
comment
Comment #9152127
Thanks Veejay!
-
comment
Comment #9152119
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 wit…
-
comment
Comment #9149725
Ah! Ok, I got it. Feels like the right way to handle this is the allow a blacklist to be defined via config file, then applied as request, something like "X-Templar-Blacklist: inte…
-
comment
Comment #9149627
Looking at that CPAN module, it wouldn't be hard at all to add a blacklist to Templar via a config file that is checked. The EC2 => EC2 issue is probably the biggest stumbling bloc…
-
comment
Comment #9149619
That's good point actually, I could see that happening. What is your concern about the url used? That they point at something a user is trying to coerce you to hit? If so, that cou…
-
comment
Comment #9149263
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 …
-
comment
Comment #9149184
I agree, async responses are a great tool. It's a question of figuring out a good way of delivering them back to the client. Another option is a long poll endpoint within Templar t…
-
comment
Comment #9149109
Fire-and-Forget is on the todo list. Since you're asking about it I'll bump it up. The later, Templar could have an option that tell it to only connect to public ips. Would that do…
-
comment
Comment #9148803
Author here! That's certainly an interesting feature that could be added. I have on the future list to support sending responses back via AMQP. Your callback scheme isn't much diff…
- story