[glckr]

Conceptually I would say I'm a fan of these sorts of ideas (serverless, and queues in particular). Forcing you to look at the system as a chain of processes operating on data can really bring architectural problems into line.

However, 99% of the work that I've done involves users hitting buttons and us responding to them synchronously. In these scenarios, I simply can't figure out how queues (and chains of serverless functions as advocated by this blog) are supposed to work (if they are at all). There seem to be many ways to solve this when the queues are all flowing freely, but as soon as there's any sort of pressure on the system these things all look to fall down.

Looking at the amazon booking flow as an example -- it appears that they always show a "your order has been placed" page with a big green banner synchronously at the end of the cart flow. Some time later the user may then receive an email saying their payment method was declined. This certainly works, but a) it's horrible UX and b) it only works at the final stage of the process.

I see queues (and serverless) advocated as good architectural decisions, but every time they come up in a lecture/blog they're given in toy or data-sciency sort of examples. Is it possible to use these patterns in a sensible way where users are actually involved? (the blog mentions CQRS, but that seems... not a perfect solution)

[suzzer99]

Same concerns here. I've read so much theory on event-based architecture and CQRS, but the examples are rarely applied to user-facing web-app scenarios. Back-end technology should never dictate UX imo.

We're building a user-facing app from scratch - the plan is to start with big coarse grained services, and just use REST for service to service communication when a user is waiting on the line.

But of course favor breaking up the services so there's no communication required is the first preference, and queue-based where it makes sense is the second preference.

[k__]

I heard people were switching API-Gateway out with AppSync (the GraphQL alternative), which allowed them to remove a huge amount of HTTP-bound Lambdas and simply let AppSync manage that part of the stack.

[e1g]

AppSync is more of a wrapper around GraphQL rather than an alternative (including being based on the most popular GraphQL client, Apollo)

[k__]

Oh, I meant it was a GraphQL based alternative to use API-GW backed by Lambdas.