how to maintain a session if required between edge and backend system.

Not applicable

Is there a way to manage a session between apigee edge and back end system between multiple request which goes through apigee edge platform to backend.

Solved Solved
3 4 1,332
1 ACCEPTED SOLUTION

Not applicable

Will add to what @sudheendra suggests.

Yes. Keep it stateless, as much as possible. If you can't, I suggest a few options:

  • Leverage JWT claims to store non-sensitive data. That way you can pass the token id around to third-party systems and remove the dependency on a server.
  • Maintain state on the server-side.
    • By associating attributes to access token. OAuth policy supports this feature.
    • Keep state on the server with KVMs or cache leveraging cookies. Not a big fan of this one, but I've been on projects where this was required.
  • Maintain sessions on the client side.
    • Leverage browser local storage. I'm an advocate of this one for many use cases.By using client-side sessions, your backend can scale as it won't have to keep track of any state. A cluster of thousands of microservices can receive your requests without the need of tracking sessions on the server side. And the best part is that it can be secure. Take a look at Using secure client-side sessions to build simple and scalable Node.JS applications to learn more.

Let us know your thoughts!

View solution in original post

4 REPLIES 4

By default the API proxies you create in Apigee Edge are stateless. So they don't maintain any state by design. But you could use Cache or Key-Value-Map (KVM) policies to maintain state. You could also leverage API BaaS (datastore) to store the session information across multiple requests.

Hi @Sudhee Sreedhara, @Diego Zuluaga I was wondering about this question too. It's there a performance benchmark between apigee KVM vs Redis or another inMemory tool ?

How can i do this. any examples or reference links
there multiple incoming requests into my apigeeproxy
firstime - a req.id comes - i need to store in somewhere
next time another req comes with same req.id - then i need to route it same load balancer target, which it is going to first.

Not applicable

Will add to what @sudheendra suggests.

Yes. Keep it stateless, as much as possible. If you can't, I suggest a few options:

  • Leverage JWT claims to store non-sensitive data. That way you can pass the token id around to third-party systems and remove the dependency on a server.
  • Maintain state on the server-side.
    • By associating attributes to access token. OAuth policy supports this feature.
    • Keep state on the server with KVMs or cache leveraging cookies. Not a big fan of this one, but I've been on projects where this was required.
  • Maintain sessions on the client side.
    • Leverage browser local storage. I'm an advocate of this one for many use cases.By using client-side sessions, your backend can scale as it won't have to keep track of any state. A cluster of thousands of microservices can receive your requests without the need of tracking sessions on the server side. And the best part is that it can be secure. Take a look at Using secure client-side sessions to build simple and scalable Node.JS applications to learn more.

Let us know your thoughts!