4 ms·

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

by kyllo 12y ago

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.

haidrali 12y ago
Thank you for replying i am also having same point of view that whole system should be in either Rails or Laravel
kasey_junk 12y ago
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 12y ago
  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 12y ago
    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.

by kyllo 12y ago

haidrali 12y ago

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

kasey_junk 12y ago

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 12y ago
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 12y ago
  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.