Речь идет о том, чтобы саму куку создавать на клиенте. Технически, её назначает не бекенд, а значит nginx все так же сможет закешировать такой ответ.
В таком случае да, вариантов не особо много.
Да, это в основном делается с целью оптимизации. Дело не в количестве запросов, а в том, как быстро клиент получит "хоть что-то". Если юзер не аутентифицирован, но у него есть корзина, он получит общий ответ как и для всех, за исключением блоков корзины, вы посмотрели товары, и "рекомендуем к покупке на основании вашей корзины". Эти блоки можно получить динамически. А общий ответ (каркас страницы, все остальные данные) из-за кеша будут получены за время пинга, а не пинг + сколько-то мс. на генерацию.
Я вообще делал такую штуку: приходил запрос, на генерацию ответа отведено 10 мс., если за 10 мс. бекенд не успел сгенерировать ответ, он отвечал статусом 202 Acepted, в теле ответа отдавал ссылку, по которой будет доступен ответ, и время, через которое за данными нужно прийти. А на фронте просто крутился лоадер.
А какие варианты вы знаете? Есть два способа: сессии и какой-нибудь JWT.
JWT хорош тем, что клиент присылает тебе все нужные данные сразу, т.е. там хранится пользователь (id, login), и вся нужная инфа, чтобы не ходить в другой источник данных для получения этой инфы. При этом ты можешь верить этим данным, а пользователь может их читать (если сервер этого захочет). Но минусы, это то, что ты не можешь делать токен rewoke, тогда придеться делать какой-то шареный стейт, куда писать все токены, которым больше нельзя доверять. Тогда смысл всей идеи теряется. На своих проектах давно юзаю JWT, так как мне лень вообще пилить сессии собственноручно, ну и под формат SPA больше подходит, т.к. обычно фронт должен отрисовать инфу про юзера, которую он может получить один раз из JWT.
А те минусы что вы описали, про мемкешед, базу, файлы, это все не проблема сессий, а проблемы хранилища.
zACz, это уже другой вопрос. Во-первых, поисковый робот будет долго индексировать ваш сайт. Во-вторых, те страницы что показывают 404 ошибку отвечают статусом 404, так что тут все ок.
Возьмите любую страницу с которой вы испытываете проблемы, зайдите в Google Webmaster, вбейте её URL в раздел "Проверка URL", там будет кнопка изучить просканированную страницу, в ней сможете увидеть HTML код и скриншот как бот видит эту страницу. Если там пустая страница - тогда есть повод беспокоится.
zACz, просмотр исходного кода страницы - это то что ответил веб-сервер, а в F12 актуальное состояние страницы, включая работу всех скриптов. Google уже давно индексирует динамический контент, главное чтобы он формировался быстро а не пол часа.
У вас в индексе везде разные тайтлы и разный контент: https://www.google.com/search?q=site%3Amcicon.com&oq=site%3Amcicon.com&aqs=chrome..69i57j69i58.2670j0j7&sourceid=chrome&ie=UTF-8
Возможно речь про какие-то другие поисковики? Яндекс, Бинг?
Ну если закрыть глаза на то, что человек выше пишет блог, а не интернет-магазин, то:
для аутентифицированных - в базу, для не авторизованных - в клиентскую куку, подгружать динамически при попадании в область видимости (через Intersection Observer API например)
для аутентифицированных - в базу (чтобы можно было бы набрать корзину дома, а оформить с мобилы в пробке или метро), а для неаутентифицированных - придеться начать сессию. Но это можно сделать после добавления первого товара, а не сразу. При этом саму информацию о корзине (которая обычно выводится в правом верхнем углу) можно так же получать по публичному API.
Это лучше вообще запретить для неавторизованных, люди добавляют в избранное, потом куки чистятся и все теряется. Лучше сразу предложить пользователю завести аккаунт.
Вообще, не стоит создавать инстанс того, в чем нет необходимости, будь то кука, файловый дескриптор, коннект, etc.
Почему не индексируется? Ваш сайт есть в поиске гугла (возможно не все страницы). Vue не нужно компилировать чтобы сайт индексировался, это опция для запаковки шаблона внутрь рендер функций.
Ну хотя бы просто потому, что зачем запускать сессию, если пользователь не авторизован (правильнее говорить не аутентифицирован, но в данном случае пусть будет уже так)? Есть session_status для определения есть ли для конкретного пользователя сессия. Если сессии нет, то вероятно он не авторизован. Запуская каждый раз сессию, nginx не сможет отличить авторизованных пользователей от гостей, т.к. вы будете постоянно присваивать куки PHPSESSID, а кешировать ответ с чьей-то кукой нельзя. Убрав и без того не нужную инициализацию сессии для неавторизованных пользователей, можно будет беспроблемно кешировать ваши ответы от PHP.
Можно сделать ленивую инициализацию сессий. А вообще, аутентификацию лучше делать в миддлвари, и если юзер аутентифицирован, то передавать данные о нем в следующий хендлер, чтобы он читал не из глобального стейта данные, а из входящих параметров. Любой глобальный стейт лучше избегать по возможности.
Этот вызов можно заменить на:
public static function start(){ if (session_status() === PHP_SESSION_ACTIVE) { session_start(); }}
А на странице аутентификации после успешного входа ручками вызвать session_start (а ещё лучше сделать враппер через статический метод на том же классе, который у вас уже есть).
И скорее всего, все будет хорошо.
Так лучше не делать. Сессию нужно запускать тогда, когда она действительна нужна (например, запрос с действием).
ArbNet,
http://arbnet.ru/shop/main
А тут будете мёрч с логотипами arbnet продавать?))
Пилите свой фреймворк и никого не слушайте. Другим от него профита не будет скорее всего, но вы многое для себя поймете (включая то, что вам тут говорят). Я уже не раз говорил, пока сам не напишешь сотни своих поделок, никаких выводов не сделаешь. Чужие шишки не работают, человек всегда учится только на своих ошибках.
Можно долго делать проектики на фреймворках, напрочь забыв как работают роутеры, почему в хороших роутерах используются деревья радикса (а не хеш таблицы и не бинарные деревья), и т.д.. Может показаться, мол, зачем это делать, все уже написано до нас. Импульсы в мозгу ходят от нейронов к нейронам по протоптанным тропам, не задействуя остальные части мозга, когда применяется сфокусированное мышление. Делая что-то не привычное для мозга, например пойти новой дорогой, освоить новое дело, приготовить еду (если никогда её не готовил), написать свой роутер (желательно эффективный и гибкий) - это все дает мозгу неплохую встряску. Благодаря такому подходу, после рыбалки например, или какого-то активного отдыха, часто приходят очень хорошие идеи или мысли для решения какой-либо проблемы.
Вы прочитали только первую половину. Да, есть. Но это есть почти в любых ORM.
Аннотации над типами хорошо, когда поддержка аннотаций у структур и свойств зашиты в язык, а сам язык предоставляет библиотеку для AST парсинга, тогда можно взять файл, распарсить его, и сгенерировать из него абсолютно что угодно. А когда у тебя есть то что вы написали выше, а вам оттуда надо получить дерево зависимостей, тогда вы вспомните про yaml файлы :)
Но тут уже от задачи зависит, не всегда приходится писать код, который пишет код.
Что-то из этого может и умеет, но точно не все. Вообще, не хватает декларативного языка в котором можно будет описать все необходимое для проекта в 2к20, а имплементацию сгенерировать под любой язык. А-ля grpc и protobuf, указал данные, указад rpc методы, кнопочку нажал, и получил интерфейсы, которые осталось реализовать/сшить с уже имеющимися сервисами.
ivan-lev, такое много где реализовано, вообще генерировать схему и связи это одна из задач ORM. Но фреймворков с интеграциями я не знаю. Например, ты описываешь сущность:
use {MaxLen, Required, Unique, WriteOnly} from "constraints"type User { id: uuid, login: String, MaxLen(16), Required, Unique, password: Bytes, WriteOnly, operations { create, read, update, delete, patch, } HasMany { ![]Post }}type Post { id: uuid, content: String, MaxLen: 4096, Required, url: String, Unique, HasOne { !Author: User, }, operations { create, read, update, safeDelete, patch, }}
Сгенерируются таблицы:
CREATE TABLE users ( id UUID PRIMARY KEY, login TEXT NOT NULL UNIQUE CHECK(char_length(login) < 16), password BYTEA NOT NULL)CREATE TABLE posts ( id UUID PRIMARY KEY, content TEXT NOT NULL CHECK(char_length(content) < 4096), author_id UUID NOT NULL REFERENCES(user), url TEXT NOT NULL UNIQUE, is_deleted BOOLEAN NOT NULL DEFAULT FALSE);CREATE INDEX posts_url_idx ON posts USING HASH(url);
В итоге, гарантируется валидность данных самой СУБД, можно делать обход графов, можно генерировать таблицы не только под PostgreSQL, но и под другие СУБД (MySQL, MariaDB, TinkerPop/Gremlin, и т.д.). Можно делать модели vue, которые потом подмешивать в свои страницы/компоненты. Генерируется сервер с нужными хендлерами (а под них и клиент, например axios+typescript).
Вообще, подозреваю, что такое уже есть. Я вот как раз стартовал свой проект на склейке из двух подобных инструментов (OpenAPI, ent), а получил кучу ограничений про которые не знал в процессе написания. То ORM генерирует дикие запросы (это можно побороть), то нет поддержки uuid в первичном ключе. То нет курсоров по строкам. И т.д.
А очередной XML конвертер в HTML имхо не особо нужен.
