Jen Person 0:10
Hey everyone. I’m so excited to be here. Thank you so much for the introduction, and I think that really summarizes a little bit how we all feel about JavaScript. It can have some really frustrating parts when you know it’s not, it’s just kind of silently failing. There’s always these like quirks to it. So that’s a love hate relationship, but it’s definitely where I spend my time these days. And yeah, I’m going to be talking about some serverless pitfalls, but you know, honestly, it was kind of hard to pick and choose, because every architecture has its ups and downs, let’s say so. In order to fit things in time, I picked a few that I thought really fit the most and be would be relevant to the most number of people. But yeah. So in terms of introduction, yes, I’m Jen Person. I’ve been in the Dell developer relations field for about a decade now, and during that time, I have primarily worked in serverless. I had kind of the pleasure of coming into the tech space when serverless was kind of the norm. So, you know, in terms of sort of more traditional architectures, where we might have some kind of like monolith. That’s kind of something I’ve put together, maybe with some projects when I was going to school, but I love that I came into the space where serverless was really easily accessible, and there were so many options to it. And you know, I especially enjoy back end as a service products, and that’s why I’ve had the pleasure of working on those over the years. And you know, honestly, I loved working at Google. I still love and appreciate the services that I’ve worked on before. So I just want to kind of touch upon the fact that it took something really special for me to decide to make the transition. And I hope you’re going to kind of feel some of that magic here. So but before we get into that, let’s let’s start with what the ideal serverless solution is how it’s kind of marketed to us in the utopian situation, sans all of its messiness. And what I generally tend to imagine is a puzzle like this one. So you have all of these individual pieces that serve their own unique purposes, and as long as you have, say, the same shape, so the same information is coming in, same type of information comes out of that puzzle piece. Then under the hood, you could change up that piece. You could change how it works. It’s modular. It would allow you to have choices about what services to drag and drop in, and ideally individual developers or teams or even whole companies, they can specialize in that service. So you end up with the best kind of database you can think of and the best kind of authentication solution, because people are just working on that, and you drag and drop it in. This is, this is the ideal situation, and this is kind of when we’re starting projects, how we imagine things are going to go but the reality is, as we know, quite different from the ideal, because you will always end up for what we’re calling this middle tier, because the pieces themselves don’t communicate with each other automatically. So that involves creating all of this glue and gunk and messiness that’s going to hold your serverless features together. And instead of just one piece connecting to another, you have multiple pieces that need to connect to each other in all sorts of interesting and unique ways, and then you connect it to your front end. So, you know, this is just one of the multiple pitfalls to look out for that can really slow down your development. And for the most part, it has to do with this infrastructure, this glue. So in general, we’re going to be focusing on that, but everything kind of falls within that realm, and these are the pitfalls that I opted to talk about, but certainly there are a lot of other ones, including cold start, which is something we’re all familiar with as well. But yeah, I think there’s a lot of good stuff here, so let’s just dive in and talk about some problems, and I’ll try to give you some answers to it. So again, this complex architecture, this is by far your biggest slowdown, and it’s one of the most common criticisms of serverless, because it ends up being much more complex in some ways than when you have some kind of mono repo. In this scenario, you know your specialized functions, each individual one is still incredibly simple, and you can write that functionality to say, call a query to a database, and there are so many great options and APIs and SDKs that make that simple, but getting all of those pieces to come together when you have so many of them, that’s where you end up with this mess. And you end up with an ever growing boiler plate that needed, that is needed to communicate between these services. So in terms of solutions, all of these things are going to be not entirely to resolve it, because these are sort of implicit to a serverless architecture, but there are certainly some things that we can do to mitigate it. So one of those to look for is to make sure that you’re focusing on asynchronous. Messaging. So especially if you find yourself you know, writing your programs and you have multiple services, even in a single file, it can become very easy to fall into a space where you’re trying to get things to happen in a specific order, so you’re calling them one after the other. For example, I had an application that I was just working on the other day where when the client is making a call to the back end, the back end needs to do several things at once. So it needs to query an API to get the weather. It needs to write that information to a database. It needs to pass that information to an AI to generate some lists. Those lists go to the database, and then once that, you know, and then I also was generating an AI generated image, and that had to go to the database. So in a traditional mono repo, you might just have those in one function where you’re going one and then the next, and then the next. And of course, that’s going to fundamentally really slow down your application, and you’re really joining those different features together more tightly. When you do that, you’re really binding them together. So focusing on implementing things like messaging queues or web hooks or functions that specifically respond to events like a write in the database is fundamental to speeding up your overall architecture and also speeding up your development, because now you are more loosely coupling those different features. When you set up something like an Apache Kafka messaging queue, what you can do is just send out a particular message like that. You are creating a new user, and you can have all of your services listening to that messaging queue and taking their actions individually. So instead of being tightly dependent on one happening versus the other, they can all listen and then, as you can imagine, when you’re adding more features as you are going to it makes it much easier to implement those as well. I’m going to take a drink of water because I have a tendency to talk very fast and not breathe very well. So bear with me for just a moment, because we’re going to talk about back end as a service, which is one of my favorite things,

