Using multiple databases in Laravel for all queries

As we continue to grow our hosted Invoice Ninja platform we’ve been been looking into both vertical scaling [bigger servers] and horizontal scaling [more servers].

Initially we added more web servers using a load balancer. This was relatively easy to setup and as an added bonus provided higher availability. Over time however we’ve started to see our single database server experience increased memory usage, particularly after releasing our mobile apps.

Our plan was to simply divide our users across multiple databases. One database would function as the lookup server, the other databases would store the actual data.

Searching Google for ‘multiple databases in Laravel’ mainly returns examples of either specifying the connection for the particular query:


Or defining it in the model by setting:

protected $connection = ...;

However, if you’d like to use a different connection for all queries you can use:

config(['database.default' => ...]);

For our implementation we created a middleware class to find the database server with the provided credentials. The server is stored in the cache so the lookup is only required once every two hours, this is particularly helpful for the API where there’s no session.

To keep the lookup tables up to date we’re using Eloquent creating and deleted model events. Finally, to ensure our queued jobs use the right database we’re using Queue::before(...) to set it.

Developing a bot for the Microsoft Bot Framework using PHP

We recently released our first version of our Skype bot, I thought it might be helpful to share some of our implementation details.

Our bot enables users of Invoice Ninja to easily create, update and email invoices as well as list their products. The code for the bot is available on GitHub.

Here’s an example:

invoice acme for 2 tickets, set the due date to next thursday, the deposit to 5 dollars and the discount to 10 percent

LUIS is able to parse the command into its distinct parts.


Our app can then process the intent and return the invoice.


Two core benefits to natural language input can be seen in the example:

  • Dates can be easier to select as text. I’d much rather input ‘next thursday’ than have to find it in a cramped data picker.
  • We’re able to expose fields through multiple terms. In our standard interfaces each field needs a single label however with speech we can assign multiple labels, in this case ‘partial’ and ‘deposit’.

Microsoft provide helper libraries for C# and Node but the core features are available through a REST API. When getting started I found this article to be extremely helpful, it covers authenticating with OAuth and sending messages using PHP.

LUIS can handle matching intents but the client and product names need to be matched in our app, to accomplish this we’re using a combination of similar_text and metaphone to select the best match.

When we deployed the bot to production we found that getallheaders() wasn’t available, this solution enabled us to access the authorization token.

If you have any questions comment below.