Implement real-time event patterns with WebSockets and AWS AppSync

Well, good morning or good afternoon rather everybody. I am uh Ryan Yanchuleff, I'm with AWS here and uh you are at FWM 204. We will be talking about implementing real time event patterns with WebSockets and AWS AppSync this afternoon.

I am joined on stage uh this afternoon by my colleague, Bill Fine. He is the senior manager in charge of product management for AWS AppSync and I'm also joined on stage by David Provan uh the principal IT architect for the PGA Tour.

As I mentioned, I am Ryan Yarl. I'm one of our senior specialist solutions architects with the Next Generation Developer Experience team here at AWS, which means I get to work with the team that is kind of reimagining how we do developer experience here at AWS.

Uh as I mentioned, we'll be talking about AWS AppSync today. Uh I'll be walking you through the uh a little bit of an overview of what AppSync is all about. Uh what the service covers and uh what different types of things you can do with it as a customer and what some of our customers are doing with it.

We'll look at a demo uh of the application, you'll get a chance to, uh to participate with that in a real time kind of interactive way. Uh in, in the, in the namesake of being a real time uh event service.

Uh and then I'll talk about some of the real time event patterns that customers are using, uh how they're building it out. And what are the, some of the use cases that we're seeing uh as they're starting to leverage that in their own applications?

I'll hand it over to uh to David to talk to you a little bit about what the PGA Tour has done uh with the real time uh event handling and some of the success they're seeing in this past year by implementing that at the tour.

And then finally Bill Fine will wrap this up talking about some of the, some of the use cases that some of the new features that we've released for AppSync this year are, are being used for and what you can do with them.

So with that, this is a live interactive session, we are using live polling in this, in this session. So if you want to grab, grab your phone out and, and take a picture of the, of the QR code here, there's a couple of different questions or there's rather one question that you, you'll be asked what we're interested in here is how many of you are actually using AppSync in a real-time scenario today in your production workloads, are you using AppSync or are you using another type of solution that might be that that's commonly used in that space?

So take a moment, scan the QR code and go ahead and answer the question and then uh we'll give it about a minute or so here and then I'll ask the uh the, the tech team here to cut over to the uh to the, the results and we'll take a look at that.

Um tech team. I, I apologize, the lights are pretty bright so I can't, can't see you in the background. Uh but uh give it a minute here and then we'll, we'll cut to the uh to the revenue or the results rather the results side.

Um so go ahead and do that while, while we're waiting for that. Uh by show of hands, how many of you in the audience have actually used AppSync at all or, or familiar with AppSync? Uh even even if it's not a real time uh workload.

So a couple of hands in the audience uh that that's good to good to see. Uh so uh team if you want to cut over to the results, if that's uh if that's working.

So uh we see a pretty good breakdown here of a couple of different solutions. Uh we've got folks that are using uh AppSync GraphQL subscriptions about 12% of you and then about three quarters each are using client side polling uh or self managed web sockets or another solution.

So that's a good thing to know as uh as we're starting to dive in to the talk that we're doing today. And so we'll try to give those folks that are using uh a non AppSync solution. Uh a good reason to, to make that switch.

So team if you want to cut us back over to the uh to the main slides, appreciate that.

So what is AppSync and, and what is it all about?

AppSync is a 100% self managed or rather managed service that we offer here at, at AWS, it's 100% serverless. So there's no fixed costs and you only pay for what you're using as you're, as you're leveraging that.

It has a number of different built-in JavaScript and VTL resolver that integrate with a number of different data sources behind the scenes to allow you to provide a single unified schema to your customers that blends a number of different resources, data sources or lambda services behind the scenes to fulfill those requests.

It is fully secure and fully performant. It integrates with services like CloudWatch and X-Ray to give you observability and debug abilities and it is, it leverages all of the modern security protocols and has integrated integration with WAF and CloudTrail to allow you to be able to restrict and control who's using your service and what changes they are making to them.

So one of the most common use cases for AppSync is GraphQL APIs. So GraphQL was introduced in 2015 as kind of an alternative to the REST protocol. And it's really designed to allow your your client developers to have more flexibility on what payloads they're seeing on the client side.

And for you as a as a backend developer to obfuscate the complexity of your backend data sources from those front-end clients, you're providing a single unified schema to those clients and then you're fulfilling those requests backend sources.

It also provides several different real-time capabilities and that's a big part of what we're going to talk about today.

So as an example in that single single GraphQL schema, you can compile your results from a number of different data sources. You can do that either for individual requests or you can do that for a single request and blend the data together.

So you can see here this particular request is bringing data in from a DynamoDB table. It's bringing data in from a REST service available on API Gateway. It's blending data from an uh a Lambda inventory and from uh RDS uh data sources.

So from the client side, all I care about is that I'm making a request here for a profile in order data. I don't really care where that data is coming from or how it's being fulfilled.

And then my backend team is responsible for compiling that data and I can make changes to that to that compilation request. As long as I don't change the schema, my client side team never needs to know the difference.

The other reason that you might want to use AppSync is for doing pub sub or real time use cases.

