Solution to Challenge Based on Eloquent and Query builder functions not Sql raw querys.

[manuglopez]

I think I have achieved the optimal loading, but loading times are greater than yours.

Thanks for your appreciated work on this fantastic framework.

[Lewiscowles1986]

I Like this, but I am seeing nearly 1s cold-boot times vs my hacky approach to do less. (data-locality)

[manuglopez]

I Like this, but I am seeing nearly 1s cold-boot times vs my hacky approach to do less. (data-locality)

I think that the purpose of this challenge is to exploit the posibilities that the framework offer to the developer. Probably you can do a raw sql query that would be fast than any eloquent or query builder query, but the beauty of this framework is that has gems inside that make your work more productive with less code. If you see my solution I have almost changed 7 0r 8 lines of code to achieve an optimal solution. There's no need to add fields to tables, or make jobs to save some data in DB, there are some functions that are highly optimized to avoid n+1 queries in eloquent like withAvg() or agregates like withCount() in models relations which are conflictive forms of queries that usually produce n+1.

[Lewiscowles1986]

I'm with you that it is a nice solution, that was what I commented.

We likely both came at this wondering why nearly all solutions were so similar and abandoned models entrypoint to eloquent so soon.

If you see my solution I have almost changed 7 0r 8 lines of code to achieve an optimal solution.

I Don't agree any of our solutions could be blanket "optimal"; Mine could be over-engineering in some contexts. That is the great thing about what we do. I Do like your solution. Brevity is not why. If we made brevity the sole thing to look for in code-review, I think we'd be setting ourselves up for a fall. Notice how using with, you do not have to alter the ->category->name, but there is "framework-magic" in the withCount and withAverage that materializes by convention the fields.

I Still think go one step further and stop it being live using the caching of the framework. It really does not matter to me where it is cached. I Chose the DB because it works outside of Laravel and is a concept and pattern for high-traffic systems, but Laravel has caching with expiry that could help. I Chose that as the most important thing, because:

1. It is movie ratings. A potentially popular thing that does not change meaningfully so often. The cost of 1-per second is multiplied by 86400 with just a single client. If it takes you 100ms P95, then that is 8,640,000 ms aggregate cost, with just one person visiting (no parallel). There are 500,000 movies according to alexa; which is another dimension which adds to cost. If you got a site like facebook user-base >1 billion, and spread it over those 500,000 movies, even 1 rating per person would get you a lot larger n to search through. All these grow the problem in a way that you are limited in the ability to solve at runtime.
2. I was chasing memory and time. Drag racing if you like, while staying within task of changing eloquent query. We both use 5MB, but I am significantly under 1s with the same model count; I'm using with for the category, so still joining and avoiding CTE, which could build that out faster still (but would be outside of eloquent).

Just thought an exchange of ideas for the spectators might be nice 👍

[manuglopez]

I agree with you about the optimal, any problem can lead to multiple solutions all equally optimal, but as the video stated caching is for other stage of the exercise, if caching is in place we could be caching all sql queries in a in the same request and all n+1 prob disappear automagically (I´m finishing a little component on that).

On the other hand, if this would be live in a big database with all films in the planet and app were as big as facebook probably eloquent is not the correct approach to the prob.

Times in execution inside debugbar can vary from machine to machine, php version and rdbm used. And the more important eloquent always will be slower than raw sql queries.

I totally agree with you that this kind of interchanges of ideas are good for other people to learn and inspire, including us 👍🏻.

Have a nice day Lewis