Пытаюсь разобратьсяс динамическим импортом компонентов, нашел пример https://svelte.dev/repl/ec6f6b61329f4f43ae049464d73d8158?version=3.23.1, но при

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

В том что нельзя передовать путь как переменную. Потому что значение переменной устанавливается в момент выполнения, а сборщик который собирает бандл, ничего про это не знает

а какой нибудь вариант можно придумать, чтобы не перечислять заранее все возможные варианты импорта? Я просто хотел с БД подтянуть нужный выриант импорта, и подставить его

В NEXT js я так делал - const MyComponent = require(./${component}).default

В общем, я программист постольку поскольку, просто делаю для себя небольшой каталог товаров. При этом у меня больше сотни категорий товаров с разными параметрами для отображения. Перед тем, как начинать вручную прописывать пути к импорту этих параметров, решил еще раз проверить не в REPL, а именно в своем проекте невозможность использования переменных в путях. И, вуаля, не знаю почему, но у меня работает - получаю из БД по фетч нужный параметр, подставляю его, и все работает.

Дело не в Свелте а в билдере. Кит умеет в динамические импорты, но пока не умеет работать с $lib

Ну в общем заработало, как ожидалось, и ладно. Я вообще скелет программы написал на next.js задплоил на хероку, и оказалось, что на бесплатном варианте хостинга моя прога падает. Оказалось, что по дефолту запущенный некст js выжирает сразу почти один гиг оперативки, сразу внимание даже не обратил. А когда начинаешь кликать , переходить по ссылкам, в пиковые моменты до 2.5гб начинает занимать процесс . Методом тыка пришёл к svelte, затем к kit варианту. Пока не видел, чтобы более 100мб ело. В итоге сейчас переписываю.

Чет это как-то дохера.

Мне кажется что SSR глупая затея, nuxt next sveltekit, не выдерживают нормальных нагрузок, даже если вам прилетит атака в 2-3к запросов в секунду (что совсем мало) ваш SSR будет валяться полудохлым

Да и удобств у SSR не много

next.js дохера? Сам немного обалдел. Начал гуглить, и оказалось, что для последних версий норм, народ а форумах реально на деплой на хероку жалуется, переходят на более дорогие платные версии хостинга и жалуются.

Нужно делать кеш на стороне nginx, не забывать про кеш эндпоинтов.

А какие варианты? Посмотрел готовые движки интернет магазинов, начиная с того же битрикса, чтобы сделать именно так , как мне надо, надо погрузиться и потратить времени на разработку не меньше(или больше), плюс хостинг нужен платный, да и сам битрикс платный . И в php я на околонулевом уровне. Писать на ванильном js можно, с бэкендом на express, и с библиотекой socket io, я курсовую делал как раз так. Именно так и хотел уже, переписать после next.

Не думаю что поможет, я занимался атаками, кэширование обойти можно, и много «стрессеров» могут обойти кэширование, а про людей которые делают атаки на заказ, я вообще молчу

SSR нужен в первую очередь для двух вещей: - Быстрее показать отрисованную страницу пользователю. - SEO — роботы всё ещё не умеют в JS

Я пишу на Golang бекэнд, и на vite + svelte

А какой смысл от быстрой отрисовки, когда сервер упадет?)

Мы же не про атаки говорим, а про высоконагруженные сервисы. Для обхода атак используются другие инструменты.

Ну вот, даже если будет 5к юзеров одновременно на пике, вы упадете

Ну так там и не один сервер будет.

увидел тут такой вот репл

А никаких, да писать либо кушать что дают и плотить. Все эти битриксы для этого и создавались, что бы вы плотили.

Я говорю про то что, на том же Golang вы сможете «сожрать» 180 тысяч запросов в секунду на 8 ядрах (M1 Pro), на Sveltekit - 4-5k rq/s (Не учитывая канал даже). Прийдется больше платить на сервер, и за сеть)

Спасибо, возьму на заметку, на будущее, но сейчас погружаться в новую технологию пока физически времени нет (((

Возможно никого не интересует отказоустойчивость сервера, возможно кто-то еще не получал атаки 50-60 тыщ запросов в секунду Но меня очень сильно волнует что при даже самой маленькой атаке я слягу, у меня веб на Adonis (помогите), 2к запросов в секунду и ты слёг, поэтому сижу переписываю все, наверное когда я его выбирал, то я руководствовался удобством, ибо он очень похож на Laravel.

На данный момент если мне предложить что-то написать, то я не выберу для бекэнда ноду, ибо слишком много проблем. Да, нода прекрасна, но до поры до времени, пока Миша с 3В не начнет атаку с стрессера за 5$ в месяц 🤷‍♂️

проблема в том что сср нужен для сео)

Мне тоже нужна мета, я просто рендерю то что мне надо на стороне сервера, и кэширую на пару минут

А если за Cloudflare спрятаться - может помочь?

Не)

Back на aiohttp не топальто?

И тут сервера Netflix на ноде, выдерживающие и атаки и обычные соединения сказали: «ну да ну да, пошли мы нахрен»

Сорри не смог пройти мимо. Звучит как сказка. Получается по 20 000 rps на ядро. Или 50 микросекунд на запрос. Сюда по идее и обращения к хранилищу должны влезть и логгирование и авторизация. Есть пруфы?

Эт plaintext bench

ну можно и 1млн на "гошке", только это все немного про другое) https://github.com/smallnest/1m-go-tcp-server

Ну это совсем другое, тут просто про держать 1M коннектов. И проблема изначальная была про 10М - вроде есть решения типа таких: https://github.com/haoxiaolong/10M-Server

А смысл сравнивать plain text с реальной бизнесовой нагрузкой? Для последней и 1000 запросов на ядро - офигенно. Это 1 миллисекунда на всё-всё-всё.

Ну а как по другому что то сравнивать? Мы же не на бизнес логику делаем бенчмарки

Ну логично сравнивать то, что чаще всего используется. Реально plain text практически нигде не нужен, это экзотика. А вот определить набор базовых функций, которые чаще всего нужны (получение запроса, проверка авторизации, логгирование, выборка из хранилища данных, сериялищация ответа) и на них тестировать выглядит полезным 🤷‍♂ Сама бизнес логика конечно специфична, ее не сравнить, но можно взять что-то типа real world

глянул последний прогон techempower бенчмарка, по плейнтексту лучший результат на го на данный момент на 10 месте, а по условно реалистичному тесту fortunes - 19 и 20 места, причём другие библиотеки, не та из гошных, что на плейнтесте лидировала. как-то так. а вообще, это всё бессмысленная фаллометрия.

Вот да, более реалистичные приложения требуют чуть другой заточки, поэтому ориентироваться на абстрактных попугаев может быть не совсем точно

На Techempower смотрят многие разработчики библиотек и проводят оптимизации. Насколько я знаю разрабы asp net core ориентируются на данный бенч и они существенно ускорили entity framework (ORM для C#) https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-6-0-preview-4-performance-edition/ из за того что в бенчах он проигрывал dapper. И еще по схожим причинам оптимизировали kestrel(веб сервер для asp net core) до такой степени что он теперь в бенчах по plain text всегда в топ 5. В целом из за оптимизаций под бенчи asp net core стал одним из самых быстрых.

Именно, судя по ускорению entity framework они явно не plain text анализировали, а весь процесс в целом