This document discusses building stateful applications on serverless platforms and provides several patterns for managing state in a serverless environment. The key patterns discussed are: 1) Sending the full context in event payloads to avoid database reads, 2) Using backend-as-a-service providers to manage stateful services like identity, media, and notifications, 3) Running long-running "state planes" to manage state, 4) Building workflows using state machine patterns, and 5) Using fast databases to directly manage state without delegating it. The document emphasizes that real applications always have state and the challenge is effectively delegating state when building on serverless platforms. It also discusses related topics like ensuring idempotency and implementing patterns

1. Building stateful real
apps on serverless

2. I’m Tiru
Hasura is :
- GraphQL on Postgres
- Serverless business logic
- Postgres as event source
I do:
- Product development
- Product management
- Developer advocacy
https://hasura.io
@Tirumarai

3. A real app always has
STATE!
Otherwise.
It is only.
Heating the place up!
# global warming

4. Examples of few simple apps
1. Get an image as input, resize and store it somewhere. That’s state.
2. Register a user, and create a list of Todo items
That’s definitely state.
3. Given a city, retrieve the current weather.
Ah! No state?
@Tirumarai

5. Given a city, retrieve the current weather
There is no state, only if
you are NOT Yahoo
Weather
What we have done is
delegated state to a
black-box
Real apps have state! All we can do is delegate, delegate and delegate.

6. Patterns for delegating state
1) Send full context in event payload
2) Use BaaS aka managed services
3) Run long running “state planes”
4) Build workflows using state machine pattern
5) EASIEST: Don’t delegate state (w00t!)

7. Pattern #1: Send context with event
Event #1
{ "id": “42” }
Event #2
"user_info": {
"user-id": "1"
},
"op": "UPDATE",
"data": {
"old":{
"id":"42",
"name": "jane"
},
"new": {
"id":"42",
"name": "john doe"
}
}
Obviate the need
for database read
❌ ✅

8. Example #1: Send context with event
"user_info": {
"user-id": "1",
"name": "Jane",
"address": "Ch. S",
},
"login": "Facebook",
"created": "14-02-19"
"utm": {
"source": "twit",
"campaign": "ad"
} @Tirumarai

9. Pattern #2: Use BaaS/managed services
Let someone else deal with state
Identity: Auth0
Media tools: Cloudinary
Search: Algolia
Notifications: Twilio
E.g.
@Tirumarai

10. Example #2: Use BaaS/managed services

11. Pattern #3: Run long running “state planes”
@Tirumarai

12. Example #3: Run long running “state planes”
Running a
GraphQL
service on
serverless
https://medium.com/open-graphql/
scaling-rdbms-for-graphql-backend
s-on-serverless-980ef24af171

13. Pattern #4 : Build workflows using
state-machine pattern
@Tirumarai

14. Pattern #4 : Build workflows using
state-machine pattern

15. Pattern #5 : Use fast databases (EASY)
@Tirumarai

16. Pattern #5 : Use fast databases (EASY)
@Tirumarai

17. What is stateless then?

18. Stateless == Idempotency?
What people usually mean by stateless is idempotency
Stateless => Idempotency, Idempotency => More than stateless
If we can ensure idempotency, our stateful function seems like
a stateless function!
Managed services should be idempotent for use with serverless

19. Caveats

20. Good enough, but not everything

21. Demo time :)

22. The 3factor app

23. The 3factor app

24. What’s the catch? Transactions!

25. Let’s talk about Haskell :)

26. How to get started?

27. Incremental adoption for brownfield projects

28. An example: Before and After

29. Hasura Event Triggers

30. Thank you!
Tirumarai Selvan
@Tirumarai
hasura.io
github.com/hasura/graphql-engine

31. Questions?