Разве Мобильному Приложению не нужен сервер для хранения БД, например пользователей?вы же ничего не написали про функционал, если это например какой-то интерактивный учебник, то все что нужно может храниться в самом приложении. Короче, без деталей вам насоветуют только общие какие-то вещи, так как телепатией далеко не все обладают...
У меня есть готовый рабочий прототип.Прям работающее приложение?
Нарисовала прототип со связями-ссылками. И уперлась в стену.Это не прототип, прототип это что-то, что можно использовать как рабочий образец для дальнейшего улучшения. То что у вас "нарисовала" - это называется use cases, хорошее начало, но к ТЗ имеет мало отношения.
не могу понять, как это повлияет на результат? Это же не какой-то отладчик, что выведет данные по ссылке и я посмотрю после всего скрипта, это непосредственно рапечатка данных.Угу, только вызываться она может не там где вы думаете, так как буферизация через ob_start().
а откуда на aws возьмутся разные размеры одного и того же изображения? Самим подготавливать и заливать заранее?Естественно. Так вы контролируете и нужное качество, и формат обрезки, и настройки ресайза...
Хочется это делать по запросу, без предварительной генерации. Вдруг на фронте решат что аватарки теперь будут не 200 пикселей в ширину, а 100.Пока универсального решения не существует, прегенеренные картинки могут быть не актуальны завтра, а все что делает это "на лету" требует процессора, причем чаще всего хорошо так жрет. Учитывая что запрашиваются они не по 1 штуке обычно, да и генерятся из достаточно больших исходных картинок, памяти и проца откусывается дай бог... По сути выбор между хранилищем и процом, причем чаще всего решения склоняются к варианту хранения набора, так как генерить на каждый запрос 100 картинок или запросить 100 готовых картинок это 2 большие разницы. Крайне редко происходят настолько крутые смены дизайна, чтобы все старые выкидывались или не подходили кардинально, просто берут ближайший подходящий размер и ресайзят средствами хтмл... Ну или создают и записывают новые размеры по мере запросов - нет нового нужного размера - создаем, записываем, отдаем. И так по мере запрашиваемости все потихоньку обновляется...
2) хм интересно. но это опять же, работа с изображениями на своей стороне, хранение на своей стороне.Хранение нет, только обработка. Но за нее вы все равно будете платить процессором и памятью, если не у себя, так у облачного провайдера, бесплатно это не будет. Естественно, готовые нарезки хранить сильно дешевле.
{
user: {
name: nameInput.value,
surname: surnameInput.value,
login: loginInput.value,
email: emailInput.value,
password: repeatPassInput.value,
age: ageInput.value
}
}о, дорогой, я вижу ты агрессивен и не адекватен в приёмах замечаний?Нет, если замечания по делу. Твой комментарий никакой смысловой нагрузки, кроме необоснованного почесывания чсв не нес, что я и отметил. Тебя, я вижу, это задело. Ну, оно и понятно, человек, чистящий свои посты ради рейта, к таким вещам как критика относится весьма отрицательно.
Нахрен name="title", name="description"Да, нахрен. Так как это вообще для другого предназначено, в частности для текстовых браузеров (как задумано изначально) и семантики поиска.
А вот схему мы линкуемИ зачем мне эта информация? Чтобы что? Чтобы рассказать что ты умный? Ок, понял, принял. Садись, пять.
А может лучше не og использовать? Может лучше tw, fb и т. п.?Может. Но работать не будет. Или будет. С og работает точно.
OpenGraph не стандарт, а стандарт схемы.О, спасибо, поправил мою глупую ремарку, ты очень внимателен, и главное сильно помог. Пирожок возьми.
$product->photos и четкого списка полей в бд/миграции.Ты хранишь в одной таблице все данные, соответственно нагрузка минимальнаяО, да, точно, "аптимизация" же, экономика спичек должна быть экономной и вот это все... Ну какая там нагрузка на джоинах двух табличек? Что за погоня за ускользающими микросекундами? С таким подходом проще вообще все в одну таблицу с 50 полями свести и все, профит, все летает (спойлер: нет)... И сложности с какими то там сущностями мутными отпадают...
Страницы установки и предварительной настройки современных популярных cms и в частности nextxloud, выглядят иначе. К сожалению, не будучи специалистом в разработке подобного рода приложений, я не могу сходу диагностировать, что именно. Но страница установки в частном случае не может подгрузить никакие изображения, не работают сценарии.Неверный визуал скорее всего обусловлен неверными настройками, например неверным каталогом установки. По вашему описанию сложно понять что конкретно не так, вам же нужно включить инструменты разработчика браузера (F12), раздел консоль, и посмотреть на ошибки возникающие при загрузке страницы. Тогда будет хотя бы примерно понятно в чем проблема. Не исключено что отсутствуют соответствующие настройки для нжинкса, например файлы статики не исключены из переадресации на единую точку входа...
После отправки данных идет задержка 3 секунды, пользователь может отправить форму много раз.то что человек не очень дружит с построением логичных предложений не повод читать только первое предложение из вопроса.
$product->photos-> ?Емнип прямого добавления через связь там нету, тем более что в результате в $product->photos у вас коллекция, а не объект. С фото работаете как с отдельными сущностями (собсно для этого они и вынесены в отдельную таблицу и модель).$product = Product::create([
'title' => 'custom title'
]);
foreach ($images as $image)
Image::create([
'product_id' => $product->id,
'url' => $image['url'],
]);