Great question @nims !

UNA is not switching to the new stack. Instead we are creating a new frontend layer using the new stack. We choose to keep PHP for server side logic and MySQL for database. It may not be the most trendy and new combo, but modern PHP can be adapted to be very performant and it benefits from large pool of devs that can maintain it. Same goes for MySQL- it’s reliable, secure and scalable. Whenever there’s an issue chances are that there’s an extension or a tool that addresses it and it has been used in large scale production.

Now, frontend is different. There’s only so much you can do with HTML until some sort of JS framework is required. We decided to go with React for web and ReactNative for native. For web we use NextJS meta framework and for native we use Expo to streamline the development.

There is a lot more to it, of course. UNA is a complex platform so some components definitely call for other underlying solutions. For example, at scale certain calculations or queries may become cumbersome. This doesn’t mean that entire system needs to be rebuilt with another stack, which would ultimately underperform on some specific tasks anyway. Instead we need to embrace microservices architecture and isolate high load tasks to specialised workers, written and configured in a way that suits the challenge. For example, your feed calculation and associated queries may take 5 milliseconds with PHP and MySQL but at scale with large tables it may creep to, say, 5 seconds! If we do it in runtime the site becomes unusable. We could rewrite the whole app in something like Rust and use Postgres, but not only it would take 10 years - it would also make it much harder to find people to maintain it, documentation to understand it and tools to extend it. Solution? Instead we can isolate the particular issue and do things like adding multithreading to PHP, denormalising and cashing feed calculations, storing their cache in redis, etc etc. We can ultimately even create a separate Rust/Golang script that handles calculations and stores them in the most performant type of database. Point is that until certain workloads become large it’s best have everything handled by the most reliable and complete framework - PHP/MySQL is great for that.

With the new frontend we get data from the PHP server via json api and websockets. We still render most screens on server (with NextJS) and stream some of the data in asynchronously using dynamic imports. It’s a mix of rendering and routing strategies - different for web and native, different for spaciest types pages - feeds, browsing, static, lists, changing/unchanging etc. React unlocks a lot of new strategies and that’s what NEO is for.

Отличный вопрос, @nims!

UNA не переключается на новый стек. Мы создаем новый интерфейс с использованием нового стека. Мы решили оставить PHP для серверной логики и MySQL для базы данных. Не самое модное решение, но современный PHP можно адаптировать для высокой производительности и он пользуется большим количеством разработчиков, которые могут его поддерживать. То же самое касается MySQL - он надежен, безопасен и масштабируем. В случае возникновения проблемы всегда есть расширение или компонент который ее решает и проверен в крупномасштабном формате.

Мы решили использовать React для веба и ReactNative для нативных приложений. Для веба мы используем метафреймворк NextJS, а для нативных приложений - Expo для упрощения разработки.

UNA - сложная платформа, поэтому некоторые компоненты определенно требуют других базовых решений. Например, в масштабе определенные вычисления или запросы могут стать медленными. Это не означает, что весь системный стек нужно перестраивать с использованием других технологий. Вместо этого нам нужно использовать архитектуру микросервисов и выделить задачи с высокой нагрузкой на специализированные обработчики, написанные и настроенные таким образом, чтобы они соответствовали вызову. Например, расчет ленты и связанные с ней запросы могут занять 5 миллисекунд с PHP и MySQL, но в масштабе с большими таблицами это может увеличиться до, скажем, 5 секунд! Если мы делаем это в реальном времени, сайт становится непригодным для использования. Мы могли бы переписать всё приложение на Rust и использовать Postgres, но это заняло бы 10 лет, и было бы гораздо сложнее найти людей, которые могут его поддерживать, документацию для понимания и инструменты для его расширения. Решение? Вместо этого мы можем выделить конкретную проблему и сделать такие вещи, как добавление многопоточности в PHP, денормализация и кэширование расчетов ленты, хранение их кеша в Redis и т.д. В конечном итоге, мы даже можем создать отдельный скрипт на Rust/Golang, который обрабатывает расчеты и хранит их в наиболее производительном типе базы данных. Главное, что до тех пор, пока нагрузка не станет большой, лучше всего использовать наиболее надежный и полный фреймворк - PHP/MySQL.

С новым интерфейсом мы получаем данные с сервера PHP через json api и веб-сокеты. Мы отрисовываем большинство страниц на сервере (с использованием NextJS) и асинхронно передаем часть данных с помощью динамических импортов. Это смесь стратегий отрисовки и маршрутизации - разная для веба и нативных приложений, разная для разных типов страниц - ленты, просмотра, статических, списков, изменяющихся/неизменяющихся и т.д. React открывает множество новых стратегий, для чего и нужен NEO.