Буду сильно рад, если этот БП поможет, впереди еще различные оптимизации для производительной работы стека, так или иначе, можно просто вырвать из БП все, что касается инфраструктурного подъема и наложить на свой апп.
Текущее ограничение - это как минимум GitHub Actions (не все пользуются гитхабом), плюс необходимость своего VPS и домена (эти ограничения я не смогу снять (в этом не было цели, как и в гитхабе на данный момент))
Из будущих улучшений - это вопросы нагрузки при рендерах страниц, больше дашбордов в графану по метрикам ошибок из логов (пока что), так же борд для контейнера с монгой, в случае его использования в рамках своей инфраструктуры (Для кластера монги внешнего чаще всего есть уже готовые борды в том месте, где монго кластер Вы уже сами будете брать))
Так же этот инфраструктурный стек можно посадить и для Nest приложения, где так же необязтаельно использовать монгу - но для другой базы данных потребуется переписать некоторые конфиги :)
Поздно наткнулся на статью 😂 спасибо, было интересно ознакомиться с кейсами
У меня была похожая проблема, но опыта на ее решение было недостаточно) уже года 3-4 прошло) За неделю тогда решал проблема с нестжс, путем разбитие на разные модули и их запуск в разных контейнерах) там уже постепенно подрубал мониторинги через графану и так далее. По бд был Firestore и классические проблемы N+1 и тд) проект уже старый, пока работает 🦫
Все так, самоцель была сделать именно в Firebase стеке, хорошей альтернативной выступает Supabase в том числе, просто с Firebase привык работать, еще с 2020 :D
Часто бывает так, что на фронте принят camelCase, на бэке snake_case. В частности, в таких случаях используют преобразователи названий свойств. Не составит труда в таком кейсе юзать какие нибудь готовые преобразователи из lodash. Перед отправкой данных из запроса в компонент фронта и обратно. Кейс с удобным названием fName вместо firstName, который вместо first_name действительно лучше избегать вовсе
Сам не использовал, поэтому подробности не знаю. Библиотека действительно весьма производительная, для большинства задач более чем подходит. Однако, насколько мне известно, документация React не рекомендует использовать не управляемые компоненты https://ru.reactjs.org/docs/uncontrolled-components.html
Спасибо за статью. Вопросы перечисленные здесь и ответы на них весьма общие и ничего не раскрывают о соискателей, чтобы что-то понять о человеке и его опыте нужно задать еще столько же более глубоких вопросов и приправить это все добротным слоем онлайн кодинга. А то знание этого списка, даже на джуна не особо дотягивает.
Буду сильно рад, если этот БП поможет, впереди еще различные оптимизации для производительной работы стека, так или иначе, можно просто вырвать из БП все, что касается инфраструктурного подъема и наложить на свой апп.
Текущее ограничение - это как минимум GitHub Actions (не все пользуются гитхабом), плюс необходимость своего VPS и домена (эти ограничения я не смогу снять (в этом не было цели, как и в гитхабе на данный момент))
Из будущих улучшений - это вопросы нагрузки при рендерах страниц, больше дашбордов в графану по метрикам ошибок из логов (пока что), так же борд для контейнера с монгой, в случае его использования в рамках своей инфраструктуры (Для кластера монги внешнего чаще всего есть уже готовые борды в том месте, где монго кластер Вы уже сами будете брать))
Так же этот инфраструктурный стек можно посадить и для Nest приложения, где так же необязтаельно использовать монгу - но для другой базы данных потребуется переписать некоторые конфиги :)
Поздно наткнулся на статью 😂 спасибо, было интересно ознакомиться с кейсами
У меня была похожая проблема, но опыта на ее решение было недостаточно) уже года 3-4 прошло) За неделю тогда решал проблема с нестжс, путем разбитие на разные модули и их запуск в разных контейнерах) там уже постепенно подрубал мониторинги через графану и так далее. По бд был Firestore и классические проблемы N+1 и тд) проект уже старый, пока работает 🦫
Все так, самоцель была сделать именно в Firebase стеке, хорошей альтернативной выступает Supabase в том числе, просто с Firebase привык работать, еще с 2020 :D
Вишлист бот с мини аппой и открытым исходным кодом
https://t.me/personal_wish_list_bot
https://github.com/Fedorrychkov/personal-wish-list-bot api
https://github.com/Fedorrychkov/personal-wish-mini-tg-app - app
Еще делал недавно впн бота с конфигами для vless/reality (пока только бот)
https://t.me/GuardianConnectVPN_bot
https://github.com/Fedorrychkov/Fedorrychkov - другие пет проекты и пару статей
Часто бывает так, что на фронте принят camelCase, на бэке snake_case. В частности, в таких случаях используют преобразователи названий свойств. Не составит труда в таком кейсе юзать какие нибудь готовые преобразователи из lodash. Перед отправкой данных из запроса в компонент фронта и обратно. Кейс с удобным названием fName вместо firstName, который вместо first_name действительно лучше избегать вовсе
Пользуюсь подобным в библиотеке rixio, линзы это очень полезная и крутая штука
Интересно, спасибо!
Неограниченное место на диске немного удивляет. Интересно, что будет с этим показателем дальше
Сам не использовал, поэтому подробности не знаю. Библиотека действительно весьма производительная, для большинства задач более чем подходит. Однако, насколько мне известно, документация React не рекомендует использовать не управляемые компоненты https://ru.reactjs.org/docs/uncontrolled-components.html
Спасибо за комментарий, я слышал об этой либе
https://rjsf-team.github.io/react-jsonschema-form/ вроде весьма популярная и возможно удобная)
Спасибо за статью. Вопросы перечисленные здесь и ответы на них весьма общие и ничего не раскрывают о соискателей, чтобы что-то понять о человеке и его опыте нужно задать еще столько же более глубоких вопросов и приправить это все добротным слоем онлайн кодинга. А то знание этого списка, даже на джуна не особо дотягивает.