this post was submitted on 26 Feb 2025
79 points (96.5% liked)

Programmer Humor

20800 readers
1592 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 

I didn't see this coming and I think it's funny, so I decided to post it here.

you are viewing a single comment's thread
view the rest of the comments
[–] tyler@programming.dev 5 points 16 hours ago (2 children)

we've been using nano-services for the past 6 months or so. Two different reasons. A codebase we absorbed when a different team was dissolved had a bunch of them, all part of AWS AppSync functions. I hate it. It's incredibly hard to parse and understand what is going on because every single thing is a single function and they all call each other in different ways. Very confusing.

But the second way we implemented ourselves and it's going very well. We started using AWS Step Functions and it allows building very decoupled systems by piecing together much larger pieces. It's honestly a joy to use and incredibly easy to debug. Hardest part is testing, but once it's working it seems very stable. But sometimes you need to do something to transform data to piece together these larger systems. That's where 'nano-services' come in. Essentially they're just small ruby, python, js lambdas that are stuck into the middle of a step function flow in order to do more complex data transformation to pass it to the next node in the flow. When I say small I mean one of the functions we have is just this

def handler(event:, context:)
  if event['errorType']
    clazz = Object.const_set event['errorType'], Class.new(StandardError)
    raise clazz.new.exception, event['errorMessage']
  end
  event
end

to map a service that doesn't fail with a 4xx http code to one that does fail with a 4xx http code.

You could argue this is a complete waste of resources, but it allows us to keep using that other service without any modifications. All the other services that depend on that service that maps its own error types can keep working the way they want. And if we ever do update that service and all its dependencies, now 'fixing' the workflow is literally as simple as just deleting the node and the 'nano-service' to go along with it.

I should note that the article is about the first thing I discussed, the terrible codebase. Please don't use nano-services like that, it's literally one of the worst codebases I've ever touched and no joke, it's less than 2 years old.

[–] zea_64@lemmy.blahaj.zone 3 points 13 hours ago

Sounds like a distributed monad

[–] Valmond@lemmy.world 4 points 15 hours ago (2 children)

This looks like hell.

I'm a C/C++ developer though.

[–] tyler@programming.dev 1 points 4 hours ago (1 children)

You can write your glue nano-service in c/c++ if you want, it’s just that: glue. It doesn’t matter as long as you don’t need to change the original services which also can be written in whatever you want. Ruby, Python, JS just work out of the box with aws lambda and you don’t really have to maintain them or any sort of build infra so it allows for very little maintenance or upkeep cost. You don’t really test these glue lambdas either.

[–] Valmond@lemmy.world 1 points 3 hours ago

Things won't be simpler just because you cut everything up in tiny tiny pieces (I mean it will be easier because it solves some surface level problem right now, pushing the real problem down the road), it creates a complexity of its own.

[–] Xanza@lemm.ee 2 points 13 hours ago (1 children)

I’m a C/C++ developer though.

Ya feel good about yourself, slugger? /s

[–] Valmond@lemmy.world 2 points 3 hours ago

Yeah, I kind of am. Just found a 33% time job so that I can gradually leave software engineering 😁