Jen Person 7:09
I love back end as a service, and I love anecdotes. So we’re going to jump into both of those things. There are so many great, complete solutions out there, and the one of course that I started on was on Firebase. And my first job in that role was to create, create a course called Firebase in a Weekend, showing that you could build a really interactive iOS app or Android app alone in just a weekend, because the features really do speed things up that way. And so Backend as a Service, again, is not going to fix everything, and we’ll talk about how that has its own drawbacks, but it can dramatically reduce the complexity of your architecture because, ideally, because these services are all supplied by the same product, they communicate with each other much easier. And you might have built in features like that responding to events. A lot of those are going to be built into that back end as a service. But of course, when you’re dealing with a back end as a service, you’re also going to be dealing with vendor lock in, because unlike what that puzzle suggests, where you can just take out one piece and put one in, that it’s going to fit exactly the same way. Generally, once you’ve chosen a service, as you know, it’s really difficult to transition to another, and that’s going to slow down your development. So for instance, if you’re comparing the functionality of AWS lambda functions to Google Cloud Functions to Azure functions, you know they’re going to be quite similar in how they operate, but changing from one service to the other is going to be basically a complete rewrite, because under the hood, the SDK, the APIs, they’re going to be different. So it does really tend to feel like you’re going to be locked in. So, you know, sometimes you have to deal with products being deprecated as well. But I think one thing that is going to fundamentally happen, no matter what kind of solution you pick, is you’re going to have something unique to your application that isn’t provided by any other service at that time. So even the most robust back end as a service is going to be missing things that you need, like if you have internal APIs, or you’re connecting to some other kind of external specialty API, you know that that back end as a service isn’t going to be familiar with it, and then you’re back to kind of writing your own boilerplate code and in terms of solutions, you know that’s this is definitely one of those problems that is generally not completely avoidable. You certainly could write all of it yourself, but that is something that we generally like to avoid, because that’s not really going to be time saving, and it doesn’t really fit why we decide to go into serverless, because it makes development so streamlined and you can get things done in a way that feels simple, like that puzzle. You can also rely on open source solutions, and that can kind of ease some of the concern about vendor lock in, because you can have your own copy of the code. You can own it. You can change it as you need. To but certainly, when we look at things like left pad, we know that no software is forever, and so you’re never completely mitigating that risk for vendor lock in. And you’ll notice in all my solutions, I kind of end with an or because I want to hint at the fact that there are some things that squared cloud does really well that can also help mitigate this. But again, just when it comes to vendor lock in, you just want to really focus on services that you can trust to the best of your ability. And you really want to avoid writing it all yourself. Speaking of anecdotes that I enjoy, there is a I was once watching an episode of how it’s made, which is sort of the show, where they show you, maybe in a factory, or how some particular product comes together. And it was for soy sauce. And it was really interesting, because the ingredients in soy sauce, fundamentally, were really quite simple. It was like soybeans and salt and water, and then there’s a fermentation process. And I thought to myself, Wow, maybe I could make my own soy sauce. Maybe it wouldn’t be that bad. It would take some work, but I could kind of get the hang of it. And I think that’s what comes up sometimes. When we say we’re going to write something ourselves, right? You have something that’s a real time database that feels pretty simple in nature. But the question is, do you want to be making soy sauce, or do you want to be making dinner? Because you can’t be doing both, and we like to make dinner, right? We like to make the applications, the services that are going to be touching the end users. That gets them excited. We’re generally not people that want to be focusing on that infrastructure. So there are some things you can do about vendor lock in to some degree. So stay tuned for that little teaser, and this one, I find, is incredibly important, and upfront, you might not feel the slowdown if you’re not paying attention to it. But not only can your security configuration generally slow down your app at some point, it is just incredibly important to the lifetime of whatever you’re building and to your livelihood, basically, when it comes to a serverless architecture, instead of having a monolith where you know you’re just locking the service from, it’s just probably one way in and one way out, and you can kind of gatekeep in that way, each single surface ends up being its own concern about how you can access it. So you’ve really expanded the risk space. So all of these APIs and databases and services that you’re connecting to, they’re going to each need their own fine grained security rules, and you’ll find that each service has their own way of writing those security rules. Maybe you’ll have to do it in a console. Maybe you’ll have to do it in some esoteric JavaScript like language, and maybe you’ll have to use some framework that they want for you to write your security rules in. But now you’re keeping track of all of these different services and how they expect you to secure them, and it is really easy to make a mistake. The more services you incorporate, of course, the harder that’s going to be. And along the lines of security, you also need to secure all of these services, potentially with some kind of API key or a password or certificate. Inevitably, they’re going to require it. So how do you store these and how do you access them in a way that ensures that nobody is able to suddenly read them, and you know that they are securely stored. If you love security, this might be an area that you enjoy, but again, I’m kind of a person that enjoys making the stir fry and not the soy sauce, so I want an option that I know I can rely on I don’t necessarily know enough about security on my own to be able to say that, yes, absolutely the way that this information is stored is going to be secure, and that’s definitely going to be a risk in this serverless environment where you’re passing all that information around. So in terms of solutions, you need to be using some kind of allow list instead of a block list, deny list. And again, this is going to maybe take more time up front, and we all know that we should be doing it. But I bring it up because I know from experience that not everyone is right off the bat, especially when we’re in the development phase. We kind of get in this habit where we think, Oh, well, you know, it’s going to slow down my development. I will add that security afterwards. I’m just going to write all things that so I know that they’re working properly. And then I’ll worry about, you know, setting up my security rules so you leave things open to begin with. We we’ve all done it at one point or another. But again, because you have this massive service surface area with all of these services, when you set that up, inevitably something is going to fall between the cracks. And we’ve seen it happen time and again. It might make why, you know, it might make like the news or something like that, when there’s rules that have been left open and people are definitely paying attention to try to catch that. That. So always start take the time up front to make sure that your rules are locked to begin with, ideally even in the development phase. It’s not fun, but it will save you time in the event that something goes incredibly wrong, and definitely ensure that your data is encrypted at rest. So you know, you really want to make sure that if you’re using some kind of service, you can trust that they’re doing that as well. So you can’t necessarily reduce that surface area, but take the time upfront, and it’ll save you time in the long run, because then you don’t have to chase down those security rules later. And of course, I’m leaving room for an or because I do want to talk about how Squid cloud handles this because I think it’s something that we do beautifully.