Um so a pub sub API is still leveraging GraphQL. It's using the subscription capability that GraphQL offers and it's allowing you to perform real time capabilities by delivering those out to your customer.

So as a customer, I can subscribe to different mutations that are happening in my data model and I can receive those updates as they're coming through. I don't have to leverage all of the other pieces of GraphQL. I can just use a subscription piece and that's actually what we're going to see in the demo today. So you get a chance to see how that, how that's built out.

So what that looks like here is that I have a number of different backend data sources that are publishing updates through my API. That could be a DynamoDB update that's making a change to a table. It could be an EventBridge source that's pushing a real-time update or it could be a Lambda function or another RDS data service and all the different clients that are listening to that subscription are going to receive that update as it's happening.

So let's look at this now in a real-time example. And you're going to have a chance here to interact with this and see how it works.

So what are we going to view? We're going to see an application here in two parts. You're going to get a chance to play with the real-time client that's going to give you the ability to push emojis up to the screen on here.

And what I'm going to show you on the screen here is the display client that's actually going to listen for those subscriptions and display them for you here on the screen. It's going to scale automatically for you because AppSync is, is a real time scaled service.

So that means there's no additional work that I need to do by running AppSync to be able to scale that out. It's automatically going to load up as all of you start to leverage the system. And when all of you are done, it's going to scale back down to zero. And I'm not going to have to do any additional work to leverage that.

So with that, go ahead and take your phones out again and scan this QR code and I'm going to give you a minute for that because I'm not showing the QR code on the demo. So go ahead and scan that QR code here briefly.

And what you should see come up on your phones is a client with a number of different emojis that you can click and so as I do that, now, let me go ahead and, and, uh cut over here as you're pulling that up and, uh, and then let me go ahead and switch that over.

And so now as I'm listening to this here, um, go ahead and start clicking the buttons. And if we're, if everything is working correctly, what we should see is a bunch of emojis appear on the screen, so I will pull that out with my phone as well and I'm not seeing any emojis.

So either none of you are pushing the button or they're going nuts out there, they are going nuts. Ok? Um uh we, we broke it. Ok? There you go. There you go. All right. Now they're all coming through.

So there's all your emojis that are coming through. So what you're seeing now is uh AppSync is actually this client here is subscribing to the uh the channel that you all are pushing your emojis to and you can see it actually scrolling them up here through the screen.

So we've got it working here. And the nice thing about this is you can see on the screen here. The publisher code, which is what you guys are using, has about five lines of code in it that you're using on the client side to push those notifications through the client side code or the, the, the display code, which is what you're seeing on the screen here has about 10 lines of code that are listening to those updates as they're coming through.

And so uh with a, with a just a handful of co of lines of code here, we're able to demonstrate in real time how a real time uh update would work.

And so with that, let me go ahead and, and cut back over. Thank you for uh for being interactive participants there.

Um and so the question is how, how complicated was that to actually build? Surely that requires a lot of different pieces and parts as you can see from the architecture demo here or the arch architecture diagram. This is a very simple architecture. It has one piece that goes into it. AWS AppSync is the only piece involved in this entire architecture.

So on the audience side, which is the client application that you're seeing that's pushing the updates to AppSync and then the demo screen that we're seeing on my laptop displaying out to the screen here is listening to those updates from AppSync.

So the question is if it's really that simple, then surely there must be some trade off. Well, it's very easy to build. And what we're actually gonna see here is how we would go ahead and build that.

So in this demo video here, which we're gonna take a minute and watch. Uh you can see what's actually involved. This is building it out through the AWS console. Uh you can also use AWS CDK or other types of infrastructure as code components to build it out as well.

Uh but what we're going to do here is actually build out our, our API in the console. We're going to um choose the basic settings and then we're going to create a simple uh pub sub API by checking the check box there.

Once we've done that, we're gonna go ahead and create the application and it's gonna build for us a very simple schema that has things like a published channel and some mutations to allow us to make changes to that published channel and then a subscription that our, our display client can listen to.

So it's going to expose here an, an api a n. We're going to get this very simple graph ql schema here with a channel that manages our updates. There's going to be a mutation there for publishing. It's going to push those updates out to, to our api. And then we're going to have this subscribed subscription here which our display application is listening to, which is going to receive those updates and publish them through.

And this is all done now through the, through the aws console. And so now you can see here in the query editor in the console, we're using the api key, we're going to publish that data and then we're going to listen to that data. So here it's uh it's, it's listening to it and then we can cut over and, and publish it in a different window here and we can see that update be pushed through.

So i'm gonna, i'm gonna publish it to uh to a channel here with a hello message. I'm gonna publish that data. It's going to go through here. And then when i cut over to the query editor and the other screen, i can see it show up there on the other side. So that's a really brief example of what that looks like.

But it's important to understand here that just because this is a very simple architecture, appsync is not a simplistic service. There are a lot of different powerful things that you can do with appsync. It provides connection management for all of our active subscriptions. So the, the java or the, the javascript client side client is managing our connection activity. It's keeping those connections open, it's handling the authentication and any filtering that we're doing and it's publishing those clients out.

