All EventsReplacing Shopify in 4 weeks with Hasura and React
WEBINAR
Nov 10, 2021
9 AM PST- Cajoo is a French direct-to-customer delivery app that promises delivery in 15 minutes.It is one of the fastest growing startups in Europe that recently raised 40M$ in funding
- They’ve replaced their ecommerce backoffice (Shopify) with Hasura and a custom web interface to provide faster response time to their users while improving the tech team’s velocity.
- It’s worked so well for them that they then went on and replaced other pieces of their stack using the same architecture: their Warehouse Management System as well as Courier Apps teams have followed the same patterns.
- They’ve replatformed their customer & courier mobile apps and their warehouse admin app to use Hasura with React Native powering the front-end.The whole project took just four weeks and a team of 3 developers!
- In this webinar we speak to their CTO to learn about their migration to Hasura and how it has allowed them to scale fast. We’ll cover:
Why Hasura:What led the team to choose Hasura? What problem were they trying to solve?- Architecture:How did they go about planning the replatforming, and what lessons did they learn?
- Observations from running Hasura in Production:How has using Hasura impact their business overall?
- What’s next:What do they have planned in the coming months?
VIEW RECORDING
Jesse
Hello everybody, and thank you for joining us today. This is our first customer story slash webinar presentation. It is going to be a fantastic story today. I actually am really excited about this one. The whole piece is just fascinating, interesting, so really excited to see what's what Jeremy's brought for us today. Jérémy Gotteland, you're going to be giving us a breakdown of what the title says, replacing Shopify in four weeks. Why don't you let everybody know who you are, the company you work for, or I shall let do that in slides, but I'm going to say you've got a presentation. So at this point, I'm going to actually just hand it over to you, and let you tell us your story, and then if you have questions in the chat, definitely hit us in the Q and A, and we will get to those by the end, but Jeremy, stage is yours.
Jeremy
Cool. Thanks a lot, Jesse. Hello everyone. Today I'll go over some slides I have prepared to present you this crazy adventure we embarked on, at the beginning of the year. You should be able to see my slides. Jesse, can you just confirm that you see them?
Jesse
Yes.
Jeremy
Sounds good. Cool. So this is the crazy is the story of how we replaced Shopify in four weeks, at the beginning of this year. So I'm Jeremy, I'm the CTO of Cajoo. Historically I'm a full stack developer, mostly specialized in React native, React node JS. One thing that is interesting I think to mention, is that prior to starting Cajoo, I had no previous GraphQl experience and that's a lot because now we use GraphQL everywhere, and I think thanks to Hasura, the ramp up for me and my teams was super fast.
Jeremy
So what is Cajoo? We're a grocery delivery company. So we deliver groceries, intensities in France, within 15 minutes. So we're part of this whole Q commerce, quick commerce wave of companies. We do that by, so we have actual warehouses inside the cities. We not quite like Uber Eats or Deliveroo that go and pick up groceries at an existing store for you. We kind of recreated the store, just without the staff, so we just have stuff that prepares orders and then hands it over to riders. You can see one depicted here, that delivers it at the client's home, and we do that within 15 minutes, to provide a lot of convenience for our users. So here are a few screenshots of our app. We have a wide range selection of product. We have fruits and vegetables, we obviously have cheese, because we're in France.
Jeremy
That's basically what the business does. And so we started at the beginning of this year, actually. The company was created 10 months ago. There was a lot of competition in this space. Lots of companies popping up with the same ID all around Europe. There was nothing in France, and we then started to pitch on the venture capitalist and we realized we needed to start very quickly, to get to market before the competitors arrived. And so with that in mind, we wanted to start as quickly as possible, so we went for the MVP. I built the initial version of the app in React native, in about four or five weeks. And for the back-end, I decided to go for Shopify, which most of you probably know already, which is a e-commerce back office. I just used the back office part.
Jeremy
So it's using the storefront GraphQL API that Shopify exposes, to connect my mobile app too, and I used that to get started super quickly, so I had my team create products, their images, their prices in Shopify, and I would fetch that in my mobile app, so that allowed me to focus on building the app, and releasing it to market as quickly as possible, and not focus on the back-end too much. So basically the initial version of the architecture for the product that we launched after five weeks of raising money in January, looked like this. So on the left, you had the React native [inaudible 00:04:41] It was connecting partly to Shopify that was using as a e-commerce back office auto management system to fetch all the products, all the products information, and also create orders, apply discounts, vouchers, et cetera.
Jeremy
It was connected natively to a warehouse management system, that's the beauty of Shopify, that it connects natively with a lot of tools on the market now. So the warehouse management system is the tool we use for managing the stock, the virtual stock in the warehouse, to say that we have X quantity of Coca-Cola and it's in this location, so that when the order arrives, the pickers know where to pick up the good. And we also had for the couriers white label mobile app, as well as a back-end with an API to create jobs and listen via webhook to the rider location. And so I just created this mini server initially, with NestJS and Heroku, to link all services that were connecting via webhooks and APIs, and I was doing the authentication, the user part with this as well, that's why my app was connecting to both. So the back-end piece, this is a big block, but actually it was very small. It was just basically forwarding information from one system to another, adding very little business logic, but that allowed me to start very quickly. And then, we grew very quickly.
Jeremy
The whole country was in lockdown at the beginning of this year, and so people were at home, they didn't want to go to supermarket, and so we had very quickly a lot of orders coming to the platform, and that was great for us, but that meant we bumped into some issues with the initial architecture, namely, well, I had to kind of bend a bit what Shopify could do initially, in order to make it work for my use case.
Jeremy
Shopify does not handle very well different stock quantities per warehouse, at least on the client side, so in order to make it work, I had to embed all the warehouse stock for all of my warehouses in each product's metafield, which means that I was doing all the fetching for all my warehouses, and I was just doing the filtering in the front-end, so as you can imagine, as the number of warehouses increased, that the volume of data I was fetching increased, and it got slower and slower, and it was just going in a bad direction. It also offered limited flexibility when I wanted to get out of the features that Shopify gave me out of the box, so it gave me coupons, gave me all the management refunds. That was very cool, but once I wanted to add, for example, favorite feature, means I had to work around the API, deal with the rate limiting, and I was just building technical depth, basically on top of this third party platform that was not mine, my [inaudible 00:07:52] point.
Jeremy
I was just working with something that I had no control on, and to me that didn't feel like the recipe success. So I went on and looked for an alternative that I could have more control on, and that would fulfill my requirements, and while browsing hacker news, actually it's around that time that the 2.0 engine was released, and so I started looking a bit more into it. It provided a lot of features I was actually looking for. So it provided an instant GraphQL API out of a data model I would provide on a database, plus aggregate, plus subscriptions out of the box, which was really handy, and as you can see later, I'm using it in the app. Likewise, the authorization part with permissions and some presets also came out of the box.
Jeremy
So that allowed me to create a role, anonymous role for everyone not being logged in, and then a user role that would only fetch information relevant to them. It was super simple to do, and I'll also show you a bit about that later. It was also providing events and basically triggers retry logic out of the box, and it was similar to what I did with Shopify. With Shopify I was configuring webhooks whenever an order was paid, while, you'll see I had to do the same thing here, and it was super straightforward, and also it was super easy to use. It was cloud based, so I didn't have to set it up again on premise, but it was still open source, so I knew that eventually I had more flexibility over it.
Jeremy
And so I was like, okay, because I had another developer joining me back then, we thought, okay, this is what we need, and the volumes were increasing, so we were a bit time constrained and we thought, okay, we need to go fast, and use that to replace our current architecture, before the user experience is too bad, and then just start losing users. Looking a bit more at Hasura, it was really fitting in the architecture that I wanted to put in place, and that was even more obvious after I read the 3factor, the app website from Hasura, that gave a few examples what use cases could Hasura provide, while the [inaudible 00:10:36] one is typically my use case. So I have my app fetching data from database, placing orders, and whenever an order is made, triggers plenty of events that are listened to by individual routes, that do individual things in response to that, asynchronously.
Jeremy
And so I moved away from Shopify and I replaced it so very quickly with this architecture. So as you can see, I moved away from Shopify. I used Hasura on an RDS database for order management system. So with orders, coupons, products, categories, everything that was managed in my app, I plugged a custom React interface on top of it, and that was super straightforward after I created my data model and plugged Hasura on top of it. I'll show you later what it looks like. And the warehouse management system, unfortunately, was not connected to it out of the box anymore, so I had to rebuild the connections to that from my API. I was then doing the stock updates in the order management system. So that's what I had after four weeks, and so what does that mean? What did I change?
Jeremy
Basically, the first thing we did with Antoine, the developer I was working with, was to create the data model, so we provisioned RDS database. We use this tool, dbdiagram.io, I think it is. It's a very handy way to kind of ping pong, and brainstorm over a data model. So we spend a few days actually I think you should not hesitate to spend some time on the data model that's going to be the base basically, on which your GraphQL API is generated by Hasura, because it's something that's hard to come back on later. So we sat around this for a few days. We got something that we were happy with, and then we just connected Hasura to it, and so it generated all the GraphQL endpoints to do the read, write, the CRUD.
Jeremy
And then that was the first step. With that, we could already build the back office. So the back office that we called Cajoo Shop, which is just a copy. We were not very original on the name, which is basically a copycat of the Shopify interface, plus a notion of warehouses that we have that they don't really have, and just with the GraphQL API that was exposed to us, we could staff a single developer, just focused on building this, without having any interactions with any back-end team, and so that allowed him to do all of this with the read, write search pagination, whatever, in just 10 days. Using React Apollo for the state management and material UI, very popular React component library.
Jeremy
And that came pretty much for free. Similarly, and I talked about it as well, the aggregates and permissions that Hasura provided were helpful for the refactoring. Here a few examples. So on the profile page, we have a simple line of text that shows the number of orders. Here we don't have to get all the orders and do the count in the front-end or create a different route. We had the aggregate generated by the API out of the box, so we just use that. Similarly we had the list of orders just filtered for the users. In the profile page, you can see all your past orders. So you fetch the orders, but just for the user.
Jeremy
And that's done thanks to permission, and the permission that you configure, it's basically one click. You define your role user in the back-end, and you add a pre custom check before the select. So here I will check all the orders, for which the user ID equals access rider ID, which is something I have in my headers that identifies my... In the JWT token that I pass the headers, that uniquely identifies my user. That allows me to not have to play with the user ID in the front-end, or have that logic that would do that in my resolver, get that user ID information from my JWT token. Hasura just does this with one line, and so all discount and all this fetching of orders, is pre-filtered on the user, so I don't have to worry about it.
Jeremy
That was super handy. What else? So that's not something we released as part of the launch, but those are features we added in the weeks after. So we had this order again feature. So the order again feature was super easy to build with relationship between the orders, their items, and so you could get the users past and then get the items in them and just say, okay, those are the items that you last order, so if you want, you can order them again. And here are favorite products feature, we just had to add the relationship between the user and the products as favorites, and then a simple join was enough to get that information. So that was super easy to do, just a few weeks after releasing. And for the back-end part, a bit of the logic I was doing in my API before. Well, when I said the event triggers used them extensively, I think I was just replicating basically the Shopify pattern, but I had an action on Hasura, that would create a pending order, and then let my user pay.
Jeremy
Then I had a webhook listening to Stripe payment success. Whenever that's done, I update the payment status of the order to say, okay, the order was now paid by the user, and then I had a few triggers basically on the order table. So when an order is paid, then what am I going to do? There's a series of actions I need to do. I need to do them asynchronously. I don't really care about the order in which they are made, but they need to get done. So I need to first notify the client via email that he passed an order, sending him the receipt. We notify the warehouses via slack, we communicate with them via slack, so notification was sent to the warehouse to let them know that there was a new order. Send order to warehouse would send it to the warehouse management system, that's what Shopify was previously doing itself and I had to redo myself. And then send order to the delivery management system, to the rider.
Jeremy
And so I just had to write a bit of that business logic in my server that I showed earlier, but setting up the triggers was just a few minutes for each. In the end it sounds complicated, it sounds like Shopify is a big tool. Actually, there was not that much logic. Building a back office like Shopify, there was mostly reading, writing, product information. Pretty straightforward when you have an API that allows you to do CRUD, so we just needed a team of free people. One that mostly did the provisioning of the database, with which we brainstorm on the data model. Refactored the mobile app to use the API and implemented a few back-end functions, namely the payment ones.
Jeremy
One that was focused on rebuilding actually only the connections with the warehouse, and one that did the admin, and just with that, after one week of intense quality assurance test, we're able to release, so progressively, because we had with the mobile app, a new wave of users that were connecting to Hasura, and the remaining ones connected to Shopify, so we had to force the update, and for a few days there was a bit of data migration to do, but roughly it was pretty smooth, and over the course of, I'd say one week, we had migrated all the users, and everyone was connecting to Hasura, and we had no one passing orders in Shopify anymore.
Jeremy
And the benefits were clear. So first we went from a loading time of, it was getting to almost 10 seconds at the end, because as I said, all the warehouse product, like stock information was stored in each product metafields, so I was fetching all of that, and it was not sustainable. And that went down obviously to less than one seconds, since I was doing the filtering in the back-end. The pricing, I did not mention it, but Shopify, especially with Shopify plus that I had to get, to get increased rate limiting, better rate limiting on the API, and some additional features with the storefront API, was 2000 plus per month, and that went down to roughly a hundred plus dollars initially with Hasura. And obviously the team velocity, because with just a team of full stack developers, actually mostly front-end and Hasura, they could spend less time just building [inaudible 00:22:33] I'd say resolvers that just read and write data.
Jeremy
And instead of that, they could focus on delivering value much faster. Moving on, because I still had a bit of a Frankenstein architecture, where my mobile app was talking to my API and also to Hasura, because I was mimicking the Shopify model. We got rid of that, and so we just used Hasura in the front-end. The front-end as a front, that's the only endpoint that my mobile app would talk to, and he would do all the talking with the API.
Jeremy
I eventually moved away from this Heroku, NestJS on Heroku. In the end, I was completely convinced by the whole free factor app architecture paradigm, and so we moved everything to AWS Lambda. We already had the database on RDS. We actually had a lot of startup credits, from AWS, which was very handy, so we moved away from Heroku to that, and it was perfectly fitting the paradigm, because then I had each function, for example the notification via email in one Lambda function, called by one event trigger, and I had one relationship between the triggers and the Lambda, and that was super clean.
Jeremy
That was still connecting to my delivery management system and warehouse management system initially. And then I liked it so much and basically the whole team liked it so much, and similarly to what we had to do with, Shopify was great initially to get started, but then it showed limitations, so we replaced it. Those two systems also were third parties and we also eventually realized that they would not entirely fit for our needs, and so we replaced both of them with a similar pattern. With Hasura's, and a front-end similar to this one.
Jeremy
So either for the warehouse management system, it's a back office, quite similar to Cajoo shop actually. Using the same base of code, and for the delivery management system, there was a mobile app, which we rebuilt with expo, so React native as well since the team was already familiar with it, with the main Cajoo app. And that's it. So this took a bit longer. The initial migration to Shopify took four weeks. This project actually here also took four weeks for another reason, but we glad we did it, and this one took much longer because the business logic there is quite intense. And yeah, that was it. Then perhaps we have some questions [crosstalk 00:25:53]
Jesse
Okay. I've had a chance to see that story several times now, so I think it is just really fantastic. A couple of things that stood out to me, and then I want to open it up, some of the questions that we're getting, rolling in now, maybe if you want to stop sharing your screen there. Just get that, so we're both visible. You talked about basically from the Shopify to Hasura was four weeks, and then you talked about creating the different admins. How long did it take you to go from Hasura to Nest, and then Hasura to serverless? So how long did it take you to replace your Nest service, with a serverless architecture?
Jeremy
Yeah, we did it over the course of a few weeks then. It was basically more refactoring that actually like a pure necessity. So we migrated endpoints bit by bit, slowly away from Heroku, but I think that took us a bit longer, maybe eight or nine weeks. We were migrating bits by bits, especially the payment endpoints. We wanted to get them right, so yeah, it took a bit... Because we had to build features obviously. There's always the need of building really quickly while performing this refactoring.
Jesse
Yeah, that's great. Now, because I was privy a little bit to some of the previous conversation, what was one of the motivators of why you switched to your own warehousing solution?
Jeremy
Yeah, the warehousing solution. So as I explain, we manipulate fresh products, high rotating products. So fruits and vegetables, frozen products, fresh products like yogurt, et cetera. There was basically no warehouse management system in the market that would be great for those use cases, so we got something off the shelf initially, but then there's plenty of information that you need to input when you enter a product, such as when it's going to be due, et cetera, and we wanted to add some logic to say, okay, you entered some four days ago and you said they were going to be due in eight days. Be careful, you need to get them out of the location, two days before it's going to expire, et etcetera. Big retailers have that kind of system, but they built them in-house.
Jeremy
And so for us, the decision can really quickly that we needed to in-house as well. To have more flexibility, and also for investors, it's really something we pitch. It's always something that they ask me, when they look us, it's, okay, what do you have in-house? What did you build in-house? What do you use a third party for? Compared to what your core business. For us, the business is storing fresh products, and delivering them. So it makes a lot of sense that, that part, the delivery part, obviously the Shopify part, we build them in-house, whereas we still use other third party tools, like the CRM or whatever [inaudible 00:29:25] to replace yet.
Jesse
Yeah. Having your service dependencies, things that are core to your business being fully under your control, has been a competitive advantage, even from an investor perspective, was a big win. Also, you told me that with the delivery service, with the delivery tracking, that was a situation where this was an exposure you had. Do you mind sharing about that?
Jeremy
Sure. So yeah, I said we had to replace it in a rush. The reason for that is that we were using this third party tool from Germany actually, and we realized and they realized, and I think everyone realized, that a competitor actually based in Germany was using them as well and actually had some kind of deal with them, that they had not been super public about, and so the competitor was paying them much more money than we did. They ask for custom development, et cetera. So they put a bit of pressure on them and we're on a monthly rolling contract, and so basically they told us in four weeks, we shut you off. So obviously that's software that's key to our business, because it's the app that the riders use all the time.
Jeremy
And obviously if it's off, we cannot operate. So it was during the summer, when the sun was shining, well, we, we went back to the inside and so yeah, we had to build the React native app. We used Expo, which saved a lot of time obviously, but then similarly, Hasura saved us so much time, whereas if we had to build the whole thing, the all back-end, at least on our own, and we already had like the serverless pieces, so it was just adding Lambda functions, creating Hasura, like I said, defining the data model, setting up Hasura on it, creating the right triggers, and then the mobile app would just connect to it.
Jesse
Yeah. I like that [crosstalk 00:31:34] sorry.
Jeremy
That was four weeks on the clock. In the beginning of August, they said that, and they say September 1st, it was off, then on September 1st it was not working, and so on August 30th, 20th, 30th, we were using our app. The design, I wouldn't show it here, but it was functioning, and actually our riders told us they like it even better now, and it's a competitive advantage. The investors like the fact that it's entirely in-house, no one can show this off et cetera.
Jesse
Yeah. That's really a really an impressive [inaudible 00:32:13] going from ticket to tracker, in four weeks is something. Something that I kind of picked up on in the storyline too. So you started with the first transition, where you just kind of were essentially attempting to replace Shopify with Hasura, and then you sort of realized there was a different architectural pattern to adopt there, because you could make it a bit more easier or simple to maintain, going full serverless. And Then you actually scaled up the amount of time you spent overall, because you ended up front-loading a lot more architecture time with your warehouse tool. And it's something that you mentioned to me as well, is that when it comes to Hasura, a lot of the time that you spend actually ends up being the thinking part of trying to figure out what does the design of your app need to be, so that you essentially can just almost plug it in and go, because it maps so cleanly to the architecture you diagram in your head.
Jeremy
Yeah, and as I said, the dbdiagram tool is not something we use and share across teams, and that's something that the teams use a lot, to think about, okay, what's going to be the relationships, especially when we model the delivery bits, et cetera, and all the relationships, and when you want to group all those together, et cetera, so it scales nicely. So that part is super important. So don't hesitate to spend a bit of time on that. And once it's done, it's crazy to see how full stack developers, but when you look at my slides, it's mostly actually front-end developers that become full stack, because they can quickly add a column or make a computed fields if they have a bit of SQL knowledge, and build things really quickly.
Jesse
Yeah, I was going to ask too. You've essentially replicated your stack now across these three sort of key business components. Have you seen a benefit with that reuse of in-house knowledge gain or even developers being able to be moved between tools? Has that been an advantage? I would imagine so, but I was just curious if you've seen that actually be a thing.
Jeremy
Yeah, I think in your organization, when you manage to have the same technology across different parts, and we try to go even further, because as I said, the front ends, so especially the web, back offices parts, share a lot of code. So it means one developer that's worked on the shop can easily go and work on the hub, so the warehouse management system parts and vice versa, and the knowledge you get from one, maybe you build a component, a handy component, and you can share it. For the mobile apps, they're quite different. So we've not gone that road too much. Sometimes it's tempting to want to share too much, but for this one we refrained.
Jeremy
And then for the Hasuras, and that's something I did not mention here because in the beginning we were mainly playing in the console, but then it's the whole deployment workflow, how you integrate it within continuous deployment, because what worked super well when you're a team of three developers, when you get to a team of 15, 20 plus developers, which we are starting to get now, you need to be a bit more careful, in who can change the metafields, et cetera. So we started committing them and we started to build a whole dev tool chain to work with that.
Jeremy
I think that's something I could cover in an entire different talk because it's something we've discussed a bit as well with the Hasura team, and another team is working a lot on the dev tooling for that, to improve it. So since it's the same technology we share code, obviously the developers are used to Hasura, are used to React native, so they can easily change project, minus getting the domain knowledge fairly easily, but super exciting for them, because whenever it gets maybe less interesting or they think they've covered everything in one area, they can work on another area, but you have to as the team, but I think it's [inaudible 00:36:50] cool for them.
Jesse
That's really exciting to hear, and it's just a great story. I really appreciate that. And we may take you up on the offer to talk about metadata at one of our HasuraCons, so just watch out for that email, but we've got a number of questions here, so I'd like to give the community a chance here to voice them. I'm going to work my way through. There's kind of split a little bit between chat and Q and A. So what we have, the first question was, one was more of a specific question regarding your use of React admin, did you use React admin for the CRUD back-end app? We've been experimenting with it to auto generate the admin dashboard from a Hasura schema. So did you do any kind of automated generation of it?
Jeremy
We tried initially, but it didn't work very well, so we went for a [inaudible 00:37:50]
Jesse
Okay.
Jeremy
I think I see what that person is talking about, because initially we saw a repository where you can have the generation. We had some bit more complex update to do, cross tables. So we needed specific Hasura-like mutations on some pages, which was why it wasn't quite working for our use cases. We didn't have to create additional actions, whatever. We could do everything with the CRUD, but we had to be a bit... The crud, I was really impressed by the [inaudible 00:38:29] allows you to do updates, cross tables, et cetera. You can go really far with it. But then you have [inaudible 00:38:39]
Jesse
There's a question that I'm going to answer myself. So it says great. Any good reference to start learning on Hasura for beginners? I'm just going to say, go to Hasura.io/learn. We actually have a whole bunch of tutorials and guides that are... It's relaunched go couple weeks ago, so a lot of really good resources there, for getting started for beginners, so I'll answer that in myself. What sort of throughput are you seeing now in terms of max number of orders per second? Do you have any kind of before and after ratio? Are you able to answer? Is that [inaudible 00:39:16] Okay.
Jeremy
That's more of the business questions, which we don't answer. [inaudible 00:39:21]
Jesse
You're happy with the performance?
Jeremy
We are very happy with the performance.
Jesse
That's good. [inaudible 00:39:31] Sorry I'm late, but I'm unsure if you address this. Using such a loosely coupled architecture, based on event triggers and webhooks, which delivery guarantees do you have? How sure are you that all business processes complete successfully? How do you handle failures? That's a good question.
Jeremy
Yeah. So I guess there's many places where it could fail. So coming out from Hasura, actually, we've not seen so far events where an order was paid and the event sending basically the information to the warehouse, stuff was not sent. So I'd say in that sense, Hasura is reliable. Then it's the Lambda that's on the other hand, that's my part, and that's happened that it's failing or there's too much throughput on it. For this, I mentioned it in the talk. We have the retry logic, you can retry and you can set the delay between retries. It's fixed, it's not exponential back off or you cannot set a strategy. It's basically you can say you can retry up to 10 times, with this many seconds in between. So that mechanisms has been useful actually, while we were investigating why the Lambda on the other hand was actually either failing, or being unstable. So that's been super nice, and then I guess it's like every synchronous architecture, we don't use event queues, and retries. Hasura does that for us, and so far that's worked well.
Jesse
So I think the answer the other question there about what do you use for queue mechanisms? So you answered that already. I'm going to switch now over to the Q and A tab, so if there's any more questions in chat, they're going to be ignored. So if you have any questions, you need to pop them into Q and A. The question we had at the beginning, so can you use Hasura for data modeling? I can kind of tap down a little bit. Yes, roughly you can, because you can do table design, you can do that in there. I actually do that for some playing around. By far recommend, and I think Jeremy, you'd recommend as well using a tool like dbdiagram, because then that allows you to start off with getting your actual modeling set, then you can do [inaudible 00:42:00] statements, or you can do [inaudible 00:42:02] based table design, inside of Hasura, but would you have any thoughts to add to that?
Jeremy
No, I would say the same thing. I think there are better tools if you want to play around with... I guess everyone has their preferences. For me, I like the visual aspect of dbdiagram. I like the syntax as well. You can copy, paste. In the beginning we actually committed that dbdiagram markdown somewhere, so someone could copy it and paste it somewhere. That's my go to tool.
Jesse
And dbdiagram has an export to SQL for different flavors as well, which you can more or less take over. With date time stamps, you have to be a little bit more specific when it comes to Postgres, but that's more or less, you can copy that over to get started, if you wanted to. Are you using a GraphQL caching system, for your front-end? Any front-end GraphQL libraries?
Jeremy
Yeah, no. So, I think the question is using the Hasura caching mechanism.
Jesse
Maybe that, or are you using any kind of a GraphQL client that does is sort of, like a [inaudible 00:43:17]
Jeremy
Yeah, so we use Apollo cache with different fetching policy, which means we refresh the data more or less frequently, based on how much we need to refresh it. Basically product stock information from the mobile app. We try to refresh quite quickly actually, because the stock can change. And we don't want to show users products that they cannot buy anymore. However, some other information needs to be refreshed less frequently, or you have a UI mechanism, so that you need to pull to refresh, otherwise it's just fetching from the cache. Because there are some features to implement caching in the API, but we are not using those at the moment.
Jesse
Are you using separate Hasura instances and RDS for each of the three systems? One for order one for warehouse, one for delivery, any plans to merge them?
Jeremy
Actually, we had them merged, some of them. The delivery one, and the order management one, with one database and we kind of split them afterwards, because the database was under too much load, from different things, and so it was just not great, so we split them afterwards. The warehouse [crosstalk 00:44:44].
Jesse
Are you using any read replicas, or what size are those RDS instances?
Jeremy
Yeah, I didn't talk about that actually. So on the main Cajoo one, so Cajoo, anyone can download it anonymously without logging in, we can fetch like a lot of data with a lot of drones, et cetera, so actually for this one, we set up a read replica very quickly. And with Hasura, it was super straightforward. We created in RDS and the then added it in Hasura, and that was just a few clicks. Yeah, I did not mention that.
Jesse
That's great. That's a really great pattern as well, for those high read elements. Was there any issues with scaling live subscriptions with Hasura? Real time geolocation sounds expensive. Hello from Mexico. Hola.
Jeremy
Hola. Well actually surprisingly, no. Surprisingly it works quite well. I was like, are you sure subscriptions for every ongoing order? Isn't that bit overkill, et cetera, maybe you can just do [inaudible 00:45:55] and I was with Antoine at the time and he said, no, Hasura is amazing. We get the life subscriptions for free, and yeah. It's still only in France, so I think the most we have in one night, maybe a few thousands connected simultaneously, and with that, we've not had subscription issues.
Jesse
There is a great post written by, I believe it's actually our CEO that wrote it, on scaling subscriptions up to thousands of concurrent requests, if you are curious. IF you search for that concurrent request subscriptions Hasura, I'm sure for you'll come across it as well. So you ended up with React front-end and no back-end? Where did you host everything and how did that affect the cost? We can kind of just [crosstalk 00:46:45].
Jeremy
So technically there was a front-end. So Hasura was doing the backend for basically just a layer for accessing my database, then my API was still, so on Heroku, with an SJS server was still my backend. I then transitioned to AWS Lambdas. It's not the backend per se that my front-end was hitting directly, but yeah, still kind of had a back-end. And then, for the React front-end, it was actually hosted on AWS Amplify. So yeah, I had a CD that was bundling and sending it to Amplify, and that would serve it. And as I said, I had a lot of startup credits from AWS, so still free to this day, all the AWS bits.
Jesse
That helps. For the product catalog, was it built into Hasura, or is it a serverless function that communicates with a PIM software?
Jeremy
Yeah. Initially it was fully in-house, and now, it's a good question, we integrating a PIM software that synchronize. That is now the master for the product information that pushes to us, so we do that. We have two kinds of sync. Period sync and webhook based sync. The product information gets updated, we listen to it via Lambda, then we update. But yeah, initially it was all built in.
Jesse
Were you able to achieve all of this through Expo, or did you ever have to eject from more granular native controls? We got questions that just cover the entire stag. This is fantastic.
Jeremy
So Expo, we only use expo for the rider app, for the React native app, the Cajoo one. We had expo initially. When I was actually pitching the VCs, I started building it with Expo, just to show them something, but then yeah, we quickly had to eject. Namely it was to use the React native intercom plugin. We used intercom. I like it very much for customer communication, and plus you can send notifications, it's great. So we eject it quickly on the Cajoo app for this. The rider app, we still use Expo. Even with like a location sending, et cetera, it works well.
Jesse
Which option did you choose for authentication? I recall you said JWT. Do you have another endpoint to generate that JWT, or some function inside Postgres?
Jeremy
Yeah. So as I said, initially I had an endpoint that would generate my JWT that would communicate with Hasura, and then I would serve it to my user. The user would embed that in the headers to communicate with Hasura. So you would contain the ex Hasura user ID, the permission.
Jesse
Are you on Hasura cloud or are you a self host?
Jeremy
Yeah, like I said, we are on the Hasura cloud. That was one of my requirements, because I wanted to worry the least possible on the Dev Ops part, and just focus on getting something out the door, and so far it's been great.
Jesse
And then which service do you use for observability? Do you use Prometheus, Jaeger?
Jeremy
So we forward everything, all our logs. Actually you have an integration with Hasura on Datadog. Datadog, and we centralize everything there. There is an integration Of Hasura and from AWS, all the CloudWatch, so you can forward pretty much everything to CloudWatch and AWS, and then from CloudWatch to [inaudible 00:50:39]
Jesse
And then what kind of roles do you have in Hasura for authorization?
Jeremy
Yeah, so initially I had three roles. I had anonymous, that would be able to query pretty much everything as a non logged in user. I had the user that would be logged in, and so that would access only their own information, and I had the admin that could access all the back office. And then the admin actually was broken down into a business specific role, so you have the marketing team that needs to access certain data, some data, but not other pieces, the category management team that needs to access product, but not other pieces, et cetera.
Jeremy
So, we then broke down the admin, because the admin was just a [inaudible 00:51:28] so we can get started quickly. Then we broke down those roles. So we have, I think, seven roles now. And what's super interesting is that we had the product managers actually working in Hasura to define the roles with the business, and changed them directly, and then we worked with the metadata to commit that, but means we had the business owner completely working with the different teams, to configure like what permissions they need exactly. They had to get a bit deep into the data model, but with the Hasura console that was quite doable, and so they managed that. I think that's quite cool.
Jesse
That's great. That's all the time that we actually have today. We don't want to take out more of your time. I really appreciate how much you were able to share with us. Again, fantastic story, so really appreciate you joining us today. I will just throw a quick shout-out. For anybody that still has some questions on what they saw tonight or anything else, we do have in a few hours, our weekly public office hours. If you go to the Hasura website under resources, there is a office hours link, you can sign up totally free. We just have a couple of texts there, that answer questions for an hour or so, so if anybody has some additional questions, join us over there, but this was fantastic. Really appreciate your time, and we will see everybody else in another webinar for another customer next week, and we also find this online. We'll email you all a link to this recording, and we'll catch you all around the Hasura community. So thanks again for joining us, Jeremy.
Jeremy
Thank you all. Bye-bye.
Jesse
Bye.
End of transcript
Build apps and APIs 10x faster