Jen Person 15:47
And so let’s talk about testing challenges a bit after I water, yeah, testing challenges, you have this massive distributed system, and you need to make sure that it really, truly works the way that you want it to. And you can mock things up and unit tests as much as you want, and you should, but nothing is really a substitute for truly seeing how these things come together. That’s also a great way to check for those security risks, for instance. So you need to make sure that you have the right permissions set up. You’re testing with the user that would really have the correct permissions set up. There’s a lot going on there. So how exactly do you make sure that you’re really getting all those things to work together, especially without interrupting your production of course, you don’t want to run this on your production version of your system, having all these things you know, you don’t want something to go wrong there. So certainly run unit tests on your business logic as a solution, and definitely maintain a dev and prod resources for all of your integrations. So a lot of services out there are going to have some kind of sandbox instance. You know, when you’re in the development and testing phase, you can connect up all of your sandbox instances, and then you’ll be able to really system test, integration tests in a way that fully mimics how things work in the wild. And then when you’re ready to deploy, you know if you’re using nvars or something to indicate which services that you should be connected to, it’ll be much simpler to ensure that things are working the way that you expect. And you’re going to want to have some observability as well. So plenty of great observability features out there, like Datadog and New Relic, can show you how those systems are working together in the wild. So that way, you know, not necessarily in the testing phase, but when things are in the wild, you’ll still be able to catch them. And of course, there’s an or for these reasons and so many more when dealing with this serverless environment and back end as a service features. This is why we created squid, because, you know, it can help you untangle the complexity by managing a lot of that infrastructure for you, so you can focus on developing features. And again, this is something that generally a back end business service does pretty well. But what makes Squid special is it can connect to any database, any API, any service. You really can just change out those puzzle pieces the way that you want to so how does Squid solve these problems or help mitigate the risks to slowing down your development? So again, Squid provides the connections for all sorts of databases, APIs, the things that you would expect from a back end as a service, so that you don’t have to create them from scratch, scratch, and it uses straightforward SDKs. If you’ve ever used something like supabase or Firebase, then you’d be very comfortable using it so it lets you organize your applications in such a way that you’re not going to end up with all of that spaghetti code. But what about vendor lock in? And as I said, it’s not something that you can mitigate entirely if you choose to use something like Squid cloud. The way that Squid helps with that is that, because it is the same exact streamline SDKs, no matter what service you’re using, if you opt to change something out, the way that you integrate in, your code is going to be virtually identical. All you have to do is change out the name of the integration, and the way that your code operates will be the same. And that’s true whether it’s a NoSQL database or a SQL database, whether it’s Microsoft SQL Server or snowflake or CockroachDB or MongoDB, no matter what it is, they actually have the same exact code that they use. So yeah, you can connect to any API or database using the same easy setup. And once you get the hang of it, it’ll be just as easy to connect any other service you want, and you can connect as many as you want as well. So yeah, we you really can if you’re wondering, can you connect this? Can you connect that? Yes, you absolutely can. So plenty of services to check out. And if we have time at the end, because I’m speaking so quickly, we’ll probably get to that. So what about the security part? And this is one of the parts that I think Squid does incredibly well that makes me super excited about it. Your security is fully customizable using TypeScript functions, so there’s no need for some kind of strange, esoteric JavaScript like language, you don’t have to go to multiple consoles for every single product you’re using to write your solutions. There, everything is streamlined in one space, and because it’s written in TypeScript, it is easy to read, and it is easy to write, and it provides some contextual information about who is trying to take a certain action and what action it is that they’re trying to do. So you’ll be able to write exactly who can and cannot access something. So you can check is the user authentication authenticated? Do they have the specific token information that is required to access this particular feature makes it really easy to say, call to a database and check if they’re on a particular list. You can just say that they’re, you know, really streamlined. You can be really specific about what areas of a database they can access, or what part of an API they can access, and it just, it’s just really sped up development, I’d say one of the biggest things for me, and it’s secrets management, it’s something that I don’t spend too much time talking about, because it is so incredibly simple. Squid has a system that can hold on and to and secure any sensitive data that is required for, like the different functionalities that you need to run in your application. So by either writing it in the Squid Cloud Console, or you can do it programmatically as well. You just store your secrets there, and they’ll be accessible when you need them, but they’re not visible and they’re encrypted, and our team does an incredible job of that. But what about testing? You know, I definitely mentioned the dev and prod environments, and that’s another thing that gets me really excited about squid. There are Dev and prod environments available out of the box. So when you create a new squid application, what you get is kind of mirror images, let’s say, of the same functionality, where you have a built in database, a built in Apache Kafka messaging queue and a built in storage bucket. Although you can add whatever configurations you want, you can integrate with whatever features you want, but this helps you get started right off the bat, and these features for your dev and your prod are completely separate, so that when you’re developing things, you know that you’re not going to be messing with your production environment and vice versa, so you’re able to connect the sandbox versions of your different features in the dev or even, you know, if you just want to make exact copies, and you’ll be able to really test and know that things are working the way that you want them to before you deploy. But honestly, this is just one part of it. There’s so much more to this in terms of APIs, because that’s how a lot of things communicate, especially if you’re trying to, say, modernize an application, and it only communicates via API. At this point, if you have an open API specification for that API, you can drop it into the Squid Cloud Console, and it’ll populate all of your information automatically. And you know that when you have something incredibly complex in your APIs, it’s great way to keep track of everything that is in your schema. On the other end, if things only communicate via API, you can generate APIs in Squid cloud, and we will give you an open API specification for it, so that you can use that to communicate with that other service. So you’ll be able to see all the information about the API very easily. So APIs go in very well. APIs come out very well. We have kind of the serverless features you would come to expect, like what we call executables. So when you have code that needs to run in a secure admin environment on the back end, but you need to access it from a client. You can do that using executables, so you can just easily set up those security rules on the back end to determine if this person is able to run that function before you do so. And you can create cron jobs with schedulers, and we have an incredible amount of AI solutions that work seamlessly with your data, no matter the source. So you integrate whatever your data source is. It works beautifully with Squid. And we also, you know, in an effort to be unopinionated and allow you to connect whatever services you want, we offer connections to multiple different llms. Now I do have some links here that I want to show again in a bit, allowing you to get started and try it out. And I really want you to come talk to me on our Discord, so that I can help you think of ideas, answer questions, you can give us feedback. What’s great about Squid is you know when you need to i. Ask questions or troubleshoot. You know, you’re not sent to some sort of system in a queue to get help from support. You’re getting help from us directly at any time. But it looks like I have a little bit of time to show some code, which I was very excited about. I have here a very basic demo that is showing some is showing some data that is stored in a snowflake database. So you can kind of think of this as some kind of product orders. So you know, there’s an order date and an order price and status, etc.