The broadcasting mechanism allows us to update those clients with any changes that are happening in real time. The fan out capability allows us to push those, those updates to millions of customers in in a single update without again having to do any further scalability. Because again, absint s serverless capability here is allowing us to do the scale up and scale down automatically without having to make any adjustments on our side.

That means we don't need any auto scaling. We don't need any two cluster or anything like that. Abst is going to handle that for us automatically. And when we're done, this is the important part, it's going to scale it back down. So there's no additional cost that we're paying when it's not being used.

And dave is going to talk a little bit about that when he talks about the, the tor and how they implemented that as well. We also have a number of different metrics that you can look for. I mentioned earlier that we have integrations with cloudwatch and x ray. Uh so you can track what updates are going out. You can see your overall usability, u usage and usability and you can use x ray to do debugging.

So as i as i mentioned, you can pull your data requests from a number of different data services to fulfill those requests. But it's important to understand if you have bottlenecks. So is one of those particular requests really slow, is one of those requests failing and causing a problem for your responses. Metrics in in absynth are really powerful in giving the the ability to debug that capability.

So we also have integrations with security. So absent supports a multi, a multi strategy which means i can do authentication, not just against a single a p a single security strategy, i can also do it against multiple security strategies. So in the example that we saw earlier, we were using api keys to do our authentication. So that was just a simple api key that you had on your client that i had on my display client that we were using to authenticate.

But i could use amazon cognito user pools and i could have, you could have you log in and, and do authentication. That way i could use a third party o ic provider. So octa secure or a zero, something like that to do my authentication, i can also use, i am, this is really powerful in in doing service to service type calls with i a or with, with, with a and then i can use lambda.

So if i'm going to do a really complex custom authentication strategy, i can invoke a lambda function and have it do my authentication strategy that way and return either an accepted or or uh uh a non athen authenticated response. So ab sin is really powerful in that sense, i can do authentication strategies against individual operations like mutations and queries.

I can do it at the type level. So i can say you can see access to this particular model but not this other model and i can do it at the field level. So i can say you can see access to my my user profile but not to the social security number. You have to be a different authentication class field to get that type of of access.

So the the emoji thrower that we, we looked at, i've actually published that for you in a github repository. So if you're interested in seeing the source code for that, you can use the qr code on the screen here and take a look at that at your leisure. The source code for both the client side display that you, you all were using on your phones as well as the, the display side that you saw on the screen here are included in that repository.

There's also a code in there for cdk to see how you can deploy the backend absent api using infrastructure is code. So give that a look and review that when you, when you have a chance and you'll be able to explore that in a little bit more depth.

So real-world real-time use cases. So we've looked at some really simple examples on the screen. Our, our emoji thrower was very interesting but we want to see what, what does that actually look like in a real in a real-world scenario. What are, what are customers doing with ab sync and how are they using that as they're building out scenarios in the real world?

So we've got a number of different scenarios here for what that looks like. Uh we have customers that are building out sports scores and statistics, uh uh different types of companies that want to push out updates. This is an example of what the, what the tour is doing uh with ayn we have companies that are using it for betting odds where customers are, are making bets on different activities that are occurring and they want the latest data to be able to know how to place those bets and, and what, which direction to make them on.

We see it in stock prices and portfolio values where i'm, i'm monitoring my portfolio and i want to know what are the, what are the latest stock prices and how are they changing in real time? And i want to have to refresh my screen every time that's happening.

We also see it in, in examples like inventory levels or fan voting, uh group chats, uh amazon music, one of the uh one of the large uh consumers uh or, or, or uh users of uh appsync is using it for their music playlist. Cues to allow you to see the updates in what people are using and what they're saving to their uh to their playlists.

So in the fan voting or, or location updates and schedule updates. So a number of those types of things as well. So let's look at one in particular example here, how do we do betting in real time? This is based on an actual customer that we're working with a large national or international sports betting company that is using this in their, in their real-world environments.

So they're publishing a number about 300 different betting markets on a single page. So as the customer is going and looking at the home page there, they're seeing 300 different objects that are all updating in real time. So how are they doing that? They're doing it with a single subscription and they're using a sync enhanced filtering to accomplish that.

So as they're on that page, the customer is passing in the betting markets that they're interested in knowing more about and we're doing that filtering on the server side. So as as the hundreds and hundreds and thousands of updates are coming through and being mutated on the server side, they're able to say, show me only the 300 that i care about and we can get even more advanced with that and we can say things like show me only the, the 20 that are in the viewport that i'm currently looking at.

I don't care about the ones that are above me on the screen and the ones below me on the screen. I just want to see the ones that are in the screen that i'm currently viewing. So we're able to do that with enhanced filtering and absent.

Another type of scenario is that they're publishing millions of customer views and they have, they have millions of customers that are looking at their website every month and they're looking at upwards of 300 different listings per page. So they want to see all of those updates that translates into billions of real time updates.

So how are we handling that sync again is a managed service. So it's doing that automatic scaling for us. We don't have to build out any, you know, autos sc groups ec two clusters, anything like that. Abs's automatically scaling to handle that load.

And if you're worried, apsick is more than capable of handling large-scale real-time updates. This particular customer again is publishing billions of updates every month. The tour is doing millions of updates as well. Amazon music is using it for millions of updates and absent is able to handle that load without any additional work on your side.

