Podio Solutions Podcast

S1E9 - Scaling Podio Solutions 1: "SaaSsafras Scaling for Podio Solutions"

March 11, 2019 Brick Bridge Consulting Season 1 Episode 9
Podio Solutions Podcast
S1E9 - Scaling Podio Solutions 1: "SaaSsafras Scaling for Podio Solutions"
Chapters
Podio Solutions Podcast
S1E9 - Scaling Podio Solutions 1: "SaaSsafras Scaling for Podio Solutions"
Mar 11, 2019 Season 1 Episode 9
Brick Bridge Consulting

Podcast Outline – Season 1 – Episode 9 – Scaling Podio Solutions 1: "SaaSsafras Scaling for Podio Solutions"

Discussion Outline:

  1. Introduction – The Shameless Plug - Why are we sitting here today (Founding Story)
  2. Topic:  "Turning Podio into an Enterprise Level Provider"
  3. 1st Discussion: Why SaaSsafras Exists - Problems we encountered
    1. Cross Workspace Issues
    2. Zapier (integration) issues
    3. Keeping Podio current
    4. Aggregate Reporting / Formatting
  4. 2nd Discussion: The Solution - Current Capabilities 
    1. Deployment
    2. Patching
    3. Flow Engine
  5. Problems that we have had to overcome
    1. OAuth
    2. Caching
    3. Rate Limits
  6. Plans for future features
  7. Call for use case examples, beta users, feature expansion
  8. Outro: SUBSCRIBE and Thank you.

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (http://www.brickbridgeconsulting.com/podcast)

Show Notes Transcript

Podcast Outline – Season 1 – Episode 9 – Scaling Podio Solutions 1: "SaaSsafras Scaling for Podio Solutions"

Discussion Outline:

  1. Introduction – The Shameless Plug - Why are we sitting here today (Founding Story)
  2. Topic:  "Turning Podio into an Enterprise Level Provider"
  3. 1st Discussion: Why SaaSsafras Exists - Problems we encountered
    1. Cross Workspace Issues
    2. Zapier (integration) issues
    3. Keeping Podio current
    4. Aggregate Reporting / Formatting
  4. 2nd Discussion: The Solution - Current Capabilities 
    1. Deployment
    2. Patching
    3. Flow Engine
  5. Problems that we have had to overcome
    1. OAuth
    2. Caching
    3. Rate Limits
  6. Plans for future features
  7. Call for use case examples, beta users, feature expansion
  8. Outro: SUBSCRIBE and Thank you.

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (http://www.brickbridgeconsulting.com/podcast)

Gil Roberts:

Welcome to the Podio Solutions Podcast, season one episode nine. With me today is Alex Shull and Jared Duker and I'm Gil Roberts, here at Brick Bridge. This podcast is about the design and development on a Citrix podio, podio , podio.com. We use this podcast to discuss her own experiences with podio as well as other interesting topics from the podio developer community. If you're a podio designer or developer working at an agency, small business or enterprise, you should immediately hit that subscribe button if you have already. Thank you so much for the support. Lastly, before we dive into today's topic, if you have a topic, issues , solution, problem, or anything else you'd like to discuss , uh , we want to know, we'd like to possibly even have you on the show. So please hit us up at Facebook, linkedin, Twitter, or send an email or podio message to podcast@brickbridgeconsulting.com. Today's topic is scaling of podio solutions. Again, this is going to be again, another one of our mini series that we'll have today. We're going to be talking about Sassaafras we've talked about in a lot on other episodes and we wanted to give it some justice , uh , with its own episode today. So , uh, let's start with you Jared talk about Sassaafras for us and how this came to be.

Jared Duker:

All right . So we've kind of danced around this topic over the last eight episodes or so, but what it comes down to it. Uh, we got involved with the podio platform , uh , sometime ago and we loved what it could do for our different organizations that we were running at the time. And we saw this amazing capability for allowing industries to quickly build out products for themselves. But there were some problems and some pretty big problems. And where that hit was replication and scaling. Anyone who's ever tried to make a copy of their podio solution are going to know what we're talking about very, very quickly that you can, you can export it to the APP marketplace globiflow links in and lets you copy apps over. But it is a very imperfect solution. Um, and , and where the really strikes in Cross workspace integration , uh , when you copy every podio workspace exists as a standalone universe. It knows about the apps inside of that workspace. You can copy the workspace, but most of us need to have much more flexibility than that. Especially when we talk about enterprise level solution. We need to be able to preserve those cross workspace references. When we copy a workspace. And right now it flat out does not do it . Any copy that you make have a workspace is going to link back to whatever the first workspace copies. So A to B and you make a c c is going to look today . We want to make c and d that look to each other and flat out cannot do it right now. The next issue that we encountered was with Zapier and other integrations. Um , absolutely wonderful, wonderful tools, but you end up constructing what is very much a house of cards. You can personally place each item in a, in a, in a integration , uh, and it works great, but as soon as you try and make a copy of it, everything just falls apart. Zapier flat out won't even allow you to copy flows without going into , um, quite a bit of effort into their team environment. Even then, it's very imperfect. So if you need to make a copy of your workspace, okay, yeah, we can have, we can do this, but I need to make 500 copies. Pretty soon you can't even hire interns to do this. They quit the next day. No one wants to do that.

Gil Roberts:

It's somebody that's had to do it. And then we've had um one of our employees also do that. It is not the most fun job.

Alex Shull:

That's when you're bring in an intern and your slider that just to break them down.

Gil Roberts:

It's really want to break somebody's spirit. That's , uh , that's the best way to do it, right.

Jared Duker:

What you're interested in actually doing is you're not making a photograph. You're painting the same painting 500 times, brush stroke by brush brushstroke to reach the level of, of detail and , uh , an integration that was what really makes podio so powerful and so great. Anyone who's logged into a handcrafted environment knows it instantly and everything is just beautiful until you try to make that copy. And then, unless you're gonna repaint the whole thing, it's just not the same. Uh, the next one that we encountered and this one came up as part of our impact pro project is the world is constantly changing. Processes are constantly changing. Business requirements are constantly, and podio environments aren't. We can make a change to a environment if you've got assistant administrator in your organization, they can tinker to their heart's content and it's really beautiful because they just don't modify template, make the changes that they need. Awesome. But we have 500 environments that all need to have that hand change made to it. And there's no way to deploy a mass patch out into the podio environment right now, which means that even if you can get that intern to make the 500 copies without , um, any problems, unfortunate consequences, we'll say now you're going to ask you to go into those 500 copies and rename a field every time you want to make a change or some new directive comes down that needs to get addressed. Good luck to you.

Gil Roberts:

To say the least. It's very labor intensive

Jared Duker:

And not just labor intensive mind numbing labor intensive .

Gil Roberts:

Yeah, of course.

Jared Duker:

Cause I'll, I'll build something beautiful. It's very labor intensive but you know, building the same retaining wall over and over again by hand gets very, very difficult.

Gil Roberts:

We identified this back in our impact pro design episode, I think it was episode two so

Jared Duker:

I've brought up these issues before but I'm just, I'm just kind of iterating the list right now for us.

Gil Roberts:

So when , so when you and I were still working on impact pro and the alpha and we finished it off and we're like we need to take a clean copy. That's when it really like we knew beforehand, but that's when we like experienced that

Alex Shull:

that was the scale of the pain because you knew that it was going to be some pain. You didn't realize how much pain, then you realize that it took over a day to create a copy dense three days.

Gil Roberts:

Well actually four days to be honest. Yeah. Dylan sat there for four days a poor guy.

Alex Shull:

I feel like thats more efficient if it takes a day, that's a lot of labor just to do the deployment.

Jared Duker:

We got it down to a couple of hours, but still the groan that I would get when I would come into the office and say, Hey, we need another copy of this. It was not sustainable

Alex Shull:

and we're not talking about you click a button and then you wait hours. We're talking about hours of labor.

Jared Duker:

And you can be carefully reading lines of code to check check for errors, which we never got to fully clean copy. There was always an error that snuck in somewhere.

Alex Shull:

Well and it's interesting because you know, we sort of talking about these concerns, you know, right at the very get go when you guys started talking with me about joining the company and i's ability to podio and I saw the API capabilities and I was immediately convinced that I could write software that did what you needed to do that could automate those steps. And um, I also came to learn over time why it wasn't built into podio to begin with. And that I think that's an interesting story. Not necessarily a story for today's episode, but if you actually look at the design philosophy of Podio, it actually makes sense that it ended up in this situation. And what we've been doing I think is saying this core API supports a lot more and to be able to um, accelerate those other usages of that core Api, we're adding on new value layers that leverage the underlying API and it's advantages, but then create some value on top of it. We feel that's , that's the way that I view podio and Sassaafras the relationship

Jared Duker:

because when we get down to it, podio is a beautiful web based form system with an underlying database. I mean that that is the core of what it does. Even globiflow was not incorporated out in the box, but globiflow made people aware of the business power that was, that was there. And citrus recognize this by acquire the company there shortly after . I mean , but it took podio from being a nice form software to being a business engine. And as soon as they opened it up to being a business engine, what we want to do, and it was, it's the next logical conclusion, okay, you can build a business engine for your company. Now let's build it for all the companies. Like you...

Alex Shull:

Yeah. And the story of Podio, if you go back to the early days of it, you really see that it's a, it's, it's what used to be called Rad rapid application development, but it's entirely service oriented and it's entirely cloud based. So it's this modern version of a rad tool and it's not like, in my opinion, it's not like salesforce because salesforce has a strong bias. And so it's this very unbiased rad tool. And I think that's what smelled it too . Early success and Sassafras. Now as the name indicates, we're trying to turn that into a Sassaafras deployment tool from the podio origins. And that's almost taking the , um, the, the level of independence where every user of podio that they built into it from the beginning to let you spin up your own organization, your own software, your own design specific to your needs, and then condensing that back into a distribution of whatever came out that's so good based on podio and make it again available for a bunch of different users. So we're kind of reversing that model because they put it so rad on Sassaafras they're rad tools, our softwares and service, and we're taking the assets that you build with that Rad tool and turn it into the Sassaafras.

Gil Roberts:

Right. And that makes a good point . Always saying we're taking it from the home kitchen to the commercial kitchen.

Alex Shull:

Yeah, that's a great metaphor.

Gil Roberts:

We're scaling a , what you're able to do for yourself. And what we've seen this in the real estate industry, we've seen this in nonprofits that we deal with. We've just seen these in a lot of different solutions. Uh , Jordan and his group with poop boost pm that they come up with something and, you know, friends talk, right ? Industry peers talk to each other and go kind of software, are you using go , well, I have this custom on that I built , I really love. And they're like, oh, I'll tell me about it.

Alex Shull:

They want the goods.

Gil Roberts:

Right. You know , and then like how do I get that? How do I get in on that?

Jared Duker:

Well no. Up until last year, the answer is you can't, you , you can, you can struggle through and make a copy and you know, for a friend, yes, this can happen. But outside of that...

Gil Roberts:

And I think because it's 2019 one of the, one of the big expectations is I go to a website and her credit card number and receive my software. Right. Because that's like how most software is now. And it has been for a long time. It used to be, I entered my credit card number in , my CD was shipped or I walked into a computer store and I bought it off the shelf and walk on this stuff. Stuck it in the dry, right. Like it was, I pay, I get software, end of story, not I have to talk to my friend and then go hire a company and develop it and all these other kind of steps in between. Um , now I think that what we're doing is allowing customers to have that kind of buy the CD kind of experience where we people can bring custom solutions to Sassaafras, uh , bring solutions they've made for products and then allow people to purchase those in mass and to scale.

Alex Shull:

Yeah. That's the idea. And also the to , you know, to bring version management.

Jared Duker:

I want to continue our stories . So Gil and I, had been working on the impact pro project for a while now and we knew that we could copy globiflows. We knew that it was stable at a can happen. And we also knew that we really didn't want to. So we went to Alex that we brought up our problem and uh , it was really his genius. It says, yeah , guys, this is definitely an issue. We , we, I recognize the business case here, but this also has implications so far beyond your just immediate needs. Um, we outlayed a business case and we very quickly realized that yes, this is mainly for us, but it's also a major gap in the infrastructure and with just a few little tools, the power of that Rad platform, which is podio could be leveraged this way. And so we started putting together some use cases and I'm validating what we thought. We knew what we know we needed this tool, but is this something that we want to invest , uh , two years and you know, God knows how much money into at this point to bring to all the rest of the podio community. And so I really want to kind of truncate this conversation and say that after all this time we have are just about to release a this flagship product, which is Sassaafras, which does exactly that. I want to give Alex a chance to talk through , um , what it does and also some of the trials and tribulations that we've been through and why. Um, one, podio was not designed with these features in mind and how it can have them now. So , um, you know, we, we , we've been banding around the office for awhile now. What is Sassaafras and , um , what it's going to do for the general podio community, both developers and users to , uh, bring this platform that we're also invested in into an entirely new universe of scalable enterprise based solutions. So at its core, what is it that Sassaafras does

Alex Shull:

Well Sassafras has a few, different pieces that are important to keep separate in part because they were designed to work independently, provide value independently and um, at its core Sassaafras is about managing the solutions you build in Podio, which could be comprised of multiple workspaces , um, deploying them, patching them, hooking their events back into a single flow engine for all of the deployed instances, and also some additional features that we needed to develop specifically for our clients related to aggregating data across deployed instances. So edit. Go ahead .

Jared Duker:

Let's break down what it , yeah, there's lots to break down there. You're saying that I can build a solution inside of podio? Yes . And then come to you and say, Hey, I want you to snapshot this and make me a bunch of copies with all of my cross workspace references intact .

Alex Shull:

Yeah. Basically you can log into Sassaafras just like you would log into a tool like globiflow. And so it, you have to be authenticated against podio.

Jared Duker:

So its going to use my credentials.

Alex Shull:

You log into podio and then suddenly you have access to Sassaafras and you can, if you're an admin over the spaces, then you can go click the spaces that you want to include in a solution and tell Sassaafras to make a copy of the solution. So that's, yeah, go ahead.

Jared Duker:

We need to break down that word solution from podio standpoint of workspace is a self contained unit. It just is, it's a mental construct that we say, hey, this works space interacts with this workspace and it's ultimately meaningless without it. So Sassafras, it's really kind of introducing this concept of a solution to go, these three work spaces are a set, they interact together and I want to call it happy, fun time.

Alex Shull:

Yeah, and it came from your design philosophy of how you used workspaces that we realize that core functionality for a lot of our software required at least two spaces. We wrote solutions that are assembled space solutions, but we , we knew that some instances would require those cross works based solutions and so that that new construct that grouped a set of spaces together that doesn't exist in podio. That's a Sassafras concept and we've expanded it to include some resources that aren't podio, but that the solution once you have it captured is an asset that we store in on our side behind our services that once you have that asset stored, you could in theory go and delete everything in podio and you'd still be able to deploy this as a working solution on podio. So we maintain all the data that we need on our side in order to do, to do the deployment. We are not copying podio side resources, we're capturing all that core application data that shows how those spaces are linked together and we're maintaining it on our side in a way that lets us manage deployments independently.

Jared Duker:

What I've heard you say around the office quite a few times is that we are taking a solution under management. You're going to define what the solution is and then it's going to be by the Sassaafras tool set.

Alex Shull:

Yeah, and that's , that's a pretty new concept. Um, but it is going to be fully integrated into the solution when we're available to for people to try out. But the basic idea is that there are a few event loops that podio at its core supports and they're unbiased. Again, you can listen to any event and do whatever you want response. It's a very flexible person someone clicked on. Yes , it's , that's the way that you can hook things into podio is for listening to those events that have to do items being created and items being updated. Those are the most common ones. But you also have events like an APP has been added to a workspace or an APP has been deleted or how about a field as a field has been changed? All of those things or events that you can listen to you . And so in the Sassafras there are two concepts. One is the management event loop and the other one is the solution event loop. And on the management event loop, when we bring a solution under management, we can actually actively detect the changes that are happening in a space and capture those rapidly into a new version. When you're ready to push those changes out to deployed instances of that solution.

Jared Duker:

Oh I was just about to get into that. It does sound like , um, okay so we have a baseline that we captured a solution and now we're listening to app work space field update links or ties your dev environment if you're used to having multiple environments and so now we can generate a difference file between these two. What is original and what is new and this is what patching is this. This is what we've been working on for so long.

Alex Shull:

So you the on the, on your, in your Dev environment, once you've established which spaces are going to be there , your area for bringing in all that creativity to your , your software. If that, when that event loop for the management is running and you say, I liked the status, it's in, now it's working, all my dev resources are looking golden, you can capture that. And then you can say, what did I actually change ? Because you've been working on it for days on end . You don't keep track in your head, Exactly. And the rather than listening for every single one of those changes, which would be a strategy for doing it. What we do is we capture it at the state when you're ready and we do a compare between the previous version and the current version and we'll show you exactly what needs to be changed in a given deployed instance. And in fact, this is something that Gil is really excited about. Um, this is something we can actually deploy on an ad hoc basis to solutions that aren't under management. If you have, for instance, this is a different use case, I don't want to get too off track, but the same tools, if you have a new version of a solution and you have a customer, you have a deployed solution but you haven't talked to them at two years and suddenly they want some updates, this tool will actually let you present a comparison between that space in your local space so you can effectively bring them temporarily under management in order to do that comparison, deploy changes and then let their space go back to whatever it was doing before. So that's, those are features that I think , um, are...

Gil Roberts:

Thats a great tool for agencies that are doing one off. You know, they're not doing product kind of what , what Sassafras is mainly for hundreds of the same type or core and customize to some of the other strategies you've talked about. But this is , if you're doing one off installations, this is a great way to what I mean from, from what I hear that and go , I can show what I'm going to change for them. I can give them estimates of what I can change. This is exactly what you expect

Alex Shull:

and you can verify the changes afterwards by doing a comparison between what's deployed in that version and you should expect no differences. So you can also make sure that it's at the correct version. Um, that's a , a solution that I think it could be exciting to a lot of people who are totally happily happy with globiflow, procfu or whatever and aren't interested in using our flow engine...

Jared Duker:

Well, we got to get into that, right now.

Alex Shull:

Yeah. But my, my only point is that this, this is a tool set that really can exclusively manage deployments and patching, you know, if you, if you're not interested in the other pieces.

Gil Roberts:

So let me, let me , uh, just as a good pen point for a summary. So basically what Sassaafras can do is look at a solution, bring the solution under management, deploy copies of , stamp the cds out and everybody gets a, it can also then under that solution management push patches, preferably from like a Dev environment out into the production world. So that after you've sold everybody these deployments, you can then push version updates for either a subscription if you're monetizing that way or people can buy updates or by continued customization.

Alex Shull:

Yeah, that's that . That's all true. And the , the core capabilities are implemented as services. So exactly how we wire them up is the , that's coming from our use cases. But if we have people come to us and have a different idea of how to use these underlying capabilities, I mean, we, we'd love to hear from the people out there to see what they need because these are, these are , we can borrow these up pretty flexibly. And , um , the more we learned , we realized that there were some other people who use podio a little differently than us and we want to support them as well.

Jared Duker:

Absolutely. But I think we do have to give credit to a Mr. Fuse and investorfuse because they were one of the people who pioneered this model and we learned a lot from them. Mostly, about the problems that they were encountering. And that gave a lot of validation to the , the use case that we put here is we saw that what they did deployments fine, but patching was just such an issue that they encountered

Gil Roberts:

I remember talking to very early on. Uh, Dan was very , uh, towards over at investorfuse is very gracious with his time. I shout out to them, great product over there. Um, and they , they told us, hey, you know, once they suffered all the way to about a hundred spaces before they moved to , to a flow engine, that was their first big move just because of the issues with having to do manual copies in a multi workspace environment of Globiflows in the halfs and , and, and just the, the issues that they had. So they, they kind of gave us a heads up when we brought Alex on. That's when we were in, we were in the real pain stages

Jared Duker:

all the way to the end. They were still, anytime they wanted to make a change to their template retroactively, they had to patch by hand all spaces. And so that passion capability we quickly realized was going to be absolutely essential for maintaining an enterprise level solution like impact pro. And uh, um, now that is working fully for the last couple of months management of that solution has gone from an absolute headache to an absolute breeze.

Alex Shull:

Yeah. We actually have , uh , this, this client is actually deploying their own copies today. And so that's, that's a step that has kind of proven that it's not a , it's , it's a different , um, it's not out in Beta. That's, yeah, this is a , um , a closed door sharing, but we actually have people giving us feedback , um, to the, for deploying those copies.

Gil Roberts:

Some ex explanation here at Brick Bridge. We do a lot of code development models, so we may be kind of a vendor or contract for hire for somebody looking to create a solution. We've proposed a podio platform for the product , we've created the product for them and then they have their own customer sets. This was very important to them because since they are servicing customers of their is their friends, right? They built this for themselves, took it out to their friends and are receiving revenue stream to that. Um, they want it to be like, how do I sell copies? Right? So we needed to, to open the door for them to, that they're not always dependent on us with a lot of, and quite frankly, we know we're not interested in, in running their customer service department. Right. So it , you know, that allows them to do that as well as they asked us. Again, the use case for patching is if we need updates because we do, this is a government related software, things change. Uh , and those have to be implemented. If we have hundreds of these workspaces, we're not going to have someone sit there and change all that. So it was these, this kind of necessitated that the birth of Sassaafras outside of her own desires not to have to do any of this work either. Well, let's move onto the next one. Let's talk about this custom flow engine. So now we had to attack the Globiflow problem.

Jared Duker:

Yeah. I think we , uh, we should talk a little bit about the remapping service that you put together as our initial on this cause this was a lot of fun. Um, now that we were able to deploy and to patch deployments, there's all the back end wiring. I mean a podio without Globiflow is a , is a very limited solution. We want to run automations. And unfortunately when you copied a solution that had crossword space, links in globiflow, just about everything broke. I mean it was, you had to more or less rewrite the entire flow, including if you were moving items between apps. You had to remap all the fields. It wasn't just, hey, no know this happens to this one. No, you were pretty much dragging and dropping from the very beginning. And , uh , Alex came up in a very, very, very quick time frame . I'm pretty novel solution for that. Um, in a remapping.

Alex Shull:

So the, there , there are two sides of this back in the day I put it a lot of effort into actually rewriting the he flows where you bet we are back when we would export them, I would load them into Sassaafras and then after deployment we could rewrite the globiflows and then import them back. And we can do that today and it still works fine. But um, that, that is actually the origin story of what you're referring to as the remapping. Because in doing that, what I was effectively doing is saying, okay, we have a Dev copy and we know the space ids the APP ids, the field ids , all the details from podio prospective of and interact with the solution and how to listen to two events coming out of it. When you create a new deployment, all those ids change. And so what I did is I designed a service that we call the Sassaafras dictionary that maintains a mapping between a deployed solution. And the reference fields in the Dev copy . So when you're designing a flow to take something from intake and to look at the date and then send an email if the date is three days old or something like that, you're , you're referring to fields that have , um , ids that are unique per deployment

Jared Duker:

and you can see this on the developer tab.

Alex Shull:

developer tab to your field ids. You look, you go to the developer and photos , you'll see space id, APP id. Those are very, very unique per deployment. And so what we do is we create a key mapping where every single field has a unique name that is within the solution, meaning that it's the same name for every deployment. But from, if you go into the first deployment and you resolve that key name, you pop out the ID and you see that it's deployment as actually space id 145 so whatever it is , discrete name. Yeah . Instead of this solution has, once you capture a solution and Sassaafras, all those key names are generated and when you deployed it, it creates a map for that environment to resolve. All those key names to actual ids . And that's how we're able to listen to events from a single flow engine for any deployment and map it back to the correct podio space. And so, and that, and that's exactly how we were rewriting the globiflow

Jared Duker:

So we were able to export our flows, run them through a process that you had and we would get , uh , flows back that we could reimport it , they would map in perfectly. Yeah , it was great. But this was the long way from being the kind of push button deployment service....

Gil Roberts:

That took us three or four days a copy down to like three or four hours. But yeah.

Alex Shull:

But I think when we really pushed us down the path that where you're really talking about now, and he's the one we had to do external API integrations. As soon as we had to start calling these , um, slightly antiquated government web services based upon podio events, I started implementing , um , solutions in AWS lambda. And once I started implementing solutions in AWS lambda for managing these API interactions, it really opened up the , the vision for the flow engine where when we listen for events back on Sassafras, podio, I don't want to get into into the technical side. When you're listening to the web hook events, it gives you minimal information. And I think that's, that's a good strategy. It's pretty safe. Um, but if you want to have a flow engine that understands the context, you have to have a way to map those web hooks information and then you have to have a way to map it back to the , um, the solution. Make sure that there's a correspondence between the version that's deployed and the version of the function that you're running. And that's what the flow engine results for us. And so in theory, we could have multiple versions of the same solution deployed and we would map all the calls to the correct versions of the functions on the back end . That's , that's what the, the engine satisfies for , for us.

Jared Duker:

And I want to call this back just for a second. So why this is so critical, which is even if we developed front end patching that would uh , rename all the fields in a , in a defined solution, all the globiflows are ultimately independent. If you open up that giant tree that we all look at, every one of those globiflows, just like every one of the apps is ultimately unique. So a front end to patching solution that doesn't also patch all the flows is a non viable solution. It's incomplete. And so what we ended up having to do is if we want to make a change, we would have to go not only fix each of the apps manually one on one, but also go and fix each of the flows and or copy a new version. But Hey, copying is going to go right back to that cross workspace instance. So patching is really not invites and non viable solution. We came to realize , uh , using globiflow as it currently exists. It because it is, it's, it's a house of cards. You've got a wonderful front end to construction. Yeah, you're stuck the wiring or into the bath. But it's not part of any standardized system. It's hand placed wires .

Alex Shull:

Well you know even if , if , uh , globiflow added some services to let people , um , export an emperor report , um, their flows, which I think would be probably good for a lot of people there. There are probably more than business who would be interested in doing that. But I think that the um, the grant , the way that flows or export it today , um, the current export format is not intended to , um, map things onto multiple solutions. It, to be honest, globiflow is not intending to be with Sassaafras. We had globiflow today because it does things that we can't do effectively on Sassafras. But then when you Sassaafras things for things that we can't do at globiflow . So it is, it's a, it's a what I consider a correspondence problem.

Jared Duker:

That's what I should be clear. We use globiflow every single day, even on mature solutions that are running completely. Our custom flow engine , we'll go into globiflow into one off customizations at customer request . Hey I want to send this text message. Well we don't, we just, okay. I'll get in globiflow and I can do this in 30 seconds.

Alex Shull:

Yeah . That's the way you provide effective value for customers is not overcompensating with simple things like that. So it's great for exactly that kind of value I think. Um, and and likewise, like I mentioned earlier, it is definitely in the , um , the plans for Sassaafras for us to be able to deploy solutions and build web hooks into other back ends. If you want to deploy a solution and you want to wire up the globiflow, we want to support that. If you have your own custom back end, we want to support that as well. We think these tools, the best thing about these tools is that you do get to, you know, figure out how to compose them and they're um , they're flexible in that regard.

Jared Duker:

And it allows someone like me to build very professional grade software without writing a single line of code. And I'm always advocating for preserving those capabilities inside of the Sassafras Platform. Because right now we're using globiflow is a prototyping engine to define customer requirements, but we're ultimately transferring those flows onto the Sassafras side because of that ease of patching, which is if I need to make a change to a flow, I don't have to go through all 79 installations in make the change, I can make a change to one AWS lambda function. And it percolates to all of the environments that are hooked to that. And I can, we, with our Dev prod split, I can develop and test without affecting my current customers and be confident that when we deploy it, it's going to be exactly the way I wanted .

Alex Shull:

Yeah. And then there's, there's other features that I , I , we have in the, on the horizon that were planning, that are enabled by the way we built , um , Sassaafras. But there's no reason to talk about those until we get our core product out there. But , um, it's interesting kind of things that we did encounter, um, when we were building out the core solution. There are a lot of challenges that you, you have to decide how you're going to approach security. You have to decide how you're going to address , um, performance concerns cause you, know podio does it all is isn't perfect on availability. They're improving their , their infrastructure and it's , um , totally meets our needs. But at the same time we put in some features that make , um, the day that even more redundant recoverable and usable, even if there's some podio unavailable and availability rate limits is another thing we really had to be , um, we, we had to learn about how to reduce the number of podio API calls we were making unnecessarily. And along the way we've optimized Sassafras to minimize the number of times it has to authenticate and minimize the number of calls and makes, cause we have a , we have a podio cash now.

Jared Duker:

Why does that matter? Why does it matter how much time, how many times did he call?

Alex Shull:

Well, it's a performance issue from the standpoint of computing, but it's also cost. I mean, podio charges you for that and they should, I think they, that there's , um, it's, it makes sense because you can limit the inefficiency of your code by writing better code in Podio says, look, don't call us anymore than you need to. And so that it's the , it's the same thing we put in those features in Sassaafras to say if you deploy things on Sassaafras, we're not gonna call podio anymore than we need to either. So it improves the performance and reduces , um, you know, the number of potential errors and everything.

Jared Duker:

Okay.

Gil Roberts:

Excellent. Let's talk a little a bit about the caching part. You said about the performance and then podio on availability with some packages a little bit .

Alex Shull:

So when you are dealing with events that come out of Podio, the core piece you get is an object Id and you want to perform some action on that depending upon what the event is and your solution. Well, you need to retrieve that item at that point. And so you have to make a call to Podio, which is a get call, you know, get calls it the cheapest calls for Podio is perspective because they're just going to serve it out of their front side cash. But at the same time, if you've gotten at once and then you're going to perform five actions on the same item and you have those items , action is split into 500 flows. But the item hasn't even changed. There's no reason to call podio five times. And so we have a cache that was when we'd get that first change, we capture the changes in our cache and when the flow is come to retrieve that item, they're just pulling it out of the cache. We don't have to call podio at that point anymore. And so that reduces the number of total calls that you made for a flow that would,

Gil Roberts:

so basically we can take a copy of that item, manipulated and then push the update. The final change back to podio.

Alex Shull:

It depends on what you're up. Sometimes you're not even talking about updates. So I'm just talking about if you're, you're responding to an event. You have to look at the item. Likewise, if you imagine , um, that you have a scheduled that that's going on and you want to respond to changes that have occurred in podio in the interim, well there , if you are fire that it satisfies , has a scheduled event so we can just set up a cron job like others, it's a little bit just set up and when it runs at that time, if it needs to pull certain items out of Podio , um , those items can be in the cache . And so it doesn't even need to call podio at all. Even though this is a , a, you know, a flow that depends inherently on podio data. Once those events are available, the Sassafras and it's going to cache those item changes and make them available to any flow that runs within this , as for as engine. Interesting.

Gil Roberts:

Well, what , uh, what kind of plans for the future features do we do? We have in the works with what's going on in your brain there , Alex ?

Alex Shull:

Well there, there's a lot than Jared striving that we're really trying to make sure that we get all of the Ui ready to meet the um , customer experience that we think is really gonna , um , make people happy. Um, and that's really forced me to put a lot of focus on how we're managing credentials. We want to be able to bring someone solution and either leverage multiple organizations or a single organization, different kind of scenarios that we realize that other people don't do the things exactly the same way. So we have a lot of focus on improving the management of credentials across accounts. Um , and logging is another area that is interesting to us because we've seen a lot of people report how they want to be able to pull logs back into their infrastructure. And we do a lot of logging internally and so we were trying to make sure that , um, the containers that we're using to run code within , um, lambda do a good job of creating discrete logs per solution per client that can be exported if our clients want that. That's a , that's an area that we're working on right now. Architecture. Um , well it's a few other ideas in the works . I don't want to give away to much.

Gil Roberts:

We'll save some for the, for the next update on this. We need some more case examples. So for our listeners out there, we'd like people to actually reach out to us. We don't have anything that's commercially available yet. However, we are starting to onboard some Alpha and Beta clients, Alpha clients for immediate use Beta clients for when we get something that's a little more like when we get the Ui built, which I'm working on and something that's a little more approachable. But if you have a solution or a scale product or looking to scale product and you're already running into this barrier and you need to be able to solve this, please contact us immediately. We are now onboarding clients , um , at a case by case basis and we're also wanting to understand some of the examples. So maybe it's something that you're interested in but not need immediately. Do contact us anyway . We want to understand how your using podio, what you're looking at when you, when you talk about building a solution or if you're an agency that has multiple clients, how you're managing their versioning and packaging for the custom solutions you're building for them.

Alex Shull:

We'd like to hear challenges because I like to hear from someone who says, I need podio to do something that I don't think podio can do. That's what I want to hear. Because people are often surprised at what you can do with podio. And so I'd really like to be challenged.

:

Yeah. So that, that would help our future expansion as well. So we're challenging our listeners here . Are you listening in? If there's something that you want to be able to have podio do, you're working with the solution you want to be able to replicate, you want be able to patch your , you're facing some of these challenges at scale, whatever that means to you and your solution or solutions. We want to hear from you some do reach out to us, you can, contact us on our Facebook, Twitter, linkedin. You can also send a podio message or an email to podcast@brickbridgeconsulting.com uh , we need to hear from you why you're there for those that may , this may not tickle your fancy as much. We still are looking for those podio gaps or get those in as well. We've got another solid podio gaps episode coming up here shortly. I think we'll go ahead and sign off.

Jared Duker:

Thank you very much.

Alex Shull:

Thank you.

Gil Roberts:

Alright. Excellent.