Jen Person 25:33
And so if I want to ask some questions about that data that, again, doesn’t belong to Squid it, it belongs to snowflake I could say something like, how many orders were over $200,000 in 1998 you never know. You might want to look back at your data from some time ago, and it’s going to populate a response for us. And again, what’s what’s magical about this is this doesn’t have to be a source that comes from squared it can come from anywhere. And you know, when it comes to AI, we know that things are gradually speeding up, but what you can do in this case is, you know, these could be part of workflows or things that are happening on the back end that make it more streamlined. So in this case, let’s say 40,325 orders so, and it even tells me the SQL query that was made. And you can do the same thing with a NoSQL database, which is super exciting. You can also have it generate graphs and charts. But what I really love about this is that, you know, I have my snowflake shop, I have my built in database, and if I want to checking out my code here, given a little preview of how things look,

Jen Person 27:09
I can do that, and now I’ll have a different data source, although

Jen Person 27:20
I might need To refresh it because it’s been sitting so long. Do one of these refreshing okay, this is always the problem with doing it live. Am I supposed to do? Yeah, I’m doing, ah, I don’t know if anyone caught it supposed to be underscores, yes, I love this. I like to live dangerously, exciting, that will also slow down. That will also slow down your development if you make an error,

Jen Person 28:09
okay, I might have broken, broken that now that’s what I get for doing a live demo. All right, well, we’ll come back to that. But what I really want to show you right now is, you know, I want you to try out these features yourself, and we could really use your feedback on if this speeds up your development. And you know, what features are you really need when you’re working in a serverless environment. So definitely go ahead and try squid. So the link here is Bitly slash underscore a board, and that’s going to put you into our sort of onboarding flow where you can build an application and adds different features to it, and you can really see how simple it is to put together and definitely join our Discord as well, if only to roast me about the fact that my live demo failed, because I think that it happens to the best of us, and also to me. So Bitly slash Squid dash discord, I really want to see you there. Come join, join our really exciting community, and I hope you see that squid has a lot to offer. And I hope there are at least a few nuggets. There are a few reminders about how to improve your serverless development.

