 Okay, I shall start. Let's not waste time. So basically, currently I'm actually the product engineer for it. And basically, we are actually trying to build a mirror this internal product ourselves, and I'll talk more about it. So, yeah. Right. So I'm Gerald. So basically, I've been, I graduated two years ago. Basically, I'm working as a software engineer for about the few years, two years to two to three years. And yeah, if you're interested, you can hit me up on the following platforms. And I think I'll do a short introduction of IFOI and what we are. So basically, IFOI actually started out as a design agency, basically to provide founders with basically design design, the designs and product design and everything. And currently we're actually venturing into engineering. So we are actually providing end-to-end services from designing the engineering. And if you're interested, we can hit F4 at ARP at Twitter or even, you know, hit our website at f4.studio. And we are actually hiring, not at this one, but yeah, if you are interested for brand engineers. So this agenda, quite straightforward, I'll go right into it, but Mira. So, Mira is actually an internal tool, an internal product. We actually want to build to actually allow readers to read and share newsletters. So actually the pain point about this, why we actually started this product is that, not me, but my friend Gabriel actually shared this with me is that, what happens is that we want to be a newsletter aggregator. So because usually when you actually subscribe to a newsletter, you actually use your own emails and stuff. So we usually use that, all the newsletters which come to your email inbox. And sometimes when you subscribe to multiple email newsletters, it's actually quite hard to read the newsletters because you need to organize it, you need to find out where is the newsletters and everything. So I would say this is a platform to actually build, to actually enable people to read and share newsletters. So without further ado, actually we'll do a quick demo of the website. So one thing is that probably we are still building it and I think it will be beta soon. So pardon if some things that you see are not perfect yet. So this is the landing page itself, I can actually sign out and sign in again. So this is the what you see. So we assign in, just do a quick sign in. And this is basically the landing page itself. So basically a lot of the three small sections in this case is the today. So basically what was for today, what you are subscribed to, based on what you are subscribed to, the newsletter you are subscribed to, they will give you certain recommendations. And so what we actually do here is that we will actually display the HTML content on iFrame and display it to the user itself. And other than that, we have the discover page. So basically currently we are actually upgrading several newsletters, basically collecting them and displaying them. So one of their signal be noise. So if I'm familiar with it, I'm not familiar, I just got to email newsletters a while back because of the influence of Gabriel, my friend. So yeah, you can see what we can do is that we can actually have the newsletters here read through. Currently some of them are dedicated for that. And you can actually click to read later. If we save, you can go to later page and you can see that it's actually there. So yeah, pretty much I would say this is what we have right here. There are still some features that you want to have before we actually go to pay it out with this. So I think without further ado, I will go down into the technical challenges that we have faced thus far and as far as some tech choices that we made. So before that I will go to the tech stack. So basically the front end, you can see it's not. I didn't build it, it's basically built by another front-end engineer, our introduced data secretary. So he actually built it using NUCs deployed on Nellify. And for back-end, it's very simple. We actually have a mega service layer using Rails. And they are based in Postgres and for search, it's used simple. Most people use elastic search as well. So with this, I'll talk about the interesting challenges that we find. So one of the technical challenges we have is with cursor pagination. So one of it is that I'll explain more about cursor pagination and what it's about. So basically, we are using GraphQL in our application itself. So in GraphQL, you actually have like before, after a certain item, you have to find out what comes after a certain item and what comes before a certain item. So what I realized is that I was using the typical cursor pagination logic, but I realized that it's not working and I had no idea why. And I realized that it's because that the model primary key is set to the unique identifier. So basically UID is actually a long string of tags that doesn't really have any order. And usually the pagination logic uses some order to actually return new results. So I actually Google around and spend some time on this and actually need to change the pagination logic to actually use the basic in Rails we have updated at. So we should use that together with the UID to actually filter out the results and return it to the find itself. It's quite interesting because many first doesn't work. I was thinking, why would we know? It's basically just simple pagination. And yeah, it took a while to actually get arrived at the solution. So yeah, quite interesting to share. Next one is we have a need to actually scrub newsletter content. So let me explain further. So on the right hand side is actually a newsletter you will see on a typical, when you receive on your email itself. So you can see usually at the bottom, you have this section where it's actually required to actually return you a section where you are able to unsubscribe if you do not wish to receive newsletters from this provider anymore. So what we do right here is that we don't want it to be here because you are a newsletter aggregator, so we don't want the newsletter to have this where the users are actually unsubscribing on our behalf. So currently we have success with some of the one approach that we have. So basically what we do is we actually get the different newsletters from the same publisher for around the same time. And you're compared and the difference to spot the unsubscribe, this unsubscribe section and we actually remove it. And it works for say 80% of the newsletter out there that we have, but for around 20% of it, it actually removes some other static content that is similar in two different newsletters from the same publisher. So it's quite, we have to handle this as case differently, but we are still working on it right now. And another food for thought. So let me explain the approaches that what we do is we basically just get the HTML content. We compare the deep for both HTML contents and spot a difference. Currently, we are only removing the difference in content at the bottom because usually unsubscribe section will usually come at the bottom. So we remove that, but some of it which works for most cases. And by the problem is that some at the bottom of some email newsletters they are actually content that we don't want to remove. So we are actually finding ways to actually avoid that problem that we have. And upon further look, just a food for thought, we actually have several advertisements that we have that is in the newsletters. So we will actually want to remove them to actually improve videos experience. So if you have any thoughts for this, you can share because I have actually never actually tackle this problem yet, but we're good to hear any opinions. So I'll move on to technical choices that we made. So I think one of the technical choices that we made is quite new. So we've been using this website called Render to actually deploy our applications. So I'll say it's quite interesting because in some places it's quite similar to Hiroku. I only use Hiroku once, so I'm not very familiar. But I'll say Render give a very simple experience and very easy to deploy. To deploy more, I'll say I set it up. The simple deployment takes about five to ten minutes, but to set up the domain everything takes a while more. But we're using Cloudflare with Render, so it's quite simple. So the problem is that I'll say the cost rack up pretty quickly. So I'll say we have our database and everything. Database, Elasticsearch, and we have probably their microservice and another layer. All these actually rack up prices. I will say currently we are racking up close to $100 right now. So I'll say we are going to scale down and see how we can achieve this. So this one thing that we have and our technical choice that we have is that Rails out of the box provide ActionMailbox. So this actually allows us to actually ingest emails easily. So in BC, we are using Sangrid and with the mailbox with Sangrid, we can just plug and play ActionMailbox and ingest the emails, allow us to actually not care about ingesting emails and care more about what content we want to show to our users itself. And setting up pretty fast because Rails actually has the guide itself. So these are the technical choices that we made. I think coming to the end, I will give credits to, I'll say the front-end engineer, Zachary, he built on this. And this project won't be here without our CEO at F1. So you can follow either of them on LinkedIn or Twitter. And I think through this, we come to the end of the presentation. You can ask any questions if there is. I have one question. You mentioned that you'll use the ActionMailbox drive, which means that your app subscribes to all the newsletter out there. Correct. And then whatever your users subscribe to in a way like on your app, and then you will show them subsequently. Correct. So one thing we are actually, I don't see the problem as more of like, we are actually subscribed to about 500 newsletters right now. But it's too ongoing, but I think one thing that we want to do in the future is that we want to allow users to actually have the ability to actually add newsletters. So maybe there are some newsletters which the readers might be interested in, but maybe we are not subscribed to. So we actually want the ability to actually allow users to actually subscribe to newsletters that they want. And hopefully these newsletters, if they're interested in, we can actually share it to other users as well, so that people can be exposed to the different newsletters that are out there. Yeah. Okay. So like giving your users the ability to like introduce news newsletter, but then this part of how to let them introduce and then the data coming into your entire app. All these are like not thought about yet, right? We actually talked about it. So basically we are going to give email, basically a customized email to every user. So the customized email will be very specific to the particular user itself. So they can actually use that email to actually subscribe to newsletters. And whatever newsletter they actually subscribe to, the email newsletters will just come to them for now. We haven't talked about how do we actually enable the sharing of newsletters for the sharing of newsletters that the particular user is actually interested in. So maybe let's say, for example, we are not subscribed to Ruby Weekly. It's not the case, but for example, if that's the case, then the users subscribe to Ruby Weekly. We haven't actually talked about ways to actually share Ruby Weekly to everyone yet. Yeah. Okay. And just curious, I haven't used Render before, but I keep hearing about it. And I know there's an alternative to HeroCool, which basically is another path. Then they're just curious like, I'm not sure whether you have contacts, but how do you make the decision to choose Render over HeroCool? Or was it just because you don't know how to use it? I think the decision for using Render basically first is that I think we want to try, because everyone has been talking about Render, as you said, as mentioned. So I think we want to try something new and we want to see whether it's really part of its expectations, which I think it is. Because I think the problem is quite straightforward, because every time you can actually hook it up to the GitHub repo, and every time you push anything to a future brand or to a master, you can actually deploy it right away. So I think it's quite easy. And all the features are there. The support is quite good. I would say we actually get, we have questions. We actually, there's a forum. We just post it there. Within a day, you really can get the problem resolved. But comparing HeroCool and Render, I don't really have much experience with HeroCool. So actually, Gabriel made his choice to actually go with Render. I just went ahead with it and see how it goes. For the removing of the un-subscribed footer, you say you're compared from the different sources? We compare from the same source, but different newsletters. So like Publisher UG is published like newsletter weekly, or maybe like on a bi-weekly newsletter. So we'll compare the same newsletter, same newsletter from the same source, but different dates. And we'll compare and get probably the bottom. We get the bottom. Actually, we won't be. Yeah. Okay. Yeah. Because I was thinking that it might be possible to also do it using, but do some keyword matching. Because usually most of them, they will have some address, or some company email, or et cetera. Okay. Oh, yeah. Ignore that and try it out. Yeah. So I think the part on the removing advertisement, I think it might be very hard because, no, I think more of like, it's very hard to differentiate what is advertisement, what is not advertisement, right? Because it could be advertisement, but it could be relevant to the content or so. Yeah. So I'm not sure how I'm going to do that. Yeah. I don't think that will be, I don't think that's the problem that we will tackle now. Probably, I think we will probably release it first, get it out to people to use it first. And once we get out there, then we will start to think about the problem. Yeah. I'm actually curious. You said you'll face this pagination issue because the primary key is the yo-yo ID. Yeah. But if I'm not wrong, Reels default is the, like one, two, three, the numerical, right? Yes. Is there a reason that you all changed your primary key to that? Reels for changing the, right. Yeah. Reels default ID is that or the, I don't actually have an answer to your question. Sorry. So basically I joined this project while it's, probably I'll say, while my friend Gabriel was working on this project. So some of the technical choices I didn't really question because I think we didn't, at the time we want to basically do the product. So yeah. Yeah. Because I think I remember for my own product, like because we will be imported, we call some API and then you got some data from somewhere. They also use your ID. And then because of that it broke quite a lot of things that then default that Reels thing, especially if you use elastic search, probably use like search key or something, then it will also break the other stuff. Yeah. Yeah. Yeah. Yeah. So for your, for your, I would say, I'm quite sure you're working on NotePlay, right? Yeah. NotePlay using all the ID, as in the basically a simple one, two, three, four. Yeah. We sort of have to pass it to use, I think a lot of the gems, they sort of assume that's the default. Yeah. Yeah. Yeah. I also like ran into this problem before, but I use the, basically I didn't change to UUID. I still use like the big integer, but then somehow right, I still have to sort my ID. Although it's like big integer ID, but I still have to like, intentionally sort it by something, like even if by the ID that I want to sort. So I think that like, even with the default Reels one, you still have to think about how you want to sort it. When you put the data, it would just not, like if you didn't do an order by right, it will, it will probably not come out as you expected anyway. Yeah. For the pagination, you're implementing yourself or some kind of like gems. So, so basically we use GraphQL. So basically from GraphQL, the pagination wise is not, I think if you can use Graph, I'm not sure about this, but I think you can get GraphQL Pro, then they will have like in view pagination like for you, by using the GraphQL free version. So there isn't any pagination. I mean, you have to implement it yourself. So we actually just wrote interface and basically pagination is quite straightforward. So, but I didn't think about the UID problem until I face it. So there's one problem too. That's not interesting problem that actually, that I face and fix it. So it was quite interesting because I didn't expect myself to face this problem and I face it anyway. So yeah. I actually use this gem called Aminari. And like it traditionally was used more, more like, okay, you have a front end view and then use ERB and then it like, like allow you to do all the pagination, like for the click next, next, next, all these things like out of the box. But I realized that like because they, they add a helper method into your, into your model, like your active record, right? So then actually you, you don't really need to use the view. You, you still can easily like do pagination and pull data and then render you with your, render you like GraphQL or whatever you want to. So, so in general, I, yeah, I'm using this and it's already like quite good. Yeah. I use this also. And I think quite of, if I'm not wrong, quite a few of those like database like wrapper, they, they integrate with this also. Like for example, like I think the search gem for that, the elastic search one, they also like can integrate with this. Yeah. It's quite easy. It's just like out of the box. It is at one. And then they give you some ways to configure it also. I think it's quite neat. Yeah. Okay. Anybody else have any questions? Yeah. Okay. Then, then maybe like one, one last question I have then you mentioned like Mira, you guys are like, in beta stage right now, right? Like what, what is the like the near future plans or something? Like, do you all have like planning to launch soon or something? Yeah. So, I think once, once beta is over, we will basically launch it. And basically once beta is over, launch it. So I think according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to according to to move this product further. Yeah. Yeah, I think as a user, the one where, like, because I guess you're going to like amass like a little bit of like newsletter content, right? I think the part would be quite interesting is that like you can recommend me like a user like what they, newsletter they didn't thought they want. Based on that similar attributes or something. Yeah, yeah. That's one thing that is in the pipeline. So basically, you know, how, how you really have to recommendation. They ask you for your, you know, your, what do you actually, what categories, you know, what do you actually watch or look at? Then, you know, based on that, they will do some recommendations. Yeah. Thank you. Okay, awesome. I think, thank you. That's it. Yeah. Thanks for the sharing. So now I'm just like, just cozy that one.