matahwoosh

Oh, and we use the basic Ghost theme, Casper, with some design tweaks.

Thanks! We're using ghost.org and of course all our illustrations are done by Annie (https://twitter.com/annieruygt) :)

Yeah A/CNAME to us and then you can use our API to issue certs of all subdomains or if you have a wildcard cert already you can upload that with us. Either way works :)

for the time being, you could try to issue SAN certs with LE (from their website):

"If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week."

LE still says Jan '18 - https://letsencrypt.org/upcoming-features/

Ohai! Yeah, you can do the same thing with Fly (which is what most of our customers do - just point DNS at Fly). I cannot stress enough how nice it is being able to build on top of Let's Encrypt! bows

The API is mainly for people who'd like to automate the process, because they want to provide custom domains for their customers (so more for B2B use-cases) ;)

I'm assuming mrkurt meant that you send your users once to create a dns record (in case you haven't already) - you can add any hostname you want on Fly, it doesn't have to exist, yet. Then you go and create a DNS challenge for Let's Encrypt. Obviously, these 2 steps are orthogonal, but this is the reality of user onboarding.

what if older you is wrong about being wrong about younger you? ;)

I think there's no straightforward answer to this. E.g. why would you have 2 DNS look-ups with cookieless domain? I imagine that means cdn.mydomain.com and mydomain.com?

If you're using HTTP/2, then one domain is better, because you can use the same persistent connection to multiplex your traffic. Well, technically, if you use the same IP and SSL cert then you can HTTP/2 Push the contents to the client (doesn't have to be the same domain).

However if your web server is slow or if the distance between the client and your web server is significant then you're likely not going to benefit from the performance gains of using one connection, because of the network propagation delay (vs low latency POPs from major CDNs).

Lastly, your static assets don't have to be on a cookieless domains, you can just strip the cookies and cache the content - that's what many varnish instances do ;)

I agree with you that the earlier you can catch those performance issues, the better. It's just like with catching bugs early in your development cycle. You could even argue that poor perf is a bug!

The more you know about the performance characteristics of your stack, the better, but given how many 3rd party services you might be using in production it might be close to impossible to predict that. Either way, you should be constantly monitoring the performance of your applications (backends, DBs, browser timings, RUM, cross-stack traces etc.) .

Looking forward to your Show HN on monitoring :)

Also, a note on QUIC. Seems like the spec is a draft and is not going anywhere right now, but Google has made big progress with TCP BBR control-flow algo, and there's also TCP Fast Open and TLS 1.3 0-RTT to look forward to.

Moving more delivery (not just static content) to edges + using HTTP/2+Push should help a lot with perf, too.

There's definitely some truth to how (at least some of) e-commerce sites could be easily sped up. Part of the problem is that you have a combination of legacy stack, organizational inertia, lack of know-how and resource outsourcing (so 3rd party vendors owns parts of the stack).

And specifically, wrt caching and varnish, as soon as you put something in your cart and you're cookie'd pages you visit are not cacheable.

Yes! We're looking forward to this at Fly :)

https://twitter.com/annieruygt She's awesome! :)

compiled in a Goodreads list (https://www.goodreads.com/list/show/114264.YC_s_2017_Summer_...) like you were going to actually read those ;)

just throttle your connection ;)

Generally, yes, but I think `O(log n / log log n) == O(log n)` is wrong.

log(n) / log(log(n)) = logx(n) (where x = log(n), wasn't sure how to describe logarithm base in a better way). So you get O(logx(n)). In general the logarithm base doesn't matter for Big-O when it's a constant, but I'm not sure you can apply the same thing to a base of log(n).

small correction, it's Θ( log n / log log n ). I noticed though, when I copied the formula from the original paper, this what I got, too ;)

We do serve our own site! We're running multiple apps on the same fly.io domain. Our landing page is currently hosted on Github Pages (and that's probably how you're seeing Fastly headers), but you're hitting our load balancer first :)

just made my day. I so want a flying nyan cat now