есть бекенд на Postgres, и надо как то данные хранить в приложении например сообщения и задачи, что лучше использовать в качестве хранилища? А ещё иногда передавать файлы до 100 мегабайт и связь может теряться , но это второй кейс ))
какая (в целом) разница, какая база на бэкенде? приложение всё равно туда не смотрит ) публично в любом случае доступны только api, а уже то каким образом ваш rest / graphql / grpc / ... на nodejs / python / php / ... будет в какую базу складывать данные - абсолютно не критично для приложения (и не тема этого чата, в общем-то). так что рекомендую по @it_chats посмотреть, какие детали в вашем конструкторе могут понадобиться, и куда более предметно вопросы задавать по каждому из них и в целом по архитектуре ну а по загрузке больших файлов - в направлении nginx решения смотреть. но это тоже тема для обсуждения за пределами этого чата
хорошо, с бекендом понял суть. Если идем даже через rest, то как лучше хранить данные в приложении на реакте? сообщения и задачи, текстовые данные. Явно не в AsyncStorage, соответственно в приложении будет своя локальная копия(типо кеша).
посмотрите мб в стороку aws amplify datastore https://docs.amplify.aws/lib/datastore/getting-started/q/platform/js#datastore-with-amplify
посмотрел, это аналог облачного решения через firebase как понимаю только от Amazon? спасибо, интересно, почитаю)
да, именно, там и загрузка файлов есть, но уже не datastore, а другой модуль
нубский вопрос, а как потом данные попадут в мою базу postgres или это решение подразумевает только хранение в Амазоне?
ну тут уже не тема рн)
по ответу понял, что это возможно, этого достаточно)спасибо)
а там скорее всего окольными путями, через какой-нибудь aws rds, т.е. данные в облаках будут https://stackoverflow.com/a/55510664 у mongo с realm такой же принцип. всё в облаке, синхронизацию со своим бэком прикручивайте сбоку, вот вам примерно подходящий api
хмм немного сложнова-то на первый взгляд) а по аутентификации подскажете?)
jwt чаще всего, в том числе для web-фронта. но там есть нюансы по реализации (где хранить токен в вебе, чтобы его не увели). я искал универсальный вариант, и кажется на базе вот этой статьи от hasura https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/ можно собрать cookie-based jwt с access и refresh токенами, и это будет достаточно стабильно. но еще не проверял. плюс вопрос - какие баги могут всплыть при таком решении, связанные с теми issue по cookie-based auth. ну а если обычным путём - отдельный роут в api, который вернёт jwt для заданного логина / пароля, и хранить этот токен локально, в headers запроса отправлять.
спасибо за развернутый ответ) класс👍
Обсуждают сегодня