Lumen - How to maintain 2 different MySQL Connections and Best Practises for Shared Models?
Hey there!
I'm porting my API part from my Laravel App to Lumen (So it performs well, Always wanted to do this but could never decide with the right framework).
So there are 2 things I'm having trouble with.
The API connects with 2 different databases. Currently, I have 2 different connections config within my config/database.php file. How would you have 2 connections config with .env or using Env vars? I know i can have the same database config file and just load it in Lumen and that's the last option I'll be doing but if i was to use .env file for the same? If i have the same DB_* options and in place of config have another connection details, wouldn't it conflict?
What's the best way to share the models between the Lumen and Laravel App? Basically, I don't want to maintain 2 different copies of the same set of models to get it working (Relations, Table Info, etc.). One way i can think of is, By moving it out as a package with its own migrations and other required files and then load within both the Apps, however I'm not sure if it's really a good practise and if there's a better way to do it?
Lumen will use the config file which we copy and paste in the config directory within the project root (For the default configs, such as database.php). So that's the only way to get the multi-connection config working.
Both good questions. I looked in the vendor/laravel folder the conf folder is there with the database file. Though depending on your deployment you may need to ssh in and set that file up as your regular app.
No answer on the model sharing though. Imo to keep thing separate I would run both. But that depends on what you have in your models of that's viable. Can't wait to see a better answer though.
On question two: Just a stab, but could you autoload the namespace in your composer file to your full path on your main app, then extend the main app models in lumen?
I plan on keeping the API on different server as well, so that it doesn't effect the main App due to heavy usage. So i think the best is to decouple the app into a package for the migration and repos part.