Пока времени нет совсем. А так бы сделать, да, надо…

Евгений, а шаблон всё тот же?) Так и не решились на новый диз?)

Which comment? Just in case, let me remind you of your own claims: «zero architecture», «I don’t see any caching», «Shared hosting won’t work», «it will collapse under load», and «this is a typical LLM mistake». That is exactly what I was responding to in my technical breakdown.

The project is architecturally sound: file uploads are strictly isolated into dedicated SOLID services, rather than scattered across controllers. Caching is implemented via an abstracted layer with tagging (so we don’t have to flush the entire cache at once). The system runs perfectly on Shared hosting because background data processing operations use ->chunk(100), and resource-intensive checks are handled via the non-blocking dispatch()->afterResponse() pattern. These are the exact HighLoad patterns that allow the engine to fly on cheap Shared hosting without risking a RAM crash.

That is why I disagreed — technically, the project is built properly, and it is certainly not «dumb AI generation.» But if you now say that you «don’t care» — it’s not quite clear why you chose to throw around such loud technical accusations at the very beginning without understanding the architecture.

In any case, I am glad that we ultimately agreed that your main message was about marketing and sales. On that front, you are absolutely right — a buyer is first interested in the «wrapper» and the frontend. I am truly grateful for that advice; I’ve heard you and am already working on it. Thank you for your time. Best of luck!

+ If you’re interested, I would like to update you on the avatar situation: WebP cropping (200x200) and Directory Sharding have already been implemented in one isolated Service. You can check the result in DevTools — new avatars weigh only 4 KB, and files are distributed into subdirectories for better performance.

Here is a snippet of the implementation:

php // Sharding path generation $hash = md5((string) $user->id); $shardingPath = "avatars/users/" . substr($hash, 0, 2) . "/" . substr($hash, 2, 2); // Image processing $image = $this->imageManager->read($file->getRealPath()); $image->cover(200, 200)->toWebp(80);

This is exactly why the logic was separated into Services in the first place — to make such updates quick and localized.

Я не понял на какой комментарий Вы ответили, т.к. я не давал таких утверждений. Я написал, что ваш подход с проработкой бэкенда, который не видит потенциальный покупатель и халтурой во фронтенде в корне неверный если ориентируетесь именно на продажи. Но дело ваше и ваш кошелек. Хотите принимайте советы, хотите дальше воображайте, мне всё равно

You are once again trying to force your narrative about a «bad LLM» onto a piece of technical debt that we are discussing for the third time now. As I have repeatedly agreed with you — yes, the current raw avatar upload process without WebP and thumbnailing is an MVP flaw, and you are absolutely right about that. But you call it an «AI context loss,» which is fundamentally wrong. Look at how the upload is implemented in the code right now:

