> ... the "microservices" that our lead thinks we need even though they aren't even microservices. All we've done is split our application into seperate mini applications that don't talk to eachother at all,
Replacing in-app API/libary calls with RPC is an micro-service anti-pattern (1). If the services don't need to communicate you have probably made the correct split - or you could think backwards - why would these services that are independent and don't talk to each need to be merged into a monolith ?
1) There are of course exceptions, there could be a good idea to separate things for performance, eg. create worker processes. Which works if they are like pure functions.
As my reply far up this chain says, the services have a ton in common. So much so that the idea was "just copy and paste" code between. Still sound great? I forced his hand on a shared library that houses lots of the code all services need, but not everything can (or should) go in there.
Multiple PRs just to complete one task sometimes and we're talking a small 4-6 hour task. If the services were truly independent this wouldn't be needed and the approach wouldn't be a poor developer experience and infrastructure headache. But a change in one often requires a change in another. We don't have a monorepo, because he was too much of a doofus to figure it out and gave up instead of asking for help.
80% of the problems are because the guy doesn't know what he's doing, doesn't know architecture and just said we're doing this. Which means I have to go in and fix his poorly built Dockerfiles that are an expose on what not to do. We're now adding API Gateway. Was this explained as to why we need it? No. Did I ask yes? But I simply get "I've already explained it" Cool. I explained to you why running an update on packages in your build instead of installing from a lock file is some of the dumbest shit I've ever seen yet I just had to go in and clean up your dockerfile again. You want untested packages going into stage / prod? My lead is your guy. I'm sure in a few weeks he'll come to me with "But API Gateway doesn't work and I don't have time can you fix it".
Fuck this dude. I just want to write clean code and not fuck with his mistakes. Did I mention we run completely different Dockerfiles between environments (local vs stage/prod). Like, not even the same O.S (ubuntu vs alpine), web server (apache vs nginx) etc... Getting the picture of whats its like to deal with his mistakes day in and day out and slowly fix them.
Replacing in-app API/libary calls with RPC is an micro-service anti-pattern (1). If the services don't need to communicate you have probably made the correct split - or you could think backwards - why would these services that are independent and don't talk to each need to be merged into a monolith ?
1) There are of course exceptions, there could be a good idea to separate things for performance, eg. create worker processes. Which works if they are like pure functions.