Sean C Davis 29:29
Thanks so much, Jen, that was great. And yes, Bravo for the live demo. And also, I’m kind of suspicious. I think that maybe it was intentionally broken, because the last pitfall is, don’t make typos

Jen Person 29:45
Exactly. Yes, we’re gonna go with that for sure.

Sean C Davis 29:48
Yeah. Great, great, good. Okay, we have a question from the audience and so and the rest of you out there, if you have any questions for Jen, drop them in the Q and A tab on the right side of your screen. But let’s. Let’s dig in. So coming to us from Brian. Brian says, so can you do orchestration with squid, like what you might do with an AWS step function?

Jen Person 30:10
Um, I’m not familiar. Can you tell me a bit more about that?

Sean C Davis 30:18
I’ll, uh, yeah. I’ll let Brian comment on that portion of it. One a related question that I had that I’ll drop in here is, so you’re integrating with all of these various providers using Squid, and is, is Squid actually managing the services for you, setting up the various services, or is it more of an interface to be able to work with them after you have already done all the provisioning and management and all that? Yeah,

Jen Person 30:49
that’s a great question. You know, at this time you provision and manages, you spin up the services yourself, and then you connect them to Squid, and then, you know, Squid kind of handles that business logic part of it so that you can set up the security functionality to it, but yeah, it doesn’t directly set them up for you.

