

Ask HN: Bad Application Architecture Example? - haidrali

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.<p>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 &amp; technologies i.e. Logging, User Management  in Rails Accounts, Academics in Laravel while our front end is in AngularJS<p>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<p>There are may other scenarios where one can easily figure out that we are doing it completely wrong<p>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<p>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 ....
======
kasey_junk
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).

------
matt_s
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.

~~~
haidrali
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

------
MalcolmDiggs
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.

------
kyllo
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.

~~~
kasey_junk
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.

~~~
kyllo
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.

~~~
kasey_junk
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.