php class AvatarStorageService { public function store(UploadedFile $file, Model $model): string { $subdirectory = $this->getSubdirectory($model); // Basic file saving (which will be upgraded later) $uniqueName = $modelId.'_'.uniqid('', true).'_'.time().'.'.$extension; $path = $file->storeAs($subdirectory, $uniqueName, 'public'); return 'storage/'.$path; } }

The upload logic is strictly encapsulated in a dedicated AvatarStorageService class. Why? To fully adhere to the Single Responsibility Principle. If an «LLM lost context,» the entire file saving routine would be thrown together in one monolithic chunk directly inside the Controller. Abstracting this algorithm into an independent Service pattern proves that the architecture was designed for scalability from day one: in order to implement your valid fixes (WebP, 48x48 thumbnail generation, and directory sharding), I don’t need to rewrite the system. I only need to update exactly one store() method in one isolated class. This isn’t an «AI mistake»; this is pure SOLID architecture — a prepared foundation that allows for painless implementation upgrades when the time comes.

You act surprised that I care about transactions while there is no traffic. In absolutely any application that handles balances (points, credits, ratings), preventing race conditions is the concrete foundation. If your user balances break because someone double-clicked or sent 10 concurrent requests, you have to roll back the database, and the app’s economy will crash on day one. A heavy avatar is just extra bandwidth consumption that gets fixed with exactly one commit implementing Intervention/Image and one script to compress old files in the background. Bulletproof data integrity comes first, static asset optimization comes second.

Regarding your claim that scanning a million files will ruin the project. I am writing this yet again: Nginx and Linux do not physically scan directories during direct URL access. When a browser requests a specific file, the operating system performs an instant inode lookup. This is an operation with O(1) time complexity, and the server absolutely does not care whether there are 10 files or 1 million files in the folder — the speed of serving via an exact path will be identical. The only bottleneck will be the filesystem’s hardware limits on the maximum number of files per directory (which is exactly why directory sharding is done), not some mythical prolonged directory «scanning».

And now the most important part — your comment that «Laravel on Shared hosting is immediately a minus». Believe it or not, the ability to sustain high loads on cheap Shared hosting is a killer feature of the project, stated directly in the description. Since you cannot see the source code, I will explain how it works under the hood: background tasks that update user statuses process data queries strictly using ->chunk(100). Why? So it doesn’t exhaust the laughable 128MB memory_limit on a cheap plan when processing 50,000 users. And when the system detects a status desynchronization for a user, it doesn’t slow down their page load; it uses the dispatch(…)->afterResponse() pattern. The server instantly returns the compiled HTML from the cache in milliseconds, closes the TCP connection to the browser, and only then quietly synchronizes the database in the background. It is exactly these HighLoad patterns that allow the engine to fly even on the cheapest Shared hosting environments without risking a RAM crash.

As for the «wrapper» and the marketplace buyer’s perspective — here I agree with you 100%. The mass marketplace buyer doesn’t look at atomic locks; they look at page load times and beautiful pictures right here and now. From a sales standpoint, the current lack of generated thumbnails in the demo is a marketing oversight on my part that ruins the showcase, and I will close this technical debt in the very next patch.

In any case, I truly appreciate your advice from a marketing perspective — perhaps I really am presenting the project incorrectly «from the outside». But I respectfully ask you not to throw around loud technical accusations (about AI context loss, «scanning» millions of files, or code crashing on Shared hosting) that objectively have no basis in reality and are disproven by the actual patterns in the project.

Серьезно? Вы пишите блокировку транзакций, но аватар неважен, т.к. нет трафика? Если вы одиночка и продаете код, то как покупатель может оценить его? Вы же не оупенсорсный проект, код не видно? Ну вот я, как покупатель зашел и посмотрел. По работе сразу вопросы. По LLM я написал именно поэтому. Это типикал ошибка LLM. Она теряет контекст. У вас транзакции(пока трафика нет, серьезно заботитесь о блокировке транзакций?) проработаны, которых никто кроме вас и покупателей не увидит, но не проработана генерация условных аватарок, которая похерит всё при росте. Это будет бутылочным горлышком. Я вам уже раза три сказал про то, что сканирование дирректории с миллионом файлов аватарок, тем более в таком размере это непроработка архитектуры, которая при росте пользователей погубит проект, а не транзакция если ваше приложение не банковское. Я как покупатель посмотрел: Laravel - сразу средний хостинг. Шаред минус сразу. Посмотрел на портянки и загрузку на пустой странице в 2 секунды - сразу VPS с норм тарифом. Посмотрел раскрытие id без необходимости, все аватары в одной директории - при масштабировании придется всё переписать. На этом я как покупатель, который ознакомился именно с тем, что продают принимаю решение точно не брать. Если вы просто для продажи, тогда акценты перестройте. Покупателю не важны ваши транзакции, которые не видят сам код. Они оценивают то, что видят, а видят сомнительный интерфейс, как из под LLM, видят архитектурные проблемы, видят портянки и думают, что в серверной части такая же ерунда. Всё. Я понимаю, что вам важно продать, но вы, возможно, конфетку заворачиваете в обертку из г.на.

Are you trying to catch me on something I openly admitted in the very first paragraph of my last post? I explicitly wrote that I work in tandem with an MCP server (laravel-boost), to which I gave strict systemic, architectural prompts and contracts. Of course, I use the power of LLMs. A programmer in 2026 who doesn’t use AI to write routine code within their own architectural boundaries is a dinosaur. My value as a founder isn’t in manually typing public function, but in forcing the AI to write FAANG-level transactional code without spaghetti. And, as you just noted yourself — I succeeded perfectly at that.

Now to the question: why such «childish» avatar mistakes in a complex architecture? The answer is simple: Business Prioritization. I am a solo developer. I have a limited resource of time. What is more important when launching an MVP: writing bulletproof point transactions (so the business doesn’t lose money and the economy doesn’t crash through race conditions), or configuring the generation of 48x48 webp avatars, which affect nothing while the project has no traffic? A «childish mistake» is when user balances drop. An uncompressed avatar is just controlled technical debt, which is closed with a single 30-minute ticket. You are evaluating a commercial MVP by the criteria of a large corporation. And if I were building a HighLoad system guaranteed to handle 20 million users right out of the gate, I certainly wouldn’t be selling it for pennies on Codester. But I am honestly glad that you took my script so seriously and immediately pictured it running a 20-million user base, honestly! 😊

By the way, a quick technical note regarding: «will the request scan 20 million files in one directory?» That’s exactly the point: it won’t. A web server (like Nginx) or the filesystem does not «scan» a directory upon direct URL access (/storage/avatars/hash.jpg). It performs an instant inode lookup, which operates in O(1) time. A directory only starts lagging if you try to ls it on the server. Directory sharding is needed to bypass the OS limits on file count, not because a web server «scans 20 million files» to serve a single image.

Thanks for the review! And the media file issues you pointed out are completely valid and helpful feedback that I will definitely address in the upcoming patches — thankfully, the architecture makes it painless to integrate. 🤝

Такой код генерирует Claude opus 4.6. Части написаны хорошо, но с оговоркой. Слишком мало кода, что бы давать оценку. По данным блокам да, видно опытного программиста. Но с такой типизацией как Block в замыкании? Используете все и сразу паттерны, которые используют в крупных проектах и по частям. Либо вы из FAANG, либо хорошо проработали инструкции для LLM. Я не понимаю, как вы, используя столько паттернов в гонке, делаете такие детские ошибки с теми же аватарами? Я задал вопрос: сейчас у вас аватары в таком виде: https://mediamix.codequadrum.com/storage/avatars/users/3_69a9f92ecd5c29.35670582_1772747054.jpg Т.е. 1 директория на сколько? Если будет 20млн пользователей, то запрос будет сканировать 20млн файлов в одной директории? Для чего такой длинный хэш аватара? 10 стмволов - это 3.7 квадрилиона вариантов. у вас timestamp + id + хэш. Зачем в аватаре расскрываете id пользователя? в данном примере user id =3. Какая необходимость в этом? Это архитектурная ошибка. Открыли id просто так. Почему не используется конвертация в тот же webp? Если вы поддерживаете такие большие Аватарки, то почему не генерирует превьюшки 4848 или 6464? С таким кодом, который вы представили на транзакциях и такими детскими ошибками во вьюшке, я уверен, что код писал opus

You say that I’m «answering like ChatGPT». I simply structure my thoughts to keep them clear and avoid fluff.

But let’s go back to your initial conclusion that my entire project is just «mindless AI generation». You made this conclusion by simply looking at the site from the outside. When it comes to coding, I don’t simply copy-paste from a basic chat. I use a specialized MCP server, laravel-boost, which reads the database, understands the project context, and strictly follows the architectural boundaries, layers, and contracts that I explicitly defined for it. That is exactly why this project hasn’t turned into the big ball of mud that basic LLMs usually generate without context.

You asked to see the classes and traits, claiming «all of this is native to the framework». No, it’s not native. In my project, chaotic circular dependencies — the hallmark of bad legacy — are physically forbidden by an architectural linter (deptrac). Part of the config:

ruleset: Controller: - Service - Model - Contract Service: - Model - Contract - Job Model: - ValueObject - Contract

No spaghetti code. The Service does not know about the Controller, and the Model cannot trigger a Service or a Job. If you try to execute business logic services inside a Model, the CI build will drop instantly. This isn’t «out of the box», this is a deliberate enforcement of architectural layers. A raw AI prompt doesn’t configure deptrac for itself.

Here is an example of my contracts. I have 12 of them in app/Contracts/: PostServiceInterface, UserServiceInterface, CommentServiceInterface, LikeServiceInterface, etc. Every service implements only its own interface.

interface PostServiceInterface { public function create(User $user, array $data): Post; public function update(Post $post, array $data): Post; public function delete(Post $post): void; }

Regarding traits — I have three custom ones, none from Laravel. Here is a snippet of the custom Blockable trait for polymorphic blocking (User/Post/Comment):

trait Blockable { public function isBlocked(): bool { // N+1 problem optimization via eager loading if ($this->relationLoaded('blocks')) { return $this->blocks->filter(fn (Block $block) => $block->expires_at === null || $block->expires_at->isFuture() )->isNotEmpty(); } return $this->blocks()->active()->exists(); } }

I have 129 service classes (across 32 domains) in app/Services/ and 43 event listeners. My architecture is event-driven. Here is what race condition protection looks like when awarding points:

// Atomic lock so two simultaneous events (likes) don't award points twice Cache::lock('points_like_'.$post->id.'_'.$user->id, 5)->get(function () use ($post, $user, $postOwner) { // Transaction idempotency check $lastTransaction = PointTransaction::where('user_id', $postOwner->id) ->whereIn('reason', ['like_received', 'like_revoked']) ->where('payer_user_id', $user->id) ->latest()->first(); ` if ($lastTransaction && $lastTransaction->reason === 'like_received') {` ` return; // Already awarded` ` }` // Notification fires ONLY if the transaction was committed successfully DB::afterCommit(function () use ($postOwner) { ... }); });

Atomic locks, afterCommit hooks, transaction idempotency checks. Show me a framework where this comes «out of the box» as simple AI generation? The code passes PHPStan level 9 validation — the absolute maximum level of static analysis.

+ Regarding your claim about «generation time,» where you say the app acts like it’s high-load — you are confusing TTFB (backend response time) with browser static asset loading. The backend builds the page and returns HTML in milliseconds because database queries are cached via my custom CacheService. What you see as 1.65 seconds in DevTools is the downloading of fonts, those unoptimized images, and JS bundles on a cold cache from a cheap VPS. Obviously, a site with a lighter frontend will load its assets faster. It’s a question of frontend payload delivery, not backend heaviness.

You further complained about «constant rendering and reloading» that pulls «megabytes of styles» and suggested moving to React or Vue. But here you’re technically mistaken — the project does not do full page reloads upon navigation at all. The TALL stack intercepts routing using the History API. When you click links, an AJAX request swaps out only the necessary piece of the DOM. This is the exact Single Page Application (SPA) behavior you mentioned, just without state duplication. No «megabytes of styles» are pulled again; they are parsed once and remain in the browser cache.

As for the avatars themselves (1024 down to 48, 16+ character names, and everything in one directory) — I unconditionally agreed with you on this in my first response. These are 100% valid observations. The intervention/image package is already installed, and generating thumbnails, migrating to UUIDs, and implementing directory sharding are top-priority backlog tasks. I’m not going to argue against obvious technical debt.

You wrote: «Honestly I don’t want to scrap someone’s hard work, so good luck, but it’s not Legacy and not for production.» But you already tried to scrap it just by looking at the Network tab and confusing the loading of a static font without a CDN with the backend architecture — and that is not a serious approach. A product where deptrac physically forbids spaghetti code, where the caching layer idempotently protects the business logic from race conditions, and where the entire codebase passes level 9 static analysis — is far more production-ready than 90% of the hand-written «out of the box» projects.

If you are genuinely interested in discussing the architecture transparently, rather than guessing via DevTools, I am ready to provide access to the code. If you find chaos in the codebase — I will be the first to admit I was wrong.

Послушайте. Вы сейчас отвечаете как ЧатГПТ. Всё что перечислили это нативное в фреймворке. Покажите ваши классы, фасады, трейты. Если у вас включено кэширование, то такое время на генерацию это отсутствие оптимизации. На странице 3 поста. Всё. Если будет лента? Даже с асинхронной загрузкой на пустом сайте не должно быть такого. Используете VPS? Вот без пользователей с тремя демо акками у вас уже как высоконагруженное приложение работает. Вы пишите пост на ресурсе, который с комментариями, ссылками и прочим грузит в разы быстрее, чем ваше приложение без пользователей. Покажите часть кода если вы хотите устроить проверку своему приложению. Я вижу аватары 1024 пикселя, которые грузят в иконку размером 48пикселей. Ларавель мощный движок, но постоянный рендер и перезагрузка страниц при таком количестве js модулей, стилей. Поверьте, создатель фреймворка не может 100% оставлять свое мнение ко всем проектам. На вашем SPA обязательно. Без сингла это оверхед перезагружать такие страницы. И да, в таком случае vue.js, react. Либо смотрите на этот проект, поменяйте стек разработки. Посмотрите на количество подгружаемой архитектуры каждый раз при перезагрузке. Если вы тащите мегабайты стилей, то даже при кэшировании в браузере у вас на каждую перезагрузку страницы тянутся портянки стилей и кода. Нейминг аватаров в 16+ символов для чего? Такие даже в условном x.com не нужны. Не хватит пользователей на земле. + Всё в одной директории. Ну-ну. Когда будет миллион аватаров в одной директории? Я пишу с телефона и мне честно, не хочется чьи-то труды браковать, поэтому успеха вам, но он не Легаси и не для продакшн.

Thank you for taking the time to look at the project. However, a number of claims don’t hold up against what’s actually in the codebase. Let me address them point by point.

«Zero architecture»

The project includes: 129 service classes with domain separation (posts, caching, economy, avatars, etc.). 50 controllers, 12 contract interfaces, 10 authorization policies. 50 validation classes extracted from controllers. 26 events and 43 listeners for event-driven logic. 20 models, 17 factories, 7 middleware, 94 tests. An architectural linter (deptrac) that enforces layer dependencies, a controller cannot access the database directly, only through a service. PHPStan level 9 (maximum) for static type analysis.

Yes, AI was used as a tool. But the architecture is deliberate, layered, and enforced through tooling. This isn’t «accept and move on», it’s managed development.

«No basic caching»

Caching is implemented at multiple levels: A unified caching service with tag support. Cache tag management with race condition protection via locks. Dedicated cache services for posts, users, and metadata, with targeted invalidation, not flush-all. 8 event listeners for automatic cache clearing on data changes (likes, comments, moderation, etc.). Cache warming. Admin panel for cache management with tag/key-based clearing.

HTTP responses showing up in DevTools doesn’t mean there’s no caching. Data is cached at the application level.

«Using Laravel without Vue.js is an anti-pattern»

Laravel + Livewire + Alpine.js is the official stack promoted by Laravel’s creator Taylor Otwell. Laravel Breeze offers Livewire as a first-class option alongside Vue/React. Livewire 3 is a full-featured tool for building interactive UIs without the need for a separate SPA. Calling the official stack an «anti-pattern» suggests unfamiliarity with the ecosystem’s current direction.

«Pulling a Node.js server»

Node.js does not run in production in this project. It’s used exclusively for frontend asset compilation (Vite). Only PHP runs in production. The sole runtime JS dependency is Alpine.js (~15 KB gzipped), comparable in weight to jQuery.

«VPS starting at 2000 RUB/month minimum»

Laravel with OPcache on a 300-500 RUB VPS comfortably handles thousands of users. This claim isn’t backed by any benchmarks or concrete metrics. The «dead code» of unused Laravel classes is never loaded into memory, PHP uses an autoloader that only includes classes when they’re actually referenced.

«15/31 requests, 1.6 MB, 3.21 sec»

Without specifying test conditions, these numbers are meaningless. Results depend on: server location, CDN presence, nginx/Apache configuration, gzip/brotli compression, and browser cache state. On a cold first load without cache, these figures are normal for any application with custom fonts and images.

What genuinely needs improvement (and is planned):

1. Avatars: yes, the original image is currently served without a thumbnail. intervention/image is already installed; generating thumbnails is the next step.
2. User ID in avatar filename: agreed, using a UUID would be better practice. It’s not a critical vulnerability (user IDs are visible in profile URLs on most platforms), but it’s a good practice to follow.

These two points are the only substantive items in the entire review.

Yes, I use AI as a tool during development. But using AI and blindly accepting its output are two different things. deptrac doesn’t configure itself. PHPStan level 9 doesn’t pass without manual work on type safety. 94 tests don’t write themselves without understanding the business logic. Architectural decisions, contracts, layers, event-driven cache invalidation, are the result of deliberate design, not «accept and move on.» AI accelerates writing code, but I set the direction.

By the way, the project doesn’t handle sensitive user data, and the work isn’t priced at some outrageous amount, although it could be. And those very same LLMs you’re pointing at can fix the noted issues in seconds, that’s exactly the power of the tool.

If you’re genuinely interested, I can provide the source code. I’d be happy to hear feedback based on actual code, not the Network tab.

P.S. The recommendation to «learn architecture first» is rather ironic coming from a review where not a single project file was examined, and all conclusions were drawn from the Network tab in DevTools.

Эх, а я все закрыл, пришлось отказаться от сервера, потому что Beget берега попутал с повышением цен, переехал на новый хостинг, чтобы там повесить свои дохлые форумы, ну а сайты на Libarea к сожалению на хостинг не повесить, пришлось драпать.

Отлично, обновился!

Вовремя зашел, спасибо!

Не, там проблем море. Всё это посыпется однозначно. Прям вижу руку вайбкодера. Это генерка чистая. Там архитектуры ноль. Нейронка всегда на ларавель пишет, потому, что это самый полпулярный фреймворк. Но это для 80% сайтов бесполезный фреймворк потому, что 80% возможностей пользователь будет тащить за собой не используя их. Это мертвый код в легаси.

Если посмотреть сколько он тянет всего, то ясно, что на базовые потребности нужен уже средненький сервер и шаред хостинг не пойдет. С учетом нагрузки и роста числа пользователей, произойдет коллапс, т.к. в описании не вижу хотя бы базового кэширвоания. + nodejs сервер или чисто зависимости тянет, неясно. Это история для VPS с тарифом от 2000р в месяц минимум, прям на старт.

+ Просто беглый просмотр.

<div class="w-12 h-12 rounded-full overflow-hidden bg-gray-100 dark:bg-gray-700 shadow-sm ring-2 ring-gray-200/50 dark:ring-gray-600/50 group-hover:ring-brand-300/50 dark:group-hover:ring-brand-500/30 transition-all duration-300">
<img src="https://mediamix.codequadrum.com/storage/avatars/users/3_69a9f92ecd5c29.35670582_1772747054.jpg" alt="User" loading="lazy" class="w-full h-full object-cover">
</div> 

вот это тянет аватарку размером 1024x1024 px. Для чего? Нужен хотя бы crop или ресайзер, или хотя бы thumb версия. Ну и раскрытие id в нейминге аватара - такое себе решение. Этот пользователь имеет id=3. Подготовка к сбору данных для потенциальной атаки. Тем более раскрытие без необходимости. Портянки css и js можно решить кэшированием на клиенте, но все равно для такого ресурса это оверхед. Ну и использовать ларавель без vuejs странно. Это как антипаттерн. Прыгающий экран на таком стеке? Если тащить node, laravel то только one page реализация, тем более с такими показателями:

Запросы: 15/31 Перенесено 1.6 MB/1.6 MB Ресурсы 119 B/2.1 MB Завершено: 3.21 сек. DOMContentLoaded: 1.65 сек.

П.С. Автору рекомендую сначала заняться пониманием архитектуры, что бы вайбкодить, но управлять и направлять LLMки, а не потакать им и принимать все их решения, как легаси код. К каждой генерации относиться критически, что это плохой код и искать слабые стороны.