Sean C Davis 31:10
Okay, okay. And, and early on in the presentation, you mentioned that there’s tools that you might always want to inject into or use alongside your serverless functions. And heard you mention Apache Kafka a few times, and so, yeah, curious what? What are those go to services for you? And then maybe part two of that is, which ones are? Are Squid providing? Is Squid providing on your behalf? Or is it more like you have a set of recommendations and and then you can choose to add them if you want?

Jen Person 31:53
Yeah, yeah, that’s a good question. Um, you know, I’d say in in general, I like that just some kind of database triggers are definitely some kind of go to functionality to handle the asynchronous nature of your code, because then you’re specifically responding to events that are happening. And it also can eliminate the need to set up some security functions if you want something to happen as a result of the client making a change to the database, but you don’t want that client to have access to whatever that particular feature is. So Squid does provide triggers so that, again, no matter what database you’re connecting, you can say that, okay, when some change is made to this collection, which would be a collection of documents or a table in a SQL database, you can dictate what you want to happen as a result. So yeah, triggers are definitely a big part of that. Definitely cues. Squid does something unique in the sense that you can subscribe to your messaging queues from a client. So if you can send messages to a client, where normally you’d think that is primarily for back end functionality, and it certainly is. There can be some if you want something to change about the view as a result, you can do that. I would say that’s definitely one of the go to ones and web hooks. I think they’ve certainly been around a while, but a lot of services do communicate that way. You know, I’ve worked with implementing things with stripe before, and using webhooks is definitely something that I think is a requirement for any kind of serverless application. And Squid does provide webhook functionality as well.

Sean C Davis 33:39
Okay, very cool, very cool. And yeah, okay, Brian elaborated a bit here and said, in an AWS step function, you can manage the entire flow between services like call this lambda and then, based on that result, do something else and so on, something wondering if you support some sort of flow like that.

