Apigee as state engine : Pros and Cons

[santosh_ghalsas]

Hi,

We are trying to analyse use of Apigee as a state engine given that Apigee has capabilities to cache the data. For example,

1. If I have been trying to shop something online and have added few items in my basket. I don't complete the order and leave my mobile app/web app just like that for say an hour or two for some work. I come back later and want to continue shopping then I should see those items in my basket when I resume. Apigee should store the basket details for me and give them back once I login back/start app again.

2. If I am trying to book an appointment with some doctor and I get few available slots at that moment. But due to some other work I forget to book appointment and go out for some work. I come on the app/site after some time and try to see where I was. Here I should see the list that I got in my last session again.

In both the cases there might be a possibility that previously selected items might have gone out of stock or the appointments for the stored dates might have got full but this enables users to resume from the stage where they had left.

I wanted to check if Apigee is a good platform to act as a state engine in such cases and the possible pros and cons of doing this. It is a bit different than HATEOAS where in APIs can be used to drive user to transition from one state to other.

Really appreciate any pointers around this.

Thanks,

Santosh

[santosh_ghalsas]

@Anil Sagar,@Brian Mulloy

Can you please help here.

Thanks,

Santosh

[santosh_ghalsas]

@Prashanth K S

Please let me know if you have any pointers here.

Thanks,

Santosh

[ksprashu · Accepted solution]

Hi @santosh_ghalsasi, short answer - I wouldn't use nor recommend Apigee Edge to do this and especially not with cache.

Your use case is leaning in the right direction, however. It doesn't matter if the items are out of stock or appointments are full. That is not the problem.

The problem lies in the design of using a cache to introduce state or persistency and that is not a good practice and not reliable. Assume that in the meantime a lot of requests are being cached, then the system will rotate space and delete old cached entries and this will be flushed out. Sometimes it may be there, sometimes it may not, and this is an inconsistent user experience that should be avoided.

If you do want to build such a capability into the API layer, then you should use a persistency like BaaS, Firebase etc. Actually shopping cart is persistency on the backend, but I get your point.

Keep in mind, whenever you cache data, you should be able to retrieve that data from somewhere if it did not exist in cache. If the cache weren't there, it is ok for performance to be impacted, but functionality shouldn't not change depending on a cache hit or miss - even if that is not apparent to the end user.

Hope this was useful. 🙂

[santosh_ghalsas]

Hi @Prashanth K S ,

Thank you for the inputs. Indeed it was useful. I need some more clarity on the point of old caching entries being deleted by the system to rotate the space. I guess you are mentioning this for the L1 cache and not the L2. Before deleting the cached data from L1, system will make sure that it is being pushed to L2, right? I agree to the point that L2 will still be shared by other resources of edge and there will be an ultimate limit for usage of cassandra by cache component. But we are not losing this data before the expiry time set for it.

BaaS is a good option to store the current state but it asks to do more in terms of creating proxies/calls that will help push data to Baas, retrieve it later when needed and make provision of deleting those entries after the time interval set for persistence. In short duplicating the cache functionality using BaaS.

And one more point that should be considered is we are using API layer to support stateful functionality although the purpose of this layer is to help for being more and more stateless. 🙂

Regards,

Santosh

[ksprashu]

My bad @santosh_ghalsasi, I was talking about rotating cache entries only wrt L1. Yes, L2 will persist it of course. I was not talking about duplicating cache functionality using BaaS, but BaaS serving as a persistence for this functionality in case of a cache miss (for whatever reason). The assumption being that the actual backend / service does not have this functionality and hence we are trying to do it on the API.

About APIs supporting stateful functionality - RESTful APIs are meant to be stateless. Any way to build state into them goes against the philosophy of REST. But nothing stops you from going and recognizing state in the APIs. I would just recommend not to expect the platform to guarantee this capability - if it works, it works, thanks to the magic that the developer put in. 🙂

[santosh_ghalsas]

Hi @Prashanth K S ,

Thank you for the clarification. I guess I have got a decent clarity on this as of now. Will get back if I have any more doubts.

Best,

Santosh