Ask HN: Bad Application Architecture Example? | Hacker News Reader

Ask HN: Bad Application Architecture Example?

7 pointshaidrali9 comments

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.

Thank you for suggestion one of favourite qouted line of my lead is "Facebook and Goole using everything that's why we also should use everything possible" this make me sad about where i am working

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.

Thank you for replying i am also having same point of view that whole system should be in either Rails or Laravel

The tight coupling you mention would be indicative of a bad database design (or more likely a bad data model), not bad architecture. There are lots of reasons to communicate over an API, but using the datastore as the mechanism of data exchange is not in and of itself evidence of a bad architecture.

Any argument about coupling at the database layer can equally be applied at coupling of the api layer and if there are certain functional requirements that are best supplied by the data store (transactions for instance) it may make more sense to not use an api.

Much more troubling to me would be the 2 different technical stacks, though even that can be trivially justified in some environments.

If the Rails and Laravel apps are updating the same tables in the database, or even different tables that have foreign key relations with each other, that is a huge problem because changing the data layer in any way will require changing it in three places.

If they're confined to separate tables that happen to be in the same database, that's better. But then just putting them in different databases would potentially make configuration and deployment much easier.

There's really no valid reason to have two different app frameworks on top of a shared database.

If you design your database with proper views and stored procedures, name spaced and permissioned correctly for the applications then any data model change that is not coupled in the data model need only be changed in the data store. If the data model itself is coupled then nothing you do will prevent the change crossing the application boundaries (and probably will propagate to more places).

There are lots of valid reasons to have multiple app frameworks deal with a shared database. I mentioned one (transactionality) and there are many others.

Reply on news.ycombinator.com