Jen Person 34:00
We don’t yet, but I absolutely love that idea, and we will certainly put in a feature request for that. So is that something then that is primarily maybe provided through a UI, or is this something that you would write? Yeah, I’m going to look into that more, and I’m definitely going to put a request for it, because I think that really suits the the ease that we’re trying to, you know, accomplish. It

Sean C Davis 34:27
definitely seems like you’re trying to stitch pieces together and and back in pieces and then, and then add this layer of ease on top of that, like, for so back to authentication. It sounds like, I mean, you, you would have, you’d have some sort of authentication, or, you know, user based access for, say, a database. And then it seems like Squid is, are you leveraging that access? Or is Skuid an entirely. Different layer on top of what you how you might be protecting your database otherwise,

Jen Person 35:06
yes, I’d say that Squid is sort of a level on top of that. Because generally, when you’re granting access to your service, you’re generally, I mean, you can definitely set up like, you know, whatever certificate or particularly like what permissions you want Squid to have as a whole? If there’s something that you maybe never want someone to be able to do, but you can generally think of Squid would be sort of that admin user that you are then writing your security functionality on top of it. But yeah, you can certainly if you have, like, a particular service account, thinking about how you connect things from GCP, you can say what you want Squid to be permitted to do, and then Squid will only be able to do those things on your behalf.

Sean C Davis 35:51
Okay, okay, this makes sense. And so you, you mentioned at one point that there, there are a number of services supported that you wanted to get into. And so I’m curious to hear more about those. But in particular, AI, especially because you had, you had a comment on having a TypeScript SDK for AI and can support various llms And yeah, so we’re curious, what are some of the use cases that you’ve seen with folks using AI and Squid together?

Jen Person 36:23
Yeah, that’s a great question. And, you know, sometimes it’s, it’s been challenging to try to pick what kind of example we want to give, because each industry is going to have something unique. But, you know, for example, if you’re in some kind of CRM system and you want to in your in sales, and we had someone who’s looking to maybe prioritize what sales calls to make next, or, you know, get a sense of, you know, who the best leads are going to be. You can implement it such that, either on a scheduler or so it’s running on a cron job, or maybe something like a trigger, you can have you basically read information in the database that you want. You can provide that to Squid AI. And Squid AI can sort of say, pop out a number to say who is most likely to respond based on what you already know about them and the interactions that you’ve had that you’ve listed in your CRM. And with Squid AI, you can provide, well, you know AI functions. So if you need to run particular code as a result of, you know what Squid AI is doing, you can do that. So you can have it say, you know, generate this number for me and pass it to this function, and then the function will write it automatically back to the database. So you can really set up flows like that. We also have someone in the healthcare industry that has used it to eliminate a lot of the code that they have to write. It’s a really small team, and, you know, maybe like one and a half engineers, but in but using Squid AI and just writing instructions for how they want their AI to work, they’re able to stream fit line things like workflows. So when someone connects to their chat and makes a request, the AI can determine what steps should be taken next. Are they trying to schedule an appointment? Do they need to look at medication refills? You know, it can then take particular actions as a result of it. So that’s something that I think Squid AI has done beautifully, and generally, because I work in DevRel, I tend to do things that are just mostly for fun, which is some great part about the job. So I made a Vacation Planner that, you know, basically makes a call to a weather API that can tell you the predicted weather in a location up to 90 days in the future. It takes that information from that API, passes it to Squid AI squid. Ai tells me what I need to pack for that, and then passes that to a function that writes it to the database. And then from there, that information when the triggers an API that checks Google Shopping to find links to the particular items so that if I’m missing anything, I can just click it to add it. And those are the kind of things that are maybe fun, but can hopefully help you see how they would relate to a real application.

Sean C Davis 39:15
Definitely. I mean that example is awesome, because even though it might not necessarily be something you would actually build for yourself. It shows how you can stitch all of these different pieces together to make something that that could potentially be very useful to some folks Exactly. Well, thank you very much. Jen, this was, this was great and great conversation. After the talk, I’m excited to check out Squid and for all of you folks in the audience, go check it out as well. You.

Transcribed by https://otter.ai