3 ms·

Surely if you're reimplementing an HTTP server inside a function running on an HTTP server then something somewhere has gone horribly wrong.

Spivak 3y ago
Do you feel the same about a load balancer being an HTTP server proxying requests to another HTTP server? Because it doesn't have to be this way, there's php-fpm and such that could eliminate the http->http step
- contravariant 3y ago
  I'm confused, how does php-fpm connect someone to the right machine? It just looks like basic multiprocessing to me, which should be a basic feature of any decent http server. Unless you're referring to the 'load balancer' in the comments where someone builds their own multiprocessing by launching multiple servers and putting nginx in front of it. I mean do what you need to do but at least be aware you're hacking together something that should be a basic feature of the http server. If you wish to push me I'd be forced to admit that I don't like load balancers either, but that's because they're doing routing on the application layer which is not ideal and creates a single point of failure. That ship has sailed though.
jvanderbot 3y ago
I _just recently_ ported a hobby fastapi project into a lambda container and I can't speak highly enough about it. My costs went to zero, deployment is just as easy, performance went up (lambda is pretty good once warm), and my local dev build matches the API perfectly now. I could get some of that on vercel, but not the docker containerization, which makes all the local/remote stuff work the same.
Aeolun 3y ago
Maybe when you decided to use lambda in the first place, for sure. But when you are stuck with lambda consolidation is best.
scarface_74 3y ago
I can tell you a good reason for it. At one company I was working for we had an API that we sold external access to as the back end for large health care providers websites and mobile apps. But we also used it internally for batch processes. In one case latency was important so we hosted the app in an auto scaling ECS Fargate cluster behind Nginx and in the other case throughput was important so we could just deploy the same API to Lambda. Yes I know about reserved concurrency.
time0ut 3y ago
The way I have done this in the past is to use an adapter library that maps from the incoming lambda event to whatever framework you are using (like fastify or jax-rs for example). Your code looks like the normal http request handler stuff you would normally write, but it isn’t running an http server inside the lambda beyond whatever stuff AWS does under the covers of course. I’ve deployed many Lambda based HTTP APIs in this pattern and its my preferred approach to using Lambda, though I would rather target a standard container orchestrator if available.

Spivak 3y ago

Do you feel the same about a load balancer being an HTTP server proxying requests to another HTTP server? Because it doesn't have to be this way, there's php-fpm and such that could eliminate the http->http step

contravariant 3y ago
I'm confused, how does php-fpm connect someone to the right machine? It just looks like basic multiprocessing to me, which should be a basic feature of any decent http server. Unless you're referring to the 'load balancer' in the comments where someone builds their own multiprocessing by launching multiple servers and putting nginx in front of it. I mean do what you need to do but at least be aware you're hacking together something that should be a basic feature of the http server. If you wish to push me I'd be forced to admit that I don't like load balancers either, but that's because they're doing routing on the application layer which is not ideal and creates a single point of failure. That ship has sailed though.

jvanderbot 3y ago

I _just recently_ ported a hobby fastapi project into a lambda container and I can't speak highly enough about it. My costs went to zero, deployment is just as easy, performance went up (lambda is pretty good once warm), and my local dev build matches the API perfectly now. I could get some of that on vercel, but not the docker containerization, which makes all the local/remote stuff work the same.

Aeolun 3y ago

Maybe when you decided to use lambda in the first place, for sure. But when you are stuck with lambda consolidation is best.

scarface_74 3y ago

I can tell you a good reason for it. At one company I was working for we had an API that we sold external access to as the back end for large health care providers websites and mobile apps. But we also used it internally for batch processes. In one case latency was important so we hosted the app in an auto scaling ECS Fargate cluster behind Nginx and in the other case throughput was important so we could just deploy the same API to Lambda. Yes I know about reserved concurrency.

time0ut 3y ago

The way I have done this in the past is to use an adapter library that maps from the incoming lambda event to whatever framework you are using (like fastify or jax-rs for example). Your code looks like the normal http request handler stuff you would normally write, but it isn’t running an http server inside the lambda beyond whatever stuff AWS does under the covers of course. I’ve deployed many Lambda based HTTP APIs in this pattern and its my preferred approach to using Lambda, though I would rather target a standard container orchestrator if available.