IK
Да не то чтобы “не дали”. Просто я как-то так настрадался с кешами, что если что-то работает без кеша — пусть лучше работает без кеша.
Size: a a a
2021 June 22
YL
В целом мне кажется это может иметь место как подготовка к переезду на микрофронтэнды те же
YL
Доменами в монолите мы различаем «кучки»
🚀🚀
к слову, в той же парадигме (serverless) в код сервера просто не попадут те части приложения, которые им не используются явным образом (их вытряхнет при сборке через dead code elimination)
YL
Да ответственность на исполнителе конечно но тем менее совсем отсекать такой вариант мне кажется не стоит
YL
Как раз возможно форк домена станет проверкой на то что мы изолировали часть приложения успешно
🚀🚀
поэтому я долго не мог понять, откуда в принципе в приложении столько юнитов мимо кассы
🚀🚀
проверка будет в рантайме, причём только во время использования нужной части, а это довольно плохой способ
IK
У нас один сервис, который рендерит много независимых виджетов. На клиенте они работают все вместе.
🚀🚀
да, это server-first подход
🚀🚀
serverless это когда у тебя каждый виджет это отдельный «сервер»
🚀🚀
а то, что у тебя сейчас в виде сервиса — будет лишь делать запросы к виджетам, то есть делегирует все свои обязанности
IK
Мы пока еще недостаточно просветленные для такого. =В
🚀🚀
это на практике гораздо проще, чем звучит)
🚀🚀
у меня одних только личных лямбд штук 50, я их просто не считаю, потому что такой подход гарантирует, что счёт будет выставлен лишь за используемые ресурсы
IK
Есть много нюансов 🤷
🚀🚀
та я понимаю
🚀🚀
я просто говорю, есть такая штука, называется serverless computing, и она делает жизнь фронтендеров заметно проще)
IK
🚀🚀
я пожалуй попробую вынести репу с бэкендом эффектора в паблик, там прям чистый serverless, можно как референс использовать)
dynamodb, lambda, s3, cloudfront и appsync для graphql api в качестве клея
а то я рассказываю, а наглядного примера нет
dynamodb, lambda, s3, cloudfront и appsync для graphql api в качестве клея
а то я рассказываю, а наглядного примера нет