And then lastly, we want to be able to handle security. So we want to be able to make sure that a customers are only seeing the data that they care about or that they're allowed to see. And we also want to make sure that nobody else is blocking access to those data, data elements that might be getting in our way of our customer.

So appsync has things like waf integration which to protect against malicious actors that it might be doing things that we would prefer they not do or that would limit access to that application and those updates for our customers. We can allow us to provide things like ddos protection in the middle there.

We also have security that i talked about in the previous screen. So i can i can restrict access to these different data points from my customers.

So with that, that gives you a little bit of an overview of what amazon appsync is or what aws appsync is all about and some of the different features that you can do with it. We've looked at some different real-time real-time scenarios in which you can use appsync and what our customers are doing with it and then you got a chance to be hands on with it and see what that was all about.

So now let me hand it over to uh to david and he's going to talk to you a little bit about how the tour is using uh uh a sync in a real time way to handle their uh to their handle their latest mobile application. So that david, let me uh let me hand it over to you.

Cool. Thanks guys. So my name is uh david provan. I'm the principal architect on the digital and broadcast side with the pga tour. And about 2.5 years ago, i joined the tour from ibm. I worked about 20 years in sports, did a lot of that with ibm at the masters. Wimbledon us open other events and the pga tour said we're going to be a word, everything from scratch. Can you do that? And that was too fun of an opportunity to say no, to, to be honest to you, it's very rare you get told start from scratch doing about the old stuff and we did that

We evaluated everything that we had from a digital point of view and we rebuilt our website and mobile app from the ground up. And today, in fact, we found out we've won design awards for Apple mobile in platinum and gold standards for the stuff we launched through the year this year and last year.

Core to that is the understanding of what golf is. So aside from the four people, I know who know about golf in the room, how many folks are aware the PGA Tour is what we do week in week out. A few. Ok. The best description I've heard of the Pj Tour this week um is, it's a traveling circus. We have events every single week in different parts of the country. We pick up kit, we drop kit at that event and we run it soup to nuts. The whole thing, data collection through data delivery is done by the PGA Tour scoreboards on site machines to collect information at ridiculous volumes. We're now gathering 10 times that we used to gather on course.

And the challenge that my team has is how do we make that relevant to you? How do you make it fast to you? How do you make you care about what you're seeing and how do we give you something that you didn't know you necessarily needed to know or give you insight into sports even though you had, we wanted a real time fan experience, our previous stuff was all polling restful api s we had about a 2.5 minute latency from course to client, which isn't fast enough for us. We wanted much, much faster than that. And if you're not first in sports, you're last. So if you're not doing it first, you go to the other platform.

Um I get one day to get your attention. If it works on Thursday, you come back Friday, Saturday, Sunday. If it doesn't you go somewhere else and I've lost you for a week. I don't want to lose you. I need to stay with our platform. And then the other problem we had is we wanted feature velocity. Everything we were building was in a year long plan. We planned out at the year level across the whole schedule of the tour and we hit about 60% of those features on a good year. Everything we did was built by a vendor which means it with that vendor working on their schedule.

A big drive in the tour is we bought technical domain knowledge inside the tour in the last 12 months. I was technical hire. Number one in our department. We're now up to about 16. We still use vendor to kind of supplement build velocity. But technical domain knowledge is inside the tour, we know how our stuff works.

So our key products data as fast as we can physically get it from the course to whatever device you're looking on mobile phone, android app, mobile website website. We want to be first, not second everything we do. We will have real problems that our i os app, our android app and our web app were built by two vendors who did things different ways. So we would release a new feature and it would work on one platform and not the other platform that made everyone in the pga to very upset. Turns out when stuff doesn't work, people get angry about that.

So we wanted to move our logic and our decision tree into what we call our middleware. So our our clients and annoying to any front end developers are dumb rendering engines. They do what they are told to do by the middleware. So we get things like two cut lines which can happen in some golf events that would throw the world into a spin the middleware just injects two and you render two out because we told you to. So moving that logic in has made us build faster, which is the last point here.

We wanted a fan out messaging capability. We need the ability to deliver messages in real time to everyone as fast as we could. And what led us to appsync was essentially a review of different aws features. We look at api gateway which has web sockets, but we had to manage the connections. So api gate, we got to manage that connection, decide what happens. Appsync was like we take care of that for you at the scale with all the stuff that ryan mentioned with the security and delivery, that was one of the primary reasons we went.

The second reason we went was the um the graph your scheme and letting clients pick the day they wanted so we can deliver the mobile payload to the mobile device. The richard desktop device, we also move to event driven, architecture, sport, everything in sport is event driven. Someone does something that means something i want to see it.

So what you see on the diagram here is maybe a little bit more complicated than your diagram, ryan, sorry. But essentially we have ingest services which write things into dynamo db or redis cache or sometimes three bucket other services. Those events trigger mutations inside appsync that then push them to the client at real time speeds over web sockets.

