Ask HN: Bad Application Architecture Example?
I am going to explain architecture of a product on which i am currently working under a Software Lead who has +8 years of development experience.
We are building a school management system on Rails and Laravel ... in short we are building a BACK END of a product not only two different servers but also on two different languages & technologies i.e. Logging, User Management in Rails Accounts, Academics in Laravel while our front end is in AngularJS
According to me this is the perfect example of pathetic architecture because one request from client to Account or Academic module will invoke n HTTPS calls to other servers ( for logging and user management purposes). And biggest mistake is both Laravel and Rails are accessing same Database
There are may other scenarios where one can easily figure out that we are doing it completely wrong
I have tried so much to understand and try to make some sense out of this architecture but unable to do so. My lead insist this the better architecture It will increase performance of the application
Please suggest me Is my Software Lead is RIGHT ... i think NO then what should i do should i leave the company because its effecting my learning as well as patience or should i continue working ....
It is impossible to determine if anyone is right/wrong with this limited amount of information. This does sound overly complicated for a proof of concept or early stage application.
That said, I've worked on tons of apps that had different languages, different servers, different services etc. And nothing about 2 different code bases talking to the same database is in and of itself bad (in fact many RDBMS are optimized for this case).
Ask the Lead some questions about that architecture. For example, is there a deeper reason or rationale for different middleware on user mgmt and logging vs. academics? Is it possible they will need to scale the academics side, but not the user management?
Or more often the case is usually nothing technical at all. Probably someone less technical said "I like [Rails|Laravel|X] use that". If that person is in a position of power, the Lead may have been forced into it if that technology is "someone's baby" so to speak.
Unfortunately, political, bureaucratic and non-technical reasons are common in technology choices. You may leave and find the same scenario some place else.
undefined
Well: if it works, is understandable, decently documented, and reasonable performant, then who cares if it seems weird?
On the other hand, if you can show (with data) that structuring it this way impedes performance, slows dow the development process, causes structural instability, or will fail at web-scale, then it might be something to worry about.
Our opinions about the architecture don't really matter. If you can find objective metrics for which the architecture is will fail to live up to the needs of the program, then that matters quite a bit more.
Having a Rails app and a Laravel app connected to the same database is a bad sign. It makes the two codebases very tightly coupled and changing one is likely to break the other in unpredictable ways. The databases should probably be separate and the Rails and Laravel apps communicating over an API... or just build the whole damn thing in Rails.