[prepend]

> API that works on localhost: 4 days

Lol. This may be true but if kind of pointless as an api on localist isn’t very useful unless you’re automating your home. Of course it’s easier to hack something out on localhost than to design for actual users.

I think it makes more sense to build incrementally with the end in mind. So writing those terraform scripts will take less time if you initially write them to deploy to localhost for testing.

[throwaway2016a]

API gateway is simply how you expose Lambdas to an HTTP interface in AWS. It was the easiest way until they recently unveiled a way to expose the Lambda directly. You can also use ALBs (Application Load Balancers) and CloudFront to expose Lambdas to HTTP.

Either way, Lambdas are hard to debug locally, often I just deploy them to test (since deploying is easy). Or I write my code such that it bootstraps differently when launched locally vs Lambda. Either way, unless it is a very complex app that has lots of external dependencies, 4 days is a bit much.

[Aeolun]

But don’t try to create a REST API Gateway with more than 200 resources, or CloudFormation will randomly start failing.

Or try to add more than 100 rules to your ALB, because it’ll be impossible.

My biggest issue with AWS is that the limits are so arbitrary, and seem to solely exist due to terrible design decisions.

If my local express server, or nginx can deal with 100 endpoints, how is it possible for this multi billion dollar infinitely scalable service to not do the same…

[throwaway2016a]

Interesting, I haven't had the experience with CloudFormation.

At that scale, however, I tend to group my Lambdas as microservices not per endpoint. It helps with cold start time as well. So for example, if I have a page" resource, I don't make that 5+ endpoints, I make it a wildcard / prefix match and do the routing inside of the service lambda.

Maybe you legitimately have 100+ different microservices, in which case, I don't doubt that is a problem, I just haven't experienced it.

[Aeolun]

I mean, there are certainly ways to work around the silly limitations. I just feel like I shouldn’t have to.

[bleeding]

The 200 resources thing has been a really frustrating problem for us too. We've started migrating ours to separate API Gateways at a "service" level and then mapping paths to different APIs using the Custom Domain API Mappings.

[Aeolun]

> We've started migrating ours to separate API Gateways at a "service" level and then mapping paths to different APIs using the Custom Domain API Mappings.

Yeah, that was suggested to us too, but it felt like a dirty hack to me. What is the point of having an API gateway if you can’t have the single one (our microservices hook themselves up to that single gateway).

Our solution involves a custom CDK resource that keeps re-creating API gateways until it gets a root resource ID starting in the lower range of the alphabet, ensuring it’ll always be found by CloudFormation.

[dogleash]

>This may be true but if kind of pointless as an api on localist isn’t very useful unless you’re automating your home. Of course it’s easier to hack something out on localhost than to design for actual users.

When did developing software on your own machine stop meaning "design for actual users"?

You should have a strong and reliable deployment for production, yes. But not being able run a baby instance locally just as easily means sacrificing your development loop.

[prepend]

Designing for me as a single user is different from designing for other users. Other users can’t hit my localhost.

The article talked about how much time it takes to get working so it seems like the author took shortcuts to get it working locally.

I agree that it’s a good practice to dev so deploying locally works as well as deploying remotely (or to lots of environments). But this is different than developing only for localhost.

[mwcampbell]

An API on localhost may not be useful, but an API running on a single VPS or dedicated server could take you very far.

[bluedino]

We had a 'microservice' running on a server that had a bunch of other random things on it, it ran for 4-5 years until the server got decommissioned.

Nobody knew what all ran on that server, worse yet nobody knew that particular service ran on it. The person who wrote it was long gone.

It took a day to troubleshoot, a day to figure out what actually happened, and 5 days to get the server backup and running.

A couple months later, someone shut the server down again. It only took three days to fix it the second time.

In order to ensure this would never happen again, there were about 15 meetings, 20 people were involved, and then service was re-written and hosted on Azure (with the rest of some of our stuff). It's probably failed about 100 times since then, in about a hundred different ways.

This thing was maybe 500 lines of php.