The we were testing the new website with our product team. We have a big media lab inside the pga tour and we had eight product owners all on the line who said we're going to test scoring. We don't believe you that it will update. We've done this for 10 years. It never works. You lie, technical people like us all the time. And we lined up eight different mobile devices and websites and they sat there and we have a system on an internal tool called tracker two which we get real time updates. Of course. And we get things like ball in hole, player, ball is resting point. So we know where it is. And we watched that and they watched the device and they all at the same time, went, got it with a hand in the air and i was like, i'm done. I quit, i've achieved it. It worked.

But that's what we get. Now, we now get everyone's device regardless if you're on an iphone, an ipad, your device is all update at the same time that data consistency is really important to us. As you drive through our experience, the score should be the same. It shouldn't go back and forward. Like you sometimes get the polling kind of architects on top of that, we can now build at the scale we want to do. We don't have fans with hopefully bad experiences. Real world happens. Sometimes things come and catch us out. This would be less fun if that didn't happen. We want to give you the best experience we can all of the time. You shouldn't ever have a bad experience on pga tour platforms.

Finally, all this is managed with cd k infrastructure. The tour is part of a 10 year partnership with aws. We were all in on cd k, appsync and cd k have been two of the most fun things to work on on this project because work should be fun.

Cdk has really helped us kind of move at velocity and build at speed were entirely serve us. We used to pay for provision instances year round because everything ran on big fat ec2 with a em templates and it was very expensive. Um I was telling these guys, august was an expensive, more expensive month. A bs and october was cheap because they stopped playing golf. And if they did play golf, it was ryder cup and people less come to pj taught for that. So we pay for consumption, which is really, really good for us because we're not paying for what we need.

All this means we optimize, we can optimize what we need to target optimization. It also moves really quickly. We like to segment our code in functional little places. We can make strategic changes. We use cd k stacks, we can deploy during play. The tour. Never, we never deployed during play. We'd wait to the end of the day and we deployed it on the first day of rsm. Last year is when we released the mobile app with about 30 minutes. We realized there was a problem on the backup course in our side. The day collection side was perfect. But our side, we had a problem with backup course. We did a cd k update. Lambda was hop swap behind the scenes. Everyone's device updated and my boss sat there went, how did you do that? I was like, i don't know, it will cost you money salary and i will tell you how it works.

Um but that's what we can do. Now, we have these short windows, we have to fix things quick, we have to move quick, we have to release features quick to keep your attention. And i said cd k, we use co pipeline docker for the website and stuff, but pretty standard stuff

The biggest result for us is we are now faster than everyone else. My favorite story about this is I was going to Vancouver to meet with a vendor. There was a playoff at that time at one of the January events last year. And there's a guy with a PJ Tour mobile app and a guy watching ESPN in the lounge and the guy with the app says he sinks this and wins and the guy's like, it's not on ESPN yet. And that was just the most perfect moment for me because the guy watching ESPN was really upset but we'll beat the broadcast because they've got a satellite delay and stuff. But with, without delay, we will beat the broadcast. Sometimes we can update during play.

It used to be two week delivery cycles. We can update five times a day if we need to, we update when it's new. We don't wait for end of play. And our architectural approach really allows us to best utilize the operating environment. We have, we are able to release features at a velocity we've not seen before. We're now producing the VP a product to we, we're doing 300% more features than we did last year at a third of the development time at an improved quality just because we have this cyclic approach to getting things done.

So I can take questions of that at the end or outside whatever you want. But I've passed a bill to about the new features. I wanna thank you and very impressive what you and your team have done, David too. Thanks for joining us and thanks for sharing it with everybody here.

So I'm Bill, head of product for AWS AppSync. And I'm here to talk about a couple of things. Mostly I want to talk about how people are using AppSync in different implementation patterns that may be something that you can learn from.

So my favorite, I'll start that by you know, saying Ryan started by showing you a very simple application architecture and it is my very favorite AWS application architecture slide ever. I don't know if anybody's ever seen an AWS application architecture slide with one single service on it before. But but that's truly what, what the case was. But of course, then David spoiled it by by showing us something more complicated.

But I am going to dig into a couple more complex application architectures where people are using AppSync with different AWS services to accomplish different things. Before I do that, I want to highlight a couple of recent features that we've released that may be of interest.

So the first has to do with scale. Um we talked a little bit about scale and one of the things that people love the most about AppSync is that they can scale up to, you know, millions of messages that they're sending to connected clients. And then just as importantly, scale back down to zero. So, you know, the tour can scale up on Tuesdays, Fridays, Saturdays and Sundays and then back to zero or close to zero on Monday.

Uh, so scale is important to our customers. And so, you know, often we have customers that are dealing with high volume events like the Super Bowl or the Olympics or golf tournaments or your favorite virtual reality TV show, uh, voting these kinds of things.

My favorite story happened last week where I think of this is the, the, we, the, the story where Bill and the AppSync team save Thanksgiving. Um, but apparently there's a, there's a, a company out there that makes meat thermometers and these digital meat thermometers use real time, uh, events to distribute to the phone temperature of the turkey that you're cooking. And it turns out they sold a bunch more than they thought they were going to sell, ah, in the week leading up to Thanksgiving. And then we got a call that said, ah, we think we are going to need more, ah, and, ah, and more beyond their, their default quotas.

