Anything but the last one. Don't duplicate the http code in the body, else you're now maintaining something you don't need to maintain.

I'm not a fan of codes that repeat information in the body either, but I think if you had used a different example like "INVALID_BLAH" or something then the message covered what was invalid, then it would be fine. Like someone else said, the error data should be in an object as well, so that you don't have to use polymorphism to figure out whether it's an error or not. That also allows partially complete responses, e.g. data returns, along with an error.

Thank you for the good post. And at this point, most of the work is being done by Ategon and the other admins. I am mostly here for infrastructure support and general direction of the instance.

Thanks for the context. You can really tell by reading it too, they’re clearly trying to make it sound like companies can’t exist without tracking users, absolutely batshit insane.

As soon as you tell the police if they won’t handle it then you will, they always seem to find the time to go get your stuff back.

The solution is to use an already existing software product that solves this, like CloudFlare’s CSAM Detection. I know people on the fediverse hate big companies, but they’ve solved this problem already numerous times before. They’re the only ones allowed access to CSAM hashes, lemmy devs and platforms will never get access to the hashes (for good reason).

You’ve never had an issue with how slow npm installs?

You don’t report it to the FBI. They need to register with the National Center for Missing and Exploited Children (NCMEC), where they will be given a login and then they report it through there. They also should make sure to not purge the CSAM as there are specific rules about removal.

Hm. this is a very strange article for me to read because in my experience, only 1 or 2 things in the whole article have been true for our company (17k employee company with 300 people in the tech org).

Users would ingress through the API Gateway technology, which handles everything from traffic management, CORS, authorization and API version management. It basically serves as the web server and framework all in one. Easy to test new versions with multiple versions of the same API at the same time, easy to monitor and easy to set up.

We don't use API Gateway. The best use for lambdas is as a direct call, using the ARN. You don't need to worry about CORS, permissions, etc. You either have access to call the lambda or you don't. You can directly control exactly who can call your service, and you never need to set up IAM at all.

Local development. Typically a developer pulls down the entire application they're working on and runs it on their device to be able to test quickly. With serverless, that doesn't really work since the application is potentially thousands of different services written in different languages. You can do this with serverless functions but it's way more complicated.

I think if you're literally recreating your monolith in a lambda then you're doing something fundamentally wrong. Our entire team only has a few lambdas (10-15) and they're very easy to manage. But yes, testing locally is an issue. We've solved this with testcontainers, which would be the same solution if you were just deploying docker services to k8s or openshift or even directly to a VM. This is the first very large issue with lambdas that the article is correct about though.

Hard to set resources correctly. How much memory did this function need under testing can be very different from how much it needs under production. Developers tended to set their limits high to avoid problems, wiping out much of the cost savings. There is no easy way to adjust functions based on real-world data outside of doing it by hand one by one.

I do not understand this. How are your resources changing like that? We've only had to touch the resources for our very large functions, and even then we've touched them only once or twice in 3 years. This is absolutely a non-issue. Set it to the lowest to start, then when it times out update it to the next level. It really isn't difficult.

Since even a medium sized application can be made up of 100+ functions, this is a non-trivial thing to do.

please. why in the world would you think a 'medium sized application' would have 100+ functions? That's absolutely insane. there's no way to manage that. That's not using serverless properly. We have a medium sized 'application' (250k+ lines of kotlin, with tens of millions of lines of generated Java from Drools Rules) and it's 10-15 lambdas. You should not have hundreds of lambdas for a medium sized app. That's just idiotic, I'm sorry, but that was never what serverless was meant for.

Is it working? Observability is harder with a distributed system vs a monolith and serverless just added to that. Metrics are less useful as are old systems like uptime checks. You need, certainly in the beginning, to rely on logs and traces a lot more. For smaller teams especially, the monitoring shift from "uptime checks + grafana" to a more complex log-based profile of health was a rough adjustment.

I can agree with some of this partially, but I'm not sure why the author thinks that getting rid of uptime checks is a problem. I've never once had to worry about whether our lambdas are up. There's no uptime! It either works every time or it doesn't work at all. It's pretty awesome actually. Of course you do need to test it when you deploy, but that's a simple http call and boom you know whether the deploy worked or not.

Traces are also a great way of tracking where you have slowness in your system. I'm guessing a lot of this depends on which 'ecosystem' you choose, but with Quarkus and XRay, tracing is dead simple. Add a dependency, you've got tracing. Done.

Now, the big problem here is the error passing, which the author talks about later.

Latency. Traditional web frameworks and containers are fast at processing requests, typically hitting latency in database calls. Serverless functions were slow depending on the last time you invoked them. This led to teams needing to keep "functions warm."

well sure, but if you have 100+ functions then you're multiplying your instantiation costs by 100+. This is not a non-issue for fewer lambdas, but it's much less of a problem.

Later Provisioned Concurrency was added, which is effectively....a server. It's a VM where your code is already loaded. You are limited per account to how many functions you can have set to be Provisioned Concurrency, so it's hardly a silver bullet. Again none of this happens automatically, so its up to someone to go through and carefully tune each function to ensure it is in the right category.

correct. but it's a server you don't have to manage. I don't know why the author calls this out this way, you have to manage autoscaling servers at a much finer grained level. Provisioned Concurrency is literally "how many functions do you want to be running at any point in time by default". There's not much else to it, besides the next point.

But it is very possible for one function to eat all of the capacity for every other function. Again it requires someone to go through and understand what Reserved Concurrency each function needs and divide that up as a component of the whole.

this is a major issue. no other thing to say about it. I do not understand why this is the case, but yes it's a huge problem, and makes scaling across an org very difficult. The one solution to this is to split your org into separate aws accounts (not sure how gcp manages it, but we do use gcp too), which helps with that, but it's still a weird restriction.

In addition, serverless functions don't magically get rid of database concurrency limits. So you'll hit situations where a spike of traffic somewhere else kills your ability to access the database. This is also true of monoliths, but it is typically easier to see when this is happening when the logs and metrics are all flowing from the same spot.

Hm. maybe this depends on using RDS, because we've never seen this with Dynamo.

In practice it is far harder to scale serverless functions than an autoscaling group. With autoscaling groups I can just add more servers and be done with it. With serverless functions I need an in-depth understanding of each route of my app and where those resources are being spent. Traditional VMs give you a lot of flexibility in dealing with spikes, but serverless functions don't.

This has not been our experience. Lambdas have been simple set it and forget it, allowing our team (and company) to focus on the business rather than infra. We only spend time configuring lambdas when we are creating new ones, which isn't too often. It's been 3 years since we started using lambdas, and I would say we create maybe 3-5 a year and they're all for new features, not new individual functions. The companies business has grown more than 3x in that time and we have daily spikes and it all just works.

Teams switched from always having a detailed response from the API to just returning a 200 showing that the request had been received. That allowed teams to stick stuff into an SQS queue and process it later. This works unless there is a problem in processing, breaking the expectations from most clients that 200 means the request was successful, not that the request had been received.

this is by far the most annoying thing about lambdas. they are http under the covers, but you can't modify any http headers, response codes, etc. It's either 'throw an exception' or '200'. nothing in between. very annoying.

You think using an app owned by a company that caused a genocide, influenced a major election, and has negatively affected the entire world’s population means you’re tech savvy? I don’t know a single software dev that uses whatsapp. It has nothing to do with being tech savvy.

Imports wouldn’t help. It’s setters with a ton of chained getters

Crunk means partying lol. I’m very drunk.

I agree. I’m very sorry for breaking it! Just trying to keep the site running!