56 karma · joined April 21, 2019
The only exception I can think of is any dependencies on libraries that may or may not be installed by the system package manager. Even then, those dependencies are often optional.
One particularly annoying pain point was that one of the engineering directors made it his personal mission to ensure that every service's Protobuf definition conformed to some platonic ideal. We'd have a BFF service Foo that essentially provides a wrapper around another service, Bar (among other things). Naturally, Foo's service definition included some Protobuf messages defined in Bar. Now the simple thing to do here would be to include those Protobuf message definitions in Foo.proto and expose them to consumers of the Foo service, but that apparently couples clients too tightly to Bar's service definition (?). So, it was decided that Foo's Protobuf file would contain actual copies of the messages defined in Bar. Adding a new field to a message in Bar wouldn't expose it to clients of Foo unless you also update the message definition in Foo.proto as well as the code that converts from Bar::SomeMessage to Foo:SomeMessage. Now imagine that the backend service is something commonly used, like UserService, and that there are potentially dozens of BFF services that contain copies of the definition of UserService::User. Welcome to hell.
The aforementioned engineering director would hunt down BFF services that dared to include a message dependency instead of copying the definition. He would then open a ticket and assign it to the service owner, informing them that they were not in compliance with the "Architectural Decision Record": the indisputable, no-exceptions, holy-of-holies log of technical mandates that were decided by a handful of people in a meeting three years ago.
This issue isn't necessarily inherent to BFF architecture, but I think it comes from the same place of overengineering and architectural astronautics.
If anyone is looking for recommendations, Clinton St. Coffee House has never once served me a sour cup of coffee.
Regarding #3: That's actually something that has been consistently satisfying. Seeing how my work impacts my coworkers and improves their workflows usually gives me a pretty good hit. Besides, it's low hanging fruit. There's plenty to improve since some of the senior engineers have, uhh... checked out?