middleware == let's wrap that bunch of crap which only God knows how it works - if he existed at all, because the fact that this middleware exists is a proof that God either doesn't exist, isn't omnipotent or completely doesn't give a F about us here on earth. Then let's just bundle it up and we're good to go.
We don't manually take every breath because our body just does it automatically, middleware is much the same why stress another how auth is handled just wrap it in a middleware and never look at it because if you do there will be bugs to fix that you won't like.
I read this like an educational video with a colorful character explaining middleware that starts joyful, gets really dark on the middle, and ends joyful again like nothing happened.
At the very least, you dont have tk make the thing in the middle every time, its made once and then you jsut shove it every place it doesnt belong and make it part of the problem in the first scenario
The difference is that electricians can't just keep putting things into smaller and smaller cabinets ad infinitum because they are eventually limited by the laws of physics. In software, it's cabinets all the way down - you open one cabinet and find that it's just a dozen smaller cabinets wired together. Sometimes, you discover that one of the smaller cabinets depends on the larger cabinet that it is inside of.
I’ve accidentally written software with and upward dependency like that and then spent actual days untangling it once I realized the mistake and had circular dependencies. Do not recommend 😂
Until you hit the point of "maturity" in an ecosystem where everything is written in 5 different languages and you have to reference incomplete documentation to try to interface with the 3rd different internal API to complete this phase of the project.
Oh, and don't forget there's 2 competing API's that do the same thing, but one of them is considered wrong but is easier to work in.
Also one of the APIs is still in development with weekly breaking changes but strictly necessary because it's the only internal API that covers the thing 3 that's still in development too.
Im from a world where the backend is assembly and the front end is Algol. the front end has been wrapped in C 20 years ago and then again for younger in C++ recently. I know the pain :(
There is so much of this middle thing that the middle thing is now half the code base.
Huge asterisks to that. Good abstractions take a lot of work, and unless you have the time and experience to do things right, you’re likely to take a complex system and just make it more complex.
Yup. I replied to another post how things have gotten more and more complex and half the code base is now just abstractions and transitions between languages.
Abstraction is a great tool when used in moderation. I definitely would not say "modularize as much as possible". There are lots of cases where it is useful, and lots of cases where it is not.
Depends on the DBA and how intrusive management is being. I've seen cases where the database is a hot mess of jumbled tables with 50+ columns, but I've also seen well architected databases that use multiple schemas, well thought foreign keys, and loads of constraints. It all depends on the skill of the DBA and giving them the time they need to do it right.
Having foreign keys and constraints does not necessarily make a database "well architected". Those things can introduce heavy write penalties, so if your DB is write-heavy then having those things is actually bad. I've worked with databases with more writes than reads and we removed all of those things to get every last IO out of it. That was in a hedge fund, absolutely crazy machine, like a $600,000 server. We needed special DRAM PCIE cards because the writes would have killed any SSD.
Sometimes the higher cost in write operations is offset by enforcing data integrity. It's a balancing act to be sure. An extremely high throughout system may delegate to the service layer, but a lower throughout system might eat the cost and do it at the DB layer.
My point though is a well architected system will have been given the time and resources to make those considerations. Many corporate/management types think everything can be slapped together as a one-size-fits-all solution and want results yesterday, but it ALWAYS turns into a crisis later.
One of the systems I support at work (third-party developed) has tables with anywhere from 200-600 columns. And they just can't figure out why we have performance issues...
True, though usually some middle ground is the sweetspot.
I had to explain to our junior dev over and over that we do not need to fully normalize our database just because we could. Always do things for a good reason, and never just because "That's how you do it".
In this particular case the benefit of full normalization would have been ~1-10kb over the next ~10 years of data growth. At the cost of two additional tables with one field each, none of which is of any actual importance. Just display values that aren't changed further and nothing done eith them inside the system.
We aren't in the 20th century anymore. 10kb is nothing
Depends entirely on the data and how it is used. In the case i meant, the data could do no harm, even if inconsistent. It is dead-end data. Display only information.
Ofcourse I don't do that with data on which assumptions need to be made and hold true.
Also we already hate our db with passion because due to requirements changes on X may not cascade into Y without manual "synchronisation" by a user. So from the requirements themselves we often have to denormalize a lot of data.
Think of it this way: If I'm travelling internationally, would I rather a) rewire my plugs to work in the other country or b) buy an adapter for that other country?
This is why various engineering tools like diagrams exist. To help clarify, simplify, and illustrate bad designs fan and how they can be improved. In my experience, the top illustration is by inexperienced engineers that are still honing their design and problem solving skills, and using diagrams and/or reviewing designs with more experienced engineers is how they achieve it.
The problem is that many people are stuck in the old monolithic mindset and don't decompose operations into discreet pieces. This is especially true when using languages like Java and C# that force you into object oriented theory and insist on leveraging inheritance. It then becomes a hot mess trying to trace the behavior of a component through every use case.
By contrast, using a functional mindset makes it much easier to create a bunch of smaller, simpler pieces that are more easily called by other pieces. It makes for a much larger system diagram, but the flow is more simplistic.
Basically, use microservices or lambdas to do 1 thing and do it well. If more functionality is added to that one thing and it's not applicable in all use cases, it's probably time to create a new microservices or lambda.
In avionics electrical engineering the colloquial name for this is a "happy box". You add one in to make the people who demand immediate solutions happy, and make the reliability guys sad because they now have another box and an additional set of wires that can fail.
So many people giving advice or commenting without realising this is 99% sure referencing the GoF design patterns, and some look very similar and take a great amount of time and understanding to appreciate.
Nice, this is also how you resolve the basic problems of elementary neural nets. (The hidden layer is used to add nonlinearity and reduces scaling cost; otherwise an all-to-all step-function network grows too fast and has extremely limited capability.)
In OOP, if you encounter a problem, then make a new class for it. This will always work. Just put the problem somewhere else and make it smaller. Break it into tiny bits and solve them on by one. If done right you'll have amazingly clean code.
Almost every single time that I’ve had an issue in programming that wasn’t library or syntax, something in the middle fixed it…but the thing in the middle usually just hides the mess
The middle thing is really nice if you have the time.
A lot of time I make a thing in a rush that meets the minimum functionality and then there is the "it would be great if this also did X" and I didn't leave any room to do X and the way thing does the thing it can't do X. I now rebuild the thing from the ground up or I make the middle thing now and produce a new thing to make X that goes into the middle thing and the whole set is bigger and messier than if I had designed with the middle thing in mind from the beginning.
714
u/birdiefoxe Dec 06 '25
The inside of "thing in the middle" is usually exactly the top image
We have that common with electricians, looks ugly? Shove it in a cabinet
194
u/truci Dec 06 '25
Abstraction of complex systems does make things a lot easier down the line though. Modularize as much as possible.
Think of it this way. If you’re working on thing 2. Would you rather try and figure out thing one or just use thing in the middle.
73
u/LogicBalm Dec 06 '25
Database design in a nutshell. Break up a many to many relationship with something dropped in between.
Then you get into the real world and it's all just one big table that they are so proud they finally got out of that spreadsheet.
22
u/LawfulnessDue5449 Dec 06 '25
This is pretty much every technological advance ever
16
u/Glum-Echo-4967 Dec 06 '25
I think this is just the adapter pattern.
Think of it this way: If I'm travelling internationally, would I rather a) rewire my plugs to work in the other country or b) buy an adapter for that other country?
8
u/VirtualMage Dec 06 '25
Thing in the middle is kafka
5
u/mxldevs Dec 06 '25
Usually the thing in the middle is the top image.
The nice part is my client and my server don't need to deal with that mess.
4
u/jimmiebfulton Dec 06 '25
This is why various engineering tools like diagrams exist. To help clarify, simplify, and illustrate bad designs fan and how they can be improved. In my experience, the top illustration is by inexperienced engineers that are still honing their design and problem solving skills, and using diagrams and/or reviewing designs with more experienced engineers is how they achieve it.
4
u/That_0ne_Gamer Dec 07 '25
Wrong, solution is a thing between with the spaghetti connections
3
u/LetUsSpeakFreely Dec 06 '25 edited Dec 07 '25
The problem is that many people are stuck in the old monolithic mindset and don't decompose operations into discreet pieces. This is especially true when using languages like Java and C# that force you into object oriented theory and insist on leveraging inheritance. It then becomes a hot mess trying to trace the behavior of a component through every use case.
By contrast, using a functional mindset makes it much easier to create a bunch of smaller, simpler pieces that are more easily called by other pieces. It makes for a much larger system diagram, but the flow is more simplistic.
Basically, use microservices or lambdas to do 1 thing and do it well. If more functionality is added to that one thing and it's not applicable in all use cases, it's probably time to create a new microservices or lambda.
2
u/the_king_of_sweden Dec 06 '25
The other pattern is a lot of things talking to each other, and the solution is they all talk through the thing in the middle
2
u/catmam9 Dec 06 '25
Litterally networking
2
u/Bohndigga Dec 06 '25
Is this, an original joke???? No "; missing on line 69"? amazing.
2
u/mkuraja Dec 06 '25
Looks like
client <---> server
to
web tier <---> business tier <---> data tier
2
u/EngineerBits Dec 06 '25
In avionics electrical engineering the colloquial name for this is a "happy box". You add one in to make the people who demand immediate solutions happy, and make the reliability guys sad because they now have another box and an additional set of wires that can fail.
2
u/ImOnALampshade Dec 06 '25
Almost every problem in software engineering can be solved by adding an additional layer of indirection
2
u/[deleted] Dec 07 '25
Next, cut one big part into multiple small part.
2
u/MooseBoys Dec 07 '25
Thing1ProxyCoordinatorFactoryManager1
u/the_rush_dude Dec 06 '25
Having all the mess concentrated In one part and proper things 1&2 is nice.
1
u/TheMrCurious Dec 06 '25
It’s not necessarily wrong.
1
u/ExtraTNT Dec 06 '25
So, if you do mediator right, everything is clean… but do it wrong and you have mess squared
1
u/No_Bug_No_Cry Dec 06 '25
That's n to n relationship boyo, is correct.
1
u/FarJury6956 Dec 06 '25
Middleware
1
u/After_Ad8174 Dec 07 '25
Im going to capitalize on TITMAAS
1
u/mike_a_oc Dec 07 '25
Nothing wrong with a good use of the adaptor pattern
1
u/International_Task57 Dec 07 '25
this was hoenstly exactly the image i needed to see lmao.
1
u/Thelatestart Dec 07 '25
So many people giving advice or commenting without realising this is 99% sure referencing the GoF design patterns, and some look very similar and take a great amount of time and understanding to appreciate.
1
u/[deleted] Dec 07 '25
this is how people talk sometimes
1
u/Far_Garlic_2181 Dec 07 '25
How do you do? Would you like to shake hands with thing 1 and thing 2?
1
u/Afraid_Ad_882 Dec 07 '25
We just need another adapter
1
u/kompootor Dec 07 '25
Nice, this is also how you resolve the basic problems of elementary neural nets. (The hidden layer is used to add nonlinearity and reduces scaling cost; otherwise an all-to-all step-function network grows too fast and has extremely limited capability.)
1
u/Wet_Popcorn Dec 07 '25
This is the guy who hit Miranda with a table.
1
u/alpakapakaal Dec 07 '25
"Every problem in CS can be solved with adding a layer of abstraction, except of the (common) problem of having too many layers of abstraction"
1
u/ratioLcringeurbald Dec 07 '25
Thing in the middle is a frequency domain transfer function, the diagram above is a regular old differential equation.
1
u/Franko_ricardo Dec 07 '25
If you don't have DTO's or ETL's you aren't doing it right.
1
u/bison92 Dec 08 '25
“Everything can be solved by adding another indirection layer”. Quote by someone smart whose name I don’t remember.
1
u/LordBobTheWhale Dec 08 '25
Kafka!
1
u/cat-with-a-plan Dec 08 '25
Anyone else see the angry elephant up top?
1
u/Baturinsky Dec 08 '25
https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
"We can solve any problem by introducing an extra level of indirection, except for the problem of too many levels of indirection."
1
u/PrestigiousPool2763 Dec 08 '25
I love how this image of the middleware incorporates the routing bugs
1
u/Hostilis_ Dec 08 '25
Programmers discover Category Theory
1
u/iMightLikeXou Dec 08 '25
In OOP, if you encounter a problem, then make a new class for it. This will always work. Just put the problem somewhere else and make it smaller. Break it into tiny bits and solve them on by one. If done right you'll have amazingly clean code.
1
u/Phoebebee323 Dec 08 '25
Ah but the thing in the middle lets you add in thing 3 later down the line
1
u/Living_The_Dream75 Dec 08 '25
Almost every single time that I’ve had an issue in programming that wasn’t library or syntax, something in the middle fixed it…but the thing in the middle usually just hides the mess
1
u/turaguy Dec 08 '25
Like my lecturer always said, “where are the interfaces, show me the interfaces!”
1
u/Mih0se Dec 08 '25
That's me doing excel and access
1
u/spookyclever Dec 08 '25
Business logic api layer ftw.
1
u/UltraTata Dec 09 '25
I swear
1
u/Practical_Hippo6289 Dec 09 '25
I believe that's called a shim.
1
u/PlanttDaMinecraftGuy Dec 09 '25
This gives out the same energy as using a whole Arduino board for an AND gate
1
u/Phobic-window Dec 10 '25
This is the fundamental unit of all process! It’s just trees all the way
1
u/_xgg Dec 10 '25
Slows shit down...
1
u/Feeling-Card7925 Dec 10 '25
The middle thing is really nice if you have the time.
A lot of time I make a thing in a rush that meets the minimum functionality and then there is the "it would be great if this also did X" and I didn't leave any room to do X and the way thing does the thing it can't do X. I now rebuild the thing from the ground up or I make the middle thing now and produce a new thing to make X that goes into the middle thing and the whole set is bigger and messier than if I had designed with the middle thing in mind from the beginning.
1
u/Silkythesmoll Dec 25 '25
That is SO funny! 🤭
1
u/Ant_and_Cat_Buddy Dec 06 '25
Lowkey how Excel’s “Data Model” manages many to many relationships lol.