BenMorganIO
Joined 12 years ago
Joined 12 years ago
Set up two nginx servers. One that's your usual to load Laravel and the other to the legacy nginx server that acts as routing to the legacy application. I would even recommend using OpenResty to help delegate if you need something intelligent.
I would strongly discourage a JS framework that would add increased complexity when you need to keep things focused. The front-end would need to be recorded in Laravel and brought back over in a clean fashion.
Set up a CI and ensure all the code that goes over to Laravel is near 100% tested. Might also be useful to set up a visual regression test tool such as Percy to ensure everything moves over nice. Push for SMACCS and BEM to keep things consistent. Or just make new styling for the new pages to surprise the users.
Rewrites are a trap though and can be painful. Keep a balance of features entering Laravel and the big foxes entering the legacy app. I would recommend RabbitMQ to communicate between them.
Never.
As per the philosophy question, neither classical mechanics, relativity, or even death cares about what we think. What matters here is how we perceive and understand a concept.
I remember working over half a billion records and having problems when I needed a count. I used count(id) but that was mainly from internet mantra. I did not see an improvement. Using Citus gave me a significant improvement from 7 minutes to 1. And that was just a single coordinator, two workers on the same host. It could become much much better.
If the data is very stagnant and writes are very low the triggers are great. Usually the "close enough" with pages is good if you have over 100k since paging - please correct me if I'm wrong - is sometimes 1k off.
My preference is Citus as a catch all, but a trigger, a Redis cache managed at the app level, or using page counts are all . really useful for stickier situations.