Миграция приложения expressjs на сервер - проблема с express

Question

У нас реализовано типичное приложение express (в основном это API для отдыха, но также есть некоторые другие c логики, такие как passport- js входящие потоки и управление сессиями). Теперь перенесите его на сервер без AWS Lambdas. Исходное приложение express использует пакет express -session для хранения информации о сеансе с postgres в качестве хранилища. Приложение развернуто на AWS сейчас - первый запрос работает, затем второй запрос завершается с ошибкой внутреннего сервера. Нам трудно понять, почему. Это не тайм-аут. Мы попытались настроить express -сессию с postgres, DynamoDB и в памяти - и все равно не смогли заставить его работать. Почему это так? Какое решение рекомендуется для управления сеансами, когда речь идет о приложении без сервера?

Answer 1

Одним из решений является использование токена JSON. Сеанс хранится непосредственно на стороне клиента.

Теоретически при первом подключении вы устанавливаете токен для сеанса и отправляете его клиенту.

Каждый раз, когда пользователь вызывает Api, вы отправляете JSON токен. На стороне сервера вы заполняете его необходимыми данными (это объект) ... и отправляете его снова клиенту ...

Существует много способов реализации этого процесса, и с помощью JWT :

https://serverless.com/blog/strategies-implementing-user-authentication-serverless-applications/ https://ponyfoo.com/articles/json-web-tokens-vs-session-cookies ....

---

По мнению Amazon, лучшим подходом к управлению сессией является установите его в третьей стороне, как вы пытались, как вы сказали ...

https://aws.amazon.com/fr/blogs/compute/going-serverless-migrating-an-express-application-to-amazon-api-gateway-and-aws-lambda/

Извлечение:

* Storing local state is unreliable due to automatic scaling. Consider going stateless (using REST),
* or use an external state store (for MongoDB, you can use the connect-mongo package)
app.use(session({ secret: process.env.SESSION_SECRET }))
*/

Удалено состояние сеанса для масштабируемости (в качестве альтернативы вы можете сохранить состояние сеанса в MongoDB, используя connect-mon go.

Так что, как говорится в лучших практиках Amazon, вы должны попытаться реализовать его через mon go.

Это рекомендуемый подход, так как он исходит от Amazon напрямую ...

Answer 2

Управление сеансами принципиально отличается в среде без состояния и без сервера.

Поскольку вы не поделились кодом, который генерирует ошибки, я могу говорить только в общих чертах. Общий подход заключается в том, чтобы хранить любую информацию о состоянии в вашей базе данных и опрашивать базу данных, когда операция должна знать это состояние. Кроме того, вы можете использовать прослушиватель в этом узле базы данных, чтобы обнаружить изменения и распространить их на внешний интерфейс.

Чтобы устранить вашу ошибку - опять-таки гипотетически, поскольку нет кода для go off - если вы перенесли приложение Express в базу данных serverless +, и ваш первый запрос был выполнен успешно, но второй возможно, вы получили обещания обработки ошибок или где-то в асинхронном потоке между функцией и БД.

Я бы посмотрел на https://levelup.gitconnected.com/avoiding-the-pitfalls-of-async-node-js-functions-in-aws-lambda-941220582e7a и разместил несколько операторов console.log в различных точках до и после доступа к базе данных, чтобы увидеть, получаете ли вы ожидаемые фактические данные или пока нерешенное обещание. Удачи!