So we worked that out with them and, um, uh, everybody's turkey, I presume was cooked, uh, cooked correctly, or at least it wasn't the meat thermometer's fault. Um, but I tell that story because, you know, it's, you know, it's nice, you know, it, you know, we were able to help him out, but it was true. Truly. It was a hassle for everybody. They didn't want to be calling us. We didn't want them to be calling us the day before Thanksgiving.

Um you know, it was mea culpa on their part. They said, you know, we should have planned this in advance, but we worked it out. But the better answer is it just works. They don't need to worry about it.

So we are introducing higher default limits. So today, uh the default inbound message limit for AWS AppSync is 2000 messages per second. Uh we're increasing that default limit to 10,000 messages per second. And then on the outbound side, the message distribution side on broadcast and found out the default quota is a million messages per second. So that meets most of our customers' needs. It was well beyond what this particular company needed for. Uh for the for the Thanksgiving day, we do have certainly some customers that work with us to exceed that. So feel free to work with that.

Uh we've also as part of this introduced some new metrics, uh that allow our customers to more easily see what they're using. What, what their inbound message rate is, what their outbound message rate is. What their number of connected clients are. How many client, new clients per second are they adding to their subscription? So these kinds of things to help them manage that.

Ryan mentioned security. He talked about how you can have multiple different auth modes. Uh how you can integrate easily with WAF, AWS WAF for your firewall needs. Another new feature that we launched a couple of months ago was private APIs. And so private APIs gives you the ability to restrict traffic to your API endpoints to traffic originating from a VPC that you manage or VPC endpoints.

You know, there was a whole session on that earlier this week. If you're interested in, uh you can look that up on the catalog and see the video.

Um the other feature that I wanted to mention was uh what's here is real time. I Amazon Aurora PostgreSQL APIs. So we did introduce a capability within, within AppSync here at the beginning of the week to give you the ability to introspect any relational database and automatically generate a GraphQL and pub sub API from a relational database.

And so literally within less than a minute, you can provide your, your, your RDS endpoint, a couple of configuration choices for you in terms of how you want to expose that, maybe how you want to set up an auth in your API and it'll give you a full fledged GraphQL API. But in this context, ah for this session, you will also get with that the, the pubs of API, the subscription capability.

So you can immediately make any RDS, you know, for example, database that you have uh available to your, any, any clients for subscribing to changes that may happen to that data. So another session on that, that you can check out um at your leisure.

So the the the two I want having said that there's a couple of patterns that I'm seeing our customers adopt that I want to dig into a little bit.

So the first was how AppSync and particularly AppSync real time and these pubs of API architectures, our web sockets API capability are being combined with our customers, event driven architectures and specifically EventBridge.

So, you know, if you're not familiar with those terms, uh event driven architecture or EventBridge, you know, at the very high level, what it gives you the ability to do is implement an architecture on your back end, which with loosely coupled services that coordinate through a series of events.

So you might have an uh one of your services, maybe an order service that generates or completes an order and publishes that order as an event onto an event bus managed by uh by EventBridge. Uh and then different services might subscribe to that so that might be interested in reacting to that event.

So maybe it's a um you know, an inventory service or a shipping service or a billing service that wants to be aware of that event, respond to it and then complete their action and then, you know, post their event, their completion event back to the event bus.

So that's great for service to service interaction. But sometimes those, you know, I think of it as this event driven architecture or backend needs to, to work with the front end in the front end applications. And there's two parts to that.

The first is what I'm highlighting here, which is sometimes you want to get events that are generated from your front end, you know, into your event driven architecture into the into the services that are on the on the back end of your system.

And what you're seeing here is an example of how customers are using AppSync as a way to publish events into EventBridge to connect to their event driven architecture. And I'll tell an example of this.

The the example I like to use is Bill's Burrito. And so um everybody has probably used some, some you know, online ordering solution to to to order order food. Ah and in this example, you know, to make it a little bit more real, you can imagine a driver that's, you know, rolled up to my house with a bag of my burritos, sets them at my door because i still haven't unclicked the part where i want contactless to, you know, drop off, but they'll set it there at my door, take a picture, say it's done and leave.

And so that's an event. It's an event that's generated off the phone of the, of the delivery driver that's, that's delivered my burrito. And it's an event that many of the back end services might be interested in it.

So that's an event that can be pushed from a, from the mobile phone through, through AppSync into EventBridge and then passed on to other other services that might be interested in that.

So I imagine, I don't know this industry well, but I imagine there's all kinds of services that might be interested in what happened after that event. So it's maybe to pay the pay the driver or judge the driver or whatever the case may be. But I do know that there's one other person that really cares about that event. And that's me, you know, I want to know that there's a burrito sitting on my doorstep that's getting cold.

And so I've been watching on my, on my, either on my web browser or on my mobile phone. Uh and that's the other thing is we want to get events out of the back end and distributed and broadcast out to the, to the front end. In this case, I want to see a picture on my phone that my burrito has been delivered and I can see it there sitting on my doorstep.

Um and so that's the other way that we're seeing people use AppSync to, to really solve what we sometimes think of as the last mile problem. Sometimes we call it the port to the sea. It's giving your way, you, your, your front end is a way to interact with your back end event driven architectures uh through AppSync.

And so EventBridge is a pretty common pattern. You know, if you caught it in, in, in David's slide, I think in your case, you, you know, in this example, it's like a a lambda providing um you know, triggering an event in an Amazon EventBridge.

Uh I think in the case of your architecture, you've got DynamoDB, triggering DynamoDB streams, it's triggering a lambda ah that's generating this. So there's a couple of ways to do this, but this is a very common architecture.

And one thing that we've invested in is, you know, together with the eventbridge team, making it really easy for you to build these connections between absynth and eventbridge in this bidirectional man or either uh creating an integration of event from eventbridge into absynth or vice versa.

So that's a pattern one. And I guess one more thing that I want to say bef uh before I leave this example, um ryan mentioned um advanced filters and so in this example, i cared, you know, to take it back to my burrito, i cared about that burrito, but nobody else cared about that burrito. And i didn't care about anybody else's burrito. And so what i only really wanted to see was what happened with my burrito. And uh what we're able to do with what we call advanced filters or serve side filters within absynth is you're able to set up um the server side filters where pass some arguments when you create the subscription.

So in this case, probably my order id, that's going to allow me to just see what i want to see uh which is you receive that um that one particular message and i don't have to worry about filtering all this on the client side. The other thing that gives you is it makes it a lot cheaper because you're not passing all of these messages uh that that your customers aren't interested that you need to drop on the client.

Ah the feature that we did, you know that's been available for a while and absent the feature we did recently launch was enhancements to this where you see here an example of an event schema that has nested fields. And so we've given people the ability to generate filters off of nested fields.

So the the final scenario or pattern i want to talk about is how we're starting to see our customers use ab sync to help them build out new applications or new application features based on generative a i and specifically amazon bedrock.

So if you haven't heard about amazon bedrock or generative a i, i'm not sure what you've been doing the last couple of days, but uh you know, in a nutshell, you know, aws bedrock will give you the ability to interface with the, you know, a number of different large language models or foundational models uh to do things like, you know, generate textual responses or image responses in a variety of different scenarios.

And now you still need some way, you know, just like any other data source, whether it be a relational data source or a or a or a microservices. ht api ah you need a way to connect from your, your applications to your back end environments and you can do that really simply with a sync uh using what we call an http resolver ah to to, you know, trigger the interaction, a synchronous interaction between uh your front end clients.

Ah and in this case, amazon bedrock for all the reasons why you might need an api gateway of some sort. And the truth is, you know, we're not doing anything here different than you might do with like an api gateway or some other approach to managing this, you know, front to back communication where it gets really interesting with aws absinth.

And why we people see people beginning to adopt aws abs is for two reasons. The first is that if you've worked with these models, one thing you begin to learn is that um they work best in an asynchronous style.

Um and that's for a couple of reasons. so, um it's not your typical, you know, two digit millisecond synchronous, you know, request and response. uh often depending on what you're asking your, you know, foundational model to do, it could take 10 seconds, it could take 15 seconds, it could take 30 seconds, it might take 60 seconds.

Um you know, these are all scenarios that, that we see, it really depends on your use case. And if you're getting into more sophisticated like rag style integrations with agents, uh you're, you're definitely going to be measuring your, your s your response time in seconds, not milliseconds and probably tens of seconds.

And that creates a couple of of challenges. The first is that if that takes longer than 30 seconds and it sometimes does in lots of use cases, not every use case. um but i've seen a number of these now you're going to time out of a of a normal synchronous api call.

Um and that's just, it's just going to break. And so the pattern that we see people implementing is what you see here invoking the model through o lambda. Lambda has a 15 minute time out receiving streaming responses back from the model to the lambda that is then updating, absent as a mutation that's triggering the subscription to write back to the, to the client.

And so that's where how people are getting around that 32nd limitation. Um but we're also seeing that even if you don't hit the 30 seconds, even if it's just maybe 10 seconds, um, it's still a crappy user experience. You know, people don't like to wait that long.

And so, um what this architecture allows you to do is to, um maybe, you know, do something different in that time. And if you're familiar with these models, particularly like in a rag model or a rag c approach, where you're asking the the model to interact, you know, with different api s as well as its own um inherent capabilities uh and and create its own sort of orchestrate its own, you know, execution path ah in that scenario, which will take some time, you can start to surface the interim thoughts in the interim steps that the model is is is creating and maybe in, you know, provide the user the ability to interact with these interim thoughts ah in that user experience through this flow.

So those are a couple of the reasons why we see people starting to adopt a sync as part of their generative a i architecture.

Ah the second reason ah where where we see absinth being a good fit for these architectures ah is that, you know, so most people have, you know, have are familiar with the kind of the chat style interface that's become popular with these large language models. And so that introduces this notion of a conversation, a back and forth dialogue with the model.

Uh and now the model is not aware of the conversation, the way that you're interacting with the model. Everything's a unique request. And so what you have to do is you have to manage somehow that conversation to find the, you know, the structure of that conversation and pass the prior conversation history and context of the model uh throughout that conversation path.

And so, um with amazon bedrock, amazon bedrock has something called amazon bedrock agents uh which will do some of that for you. Uh but there are some scenarios where you want to have a little more control over that conversation history.

Ah so you might want to, you know, the context window and all the data that you're passing back and forth in this context history or in this history is what you're getting billed for. So you might want to have a little more control over that, maybe summarizing the data as it's going through.

The other thing that we're seeing is new kinds of user experience patterns emerging. So there's one here that i've listed called uh select and carry context. And what that means is you're seeing people say like they might ask a model to generate three different options and once they generate those options, they want to select one of those options, discard the other two options and go deeper down that one, maybe create an image off of that option or, or refine that option or those kinds of things.

So this gives you the ability or the people are looking for the ability to manage that and within a sync. Uh we haven't talked about it yet, but there's a, there's a capability called pipeline resolver. There are notion of resolver that's built into any query or invocation and that gives you the ability to string together and sequence a number of javascript functions basically that will trigger that can integrate or interact with different data source targets.

So an example i'm giving here, it's dynamo db where you might want to at the initiation of this conversation, create a record in dynamo db before you invoke the model that that defines maybe an id or some kind of of identification for a particular conversation and then as you and then keep track of that first conversation flow and then the responses back and so forth as you're going through it.

So that's, that's the way that you can begin to use. Or we see customers beginning to use a sync to support some of these emerging patterns for interacting with generative a i.

So there's a couple of examples that we've built out. This is an example of using uh a sync uh just to connect to a generative a i model through an hctp resolver uh you can look on our blog. Uh we've, we, we've also introduced a couple of examples uh and have some sample code that will show you how to, to implement the pattern that i just showed on the last screen.

So the, the final word here, thanks for bearing with us this long. I, we're going to try this ah survey once again um instead of the raising your hands and ah, as you pull that up on your phone, you should see a couple of things and, and these are things that, um, i didn't realize i'm going to have to remember i put on that survey, but, ah, you might want to, maybe i'll need to have you help me out.

But these are things that i've heard customers ask us for. Um, and the first thing that's on that list is if, if to explain it a little bit better, if i, if i remember correctly, is that ok? Thank you, subscriber, defined selection set. So this is where our customers are asking us for a little bit more control over when they initiate a subscription. What data do they get?

Um, so i think david, you were just asking for me about this yesterday, which is they want to have the ability to get the last known state of an event. Uh instead of waiting for the next event, have a little bit more control over that you can always initiate a query to do it, but, you know, customers are asking for a little bit more control over that, um, simplified.

Ah, well, i, i'm going to have to go from top to bottom now, presence detection on the bottom. That's like, you know, in slack, the, the little green button that tells you somebody else is there. Um, and so there's those kinds of scenarios. Again, it's something you can do today, ah, but it could be made a lot simpler.

Um metrics and logs i think are s are are are self evident, uh simplified multiregional dr support. So we've got, we do have a number of customers that are doing things like managing events that they diminish critical. Like you can imagine betting as we talked about earlier, the super bowl is a pretty big day and customers that are doing that uh invest in multi region architectures and disaster recovery. So there are simpler ways there's things that we can do to enhance that.

Um and then um this is my favorite. I was, i was curious to see how this would would turn out but the stand alone event api without graph ql. So what we are seeing is that the way that i think about it is, you know, we kind of started this absent is first was a graph ql service and it had this thing called subscriptions. It was almost like, do you want fries with a kind of option for graph ql?

And what we're thinking here is inverting that uh is that many of many organizations are coming to us? And they're saying what we really want to do is start with just the pub sub capabilities that you have available to us. You know, graph ql sounds nice. It sounds interesting, but, you know, i don't really want to learn it right now and my and my team doesn't want to learn it. My customers don't want to learn it.

So could you just give me a, you know, all the capabilities that you have without the graph ql? And maybe, you know, maybe, you know, i'll add the phrase later. Um which is truth be told. I think where you were at, david when we, we talked to re invent a while ago. Uh and you've since fallen in love with graph ql? Sure. But uh ok.

Well, could we go back to the slides, please? Of course, there's other things that are not on that list. I'll be here, please come up and talk to me after this session. If you have specific things you'd like to see us invest in from a feature perspective, the rest of us will be here available.

Uh i think we're probably just about out of time, more resources here. If anything catches your eye, there's a, a case study that david stein put together. So there's a qr code to that and if you're interested, ah as well as a link to some of the documentation and and a couple of ah of of goodies there.

So, so that's the end of our presentation. Ah the next slide i'll leave this up. The next slide is just going to say thank you. Thank you in particular for on thursday afternoon making it to what i think is the edge of re invent all the way over to the mandal liia bay at the top floor in the back corner. So i appreciate that.

And, um, and then also please do, uh take a moment to fill out your surveys. Uh we do pay attention to that. If nobody shared that with you, it has a big influence in terms of what we talk about at next rein event, how we talk about it, who talks. So, so it do take some time to thoughtfully fill that out. We'd appreciate it.

So, thank you, everyone. Uh we'll be up here if you have any questions.