Nirmalya Ghosh joins the React Round Up panelists in this episode to talk about how he migrated a monolithic Ruby on Rails application to React. What was estimated to take 3 -6 months ended up taking about 2 years, and Nirmalya shares all the hard-won lessons he learned along the way for any listeners who might be preparing to make a similar upgrade. Additionally, he talks about the company he currently works for and how they're trying to become the one-stop shop for anyone looking for a good API online. Lots of interesting tidbits are packed into this episode!

Hello everyone, welcome to another episode of React Roundup. I am your host today, Paige Niedringhaus, and we are joined by our panelist, TJ Vantol.

 

Hey everybody.

 

And our special guest today is Nirmalia Ghosh. And Nirmalia, I apologize in advance, but please say your name the correct way and tell our listeners a little bit about yourself.

 

Hi everyone. I think Namelya is the correct pronunciation and yeah, happy to be here. I will start by introducing a little bit about myself. I have been working in the dev rel team at a company called Rapid API. I work in the senior developer programs engineer and my job is to build all the code examples, build API stuff, build all the cool API stuff. I say cool because it's not actually related to the actual product, but I bridge the gap between developers who want to use the product and the developers who are building it. So bridging the gap between the code and the community. I also build a lot of interactive components, which helps visually understand what the API does or how you can integrate certain kinds of things with Rapid API. like the GitHub for APIs, where a lot of APIs are available. And you can search for any type of APIs, like you want to visit a place, so you can search for hotels. You want to watch a match, you can search for APIs related to football and stuff like that. So my job is to look at those APIs and create integrations with various technologies, like, for example, React, Next.js, Vue, on the front-end side. On the back-end side, it can be Ruby, Unreal, Spikes, and Django, et cetera. So that's my day job. And when I'm not working, I am generally trying to contribute to open source projects. I have a few open source projects, which I try to maintain. But it becomes sort of difficult sometimes. And when I'm not working at all, when I'm not coding, basically, I try to play football as much as possible. And that's about me.

 

Sounds like you've got a pretty full plate. Ha ha ha.

 

Yep.

 

So I'm curious, I definitely want to talk more about the APIs and the kind of stuff that you're building now. But the first thing that we actually asked you to come onto the show to talk about was something that I think a lot of developers have struggled with or have encountered, which is migrating a large code base to a new platform, like bringing it into React, bringing it into Next. And it seems like, or it sounds like you have actually gone through this process. So maybe you could tell us a little bit about how it was for you and some of the advice, tips, tricks, pitfalls you encountered along the way.

 

Definitely that is like one of the most important or most challenging projects that I have done in my professional career. And the code base that I started working on was a monolithic Ruby on Rails application, which has like small, small react applications, client-side react applications split throughout. I'm talking about 2015, 2016-ish kind of space. where React just came out and we wanted to try out this thing instead of jQuery, which we all liked, but when React came out, we sort of wanted to experiment with it. But what we found out is that it's very difficult to make everything work together. For example, there was Redux, so Redux was not that much popular at that point of time. So when you want to make the sidebar, which is a React application, work with the... navbar or the content area which are different React applications, it becomes very difficult to connect. And micro frontends or stuff like those things were not that popular during that time. Or they were there, but it was very difficult to make them work together. So I sort of took up the project, I looked at my whole team, that we wanted to take that monolithic Ruby on Rails application and split it into two parts. One. the back end would be on Ruby on Rails, but it would only give you the APIs that are necessary. And on the front end, we sort of fought over a lot of frameworks. For example, we thought about Angular, we thought about a lot of other things, but

 

Mm-hmm.

 

eventually decided to use Next.js because the whole team, the development team at that point of time which we had hired, were specializing in React. And it makes a lot of sense to use something which is popular. And thinking about now, I think I was one of the developers who wanted to use createFractor, but I think choosing Nexus was the right call, especially when you think about the stuff that has happened over the last few years.

 

Mm-hmm.

 

And I honestly, I learned a lot of things like how you can write code, manage code. And structure everything in a way which makes it possible to do that kind of migration. You know, like you are talking about a live app. You cannot stop the app. You cannot say that I won't push upgrades or bug fixes and I would only work on this new shiny stuff. It doesn't work like that. The business, the product managers will never let you do that. So, like when I was thinking about doing this kind of migration. I try to research a lot like how other companies or companies which has like big applications are trying to do this sort of migration. It doesn't have to be react specific, but it has to be like splitting the monolith into a front and back end.

 

Mm-hmm.

 

And what I figured out during my research time is that it is possible, it is hard, but you have to do it in chunks. You cannot do the whole thing at once. You cannot say that. I would pause everything for one month or two months. I mean, two months is a scenario which generally takes like years, to be honest.

 

Yeah. Ha ha

 

But

 

ha.

 

you cannot say that I'll stop pushing upgrades for two months and work only on this thing. And we are not even 100% sure if this is going to get into production, which is a different call altogether, right? Because a lot of projects start, but they never get into production.

 

Mm-hmm.

 

And what... We decided during that point is start with the path of list friction. So take the part which we don't have a lot of visitors. So it took

 

Mm-hmm.

 

one page where we noticed that we were getting probably like a hundred or a couple of hundred visitors in a span of one month. And we decided to take that and build an access application only for that page. And when we started working on it. We figured that it's not easy. It's very painful because you, if you, if you take your whole team and start doing that project, there will be a lot of like, like people will be, uh, stepping on each other's toes and

 

Mm-hmm.

 

it's not going to get forward. So we built a very small team, like four developers, one person will be responsible for the backend bits and the three person will be responsible for doing the front end stuff. Because we were splitting a monolithic application, we have to understand that the back end also needs to make modifications. It's not only about front end. So what we did is we started that page and wrote an XS application. And after a few weeks, the initial time is always hard for the first page. So I'm saying around a couple of weeks or a little bit more than that. We got that page working, but on development. And we had no idea. how to make that page work on production, right? Because,

 

Yeah.

 

you know, like you have to think about authentication, authorization. It's not like

 

Thank

 

a

 

you.

 

marketing

 

Bye.

 

page which anyone can use. It's a page under the cover of authentication. So then, we thought about how we can do certain things which will help us, right? So, I mean, this is like kind of a buggy way of doing it or not the ideal way, but what we did is... Like we performed the login or the authentication via the Rails application. And whenever

 

Mm-hmm.

 

you visit that particular page, which we revamped, if certain cookie was enabled based on a feature toggle, then we would redirect the user to that Nexus application. Now you have to understand, like we were not using Bootstrap. Like

 

Mm-hmm.

 

the existing application was using Bootstrap, but you know, like we were getting into the stage where design systems was the first, right? And we wanted to try out so many things, but eventually use something like and design because we didn't want to invest more time into developing

 

Mm-hmm.

 

components. We wanted something that is already there and we wanted to just take the components and make it work. So we started working with that and it worked really well for us because when you look at it, like after a few months when A lot of developers started developing pages and started migrating in this way, like sort of cookie based or feature flag based approach.

 

Mm-hmm.

 

Initially we were taking around like one sprint. It's been comprises of two weeks to deliver a single page with

 

Mm-hmm.

 

obviously a few complicated logic, like tables, filters and stuff. Whereas we were able to complete after the migration in like three to four days. And.

 

Wow.

 

Like when you think about like 20 developers, it is a lot of time saved, a lot of bandwidth saved and

 

Mm-hmm.

 

the development experience was really good. Like for example, when you're working with a monolithic application, which is all good, but for front-end developers, you really don't want to work with jQuery, HTML and that

 

I'm

 

kind of stuff.

 

sorry.

 

It also had CoffeeScript. But the thing is, what I'm trying to say is after we did this migration. there were a lot of pitfalls at the start, but it started becoming smooth. And it became even smoother when we integrated TypeScript into that project. Like I wanted to use TypeScript because people are talking about TypeScript on Twitter. And I just wanted to try it out. And I wanted to try it on a big application because I was stuck on small, small applications and they are working fine. And

 

Yeah.

 

The reasons that I wanted to use TypeScript was because I wanted to have type safety and autocomplete. Like I was, I am a very lazy developer and I don't want

 

Hehehe

 

to like write long, long things together. I just wanted TypeScript to autocomplete and lessen the amount of bugs. Like you know, like when you have a big application and a lot of developers copy paste happens, right?

 

Right.

 

It's something that you cannot predict and you cannot prevent. And using something like TypeScript really helped me in that way. I mean, TypeScript was the first point where I realized that, okay, we are improving. There was no metric, especially you cannot really measure any metric, like how is your development experience. So what we measured is the time taken to deliver a project, and the developer happiness, like is the developer happy with the work? Is the developer happy with the feature that they have built and the number of issues that we're getting?

 

Right.

 

We will talk about it, like how we reduce the number of issues using Storybook, React

 

Mm-hmm.

 

Yeah. So one thing I'm sort of wondering about you, you're migrating from like rails to next. How did I, and maybe I didn't quite grasp this, but how did the two co-exist? Because next is very much kind of wants to control absolutely everything.

 

I'm sorry.

 

Right. Like,

 

Thank

 

so

 

you.

 

I, like my brain is having trouble processing. Like I love the idea of migrating in chunks is amazing. Like

 

Mm-hmm.

 

I think that's definitely the right strategy. I'm just. struggling to figure out how that's even possible with Next because

 

how

 

it

 

they

 

just wants to

 

lived

 

own everything.

 

together and yeah.

 

Yeah.

 

All right. I'll just give you a little bit more context regarding that. Initially, we were using React inside the Rails application. We are using not create React app, client-side React, how you do

 

Okay.

 

right now on code sandbox.

 

Yep.

 

Mm-hmm.

 

You call unpackage.com slash React and React DOM, and you reactdom.render, and you start the application there. So we had those things during that point of time. And when we decided on using Next.Chairs, what we did is that we took a page and using NGINX and a few other things, which I didn't mention intentionally, because right now it's not necessary. It's

 

Hehehe

 

easier to do that. But using those sort of things, what we did is that after the authentication is done, we redirect the user based on a feature toggle Rails application or the NextJS application. Those

 

Mm-hmm.

 

are running separate. You can think about it that the Divendrls application is running on a different port, and the NextJS application is running on a different port. I'm talking about development. But you can think about the same thing on production as well. Three Wires can be different. Also, one thing that I would like to mention is that when you started working with NextJS, to run NextJS, you needed to have a server. So it's on production. I'm not talking about like SSG, SSR. I'm talking about

 

Mm-hmm.

 

get initial props, that kind of state. So it was also difficult in certain way because we had to use Docker because our app was a multi-tenant application. So

 

Mm.

 

more complexity. But that's how we made the existing Rails application work with the Nexus

 

Mm-hmm.

 

application. That's that. sort of makes sense or you want me to dive deeper.

 

Yeah, no, I think that helps. It's just, I had a feeling there was some more complexity to

 

Bem-vai.

 

it because it's, yeah, it's not the easiest beast to tackle.

 

No.

 

Yeah, I mean like we've already had like five or six failed migrations before that so we took the lessons learned from that as well Events are always the hardest

 

So one question that I had because I, when I worked at my previous company, we did a similar

 

Thanks for watching!

 

migration from angular JS to react. And one thing that we ended up having to do was take a lot of the logic that angular held in the front end and create additional microservices that could serve up that information from the back end. So when you were kind of figuring out how to migrate your application. First, how did you decide which pieces to migrate and when? And then second, did you have to do the same kind of thing where you created new backend services that kind of just could serve up the information to the React API or the React Next.js client?

 

That's a really good question because that is one of the issues that we also had encountered. The reason why we didn't build any separate backend thing out of the ordinary thing, like one job of the backend developer was to take the existing Ruby on Rails pages and spit out APIs from those things. But we didn't want to create anything out of the ordinary for the backend service because we wanted most of the logic to be on the front end. You have to understand, like in a real scenario, when you want to do a migration, it always makes sense to push complexity to the back end. And that's where you all started. But when you think about a realistic scenario, you always have like failed projects of migration. So you can understand like the trust of the organization on this project being successful and not being a mess is not that high. So... You also have to address that we want you to take the path which has the least friction and like what you're talking about that was also thought of, but we figured that if we want to do the backend that has to be done before the frontend starts working. So you can understand like it becomes like one month of extra work before the frontend work starts. And that is something that No one was comfortable, even though we wanted to, because that would have made our life a lot easier. But people were really, really not that much sincere about doing something like that. So because of that reason, and the other reason was, our APIs, we had the plan that we wanted to expose our APIs so that any third party application can consume the same APIs that we are using internally. Now. When you want to have something like that, there are two ways. Either push most of the logic or the business logic to the front end and let the back end be very simple, which is the part that we followed. The other thing was have two different set of APIs, one for the internal applications and one for the external ones. But those would take much longer and we didn't have enough bandwidth to do something like that. And that is why we didn't follow that approach.

 

Real quick, the background noise, is there any chance you could, I don't know, it started

 

turn

 

kind of

 

it

 

small,

 

down.

 

but it's like, yeah, it's growing

 

So.

 

in volume. I don't know if there's any chance you can.

 

The thing is I was slightly worried about that. I am in West Bengal, India, and right now there is a festival going on just outside my home. I have everything shut off, but I don't think that I can reduce the volume anymore. I'm so bad.

 

That's all right.

 

Yeah.

 

At least it's exciting. It's nice music.

 

Ha ha!

 

It's from the 80s by the way.

 

Ah.

 

even better. No problem then.

 

So then are there any other pitfalls? Because we went through migrating that, but I think there were a few others you were going to mention.

 

There were actually quite a lot because when you think about like, okay, first thing is the organization bias is always there, right? Like if you want to build something which is like the main product, you want to remember the main product, the product that keeps the company alive. And I'm talking about a small start. I'm not talking about like a big MNC. You always have the budget restriction. So you always have to think about like, how can I do the most amount of work in the least amount of developer time? I'm not

 

Mm-hmm.

 

talking about like months, I'm talking about developer time because that's the most cost that the company incurred. And the other thing was the company was, or the product was using Bootstrap. It was using Bootstrap 2, Bootstrap 3, Bootstrap 4, three versions of Bootstrap together. You know,

 

Mm-hmm.

 

like any application which has been there for around. more than 6-7 years has those kind of things. And when you move away from bootstrap to Ant, it's very difficult to make both of them work together and look together, look consistent.

 

Mm-hmm.

 

So that was another challenge which we faced, but how we tackled that sort of, we couldn't make it exactly. But what we did is, initially, under the feature flag, work as much as possible with the granular settings. We modified the brand color and a few

 

Mm-hmm.

 

more spacing because Ant at that point of time only exposed FAS. In the recent one, which they released a few months ago, they announced CSS in JS. So it's not a problem right now. But that point of time, it was using CSS variables.

 

Mm-hmm.

 

So we tried to modify the brand color. We modified the fonts and everything to make them look overall similar. And before we turned the feature toggle on for everyone, we took the bootstrap part and configured it or modified it to make it look similar to and, because we knew that the bootstrap part was already messed up and it was not maintainable at that point of time and so on.

 

Mm-hmm.

 

So what we did is that we wanted to add more mess to the existing stuff because we knew that we were going to throw that away. and rewrite that with ndesign in the next couple of months slash years based on the priority.

 

Mm-hmm.

 

So that was another challenge that we faced. The other challenge was because we are working with a multi-tenant application, you have to understand like we cannot just like there is only one application, one front-end application and one back-end application which spits out the APIs. So we had to use Docker. for that because we wanted to make it work on our development, seamlessly on staging

 

Mm-hmm.

 

and seamlessly on production. Like the same thing. Although there were a few differences because how ACID compilation worked in Next.js at that point of time was a little bit different than how it works. Right now Next.js does everything. At that point of time, it wasn't the case. It was difficult. And a few other things like on production, what I noticed This is something that developers who have done this sort of migration will know is that everything works fine on development. On production, the CSS doesn't load. or something gets

 

Yeah.

 

messed up, right? And

 

Yeah.

 

I'm pretty sure most developers who have been working for a few years have faced something like that. And honestly, that was a bit difficult to debug because we all knew that everything is similar. Like on development, it's Docker. On staging, it's Docker. On production, it's Docker. So why is it

 

Mm-hmm.

 

breaking? It turns out that someone had upgraded a package and the package lock file was... messed up. And

 

Oh.

 

when you clear that off, clear the cache, because Docker caches everything, when you clear those things up, then only it started working. So I'm talking about like, I wasted days on this,

 

Hahaha

 

but I'm giving the answer in a few seconds. But honestly, it's very difficult to debug when something like that happens. And people like front-end developers are always scared of removing package lock or re-unlock file and start all over again.

 

Yeah, and adding a layer of Docker on top of that just makes debugging it that much worse.

 

Yeah, it was difficult because, you know, like we had recently added Docker to our application during that point of time. And then

 

Mm-hmm.

 

we started working on this migration. So the Docker already had a few rough edges at that point of time. It was not very smooth. And, you know, like, it cannot say that, okay, it has to be very smooth. And then we'll start on this migration in a normal startup or a middle, like middle sized startup. that thing is something that never happens. Some upgrade

 

Hehehe

 

happens, you start working on the next, something gets messed up, you fix that, move on, come back again,

 

Mm-hmm.

 

fix it, move on, it's like that, right? So I'm not sure how it works in big companies, but I'm talking about a very small startup and it became imperative that we had to work with what we have and there were frictions, but we resolved them.

 

So how long did it, how long did you think it was going to take to do this migration and how long did it actually end up taking? Because in my personal experience, I think that we had budgeted for maybe three months and when all was said and done, it took closer to three years kind of on and off.

 

Okay, in our case we had budgeted for around three months to six months. Why I'm saying

 

Mm-hmm.

 

three months to six months? Because three months for only the four developers, the initial developers were working on it and the rest of the three months for everyone, whole company to work on it.

 

Yeah.

 

It took around two and a half years.

 

Yep, that sounds right.

 

Yep.

 

And, but there were a few good things because after one year, MixedChase became very popular and they started removing the custom server that you have to run on production. And it became very fast compared to the previous versions. It became very fast and React was also doing a lot of things which helped us in improving the performance. And there were a few breaking changes. So you have to understand like... those things also took quite a bit of time even though not all the developers are working on it but when someone makes changes something always gets messed up and that's where days are lost because of those things and you have to fix those things because someone is blocked and sometimes it happens only on production sometimes it happens only on staging you all hate that when it doesn't when it works on development but doesn't on the other environments but those things were there and we had to fix that. And at the end, like after almost like one and a half years, we sort of knew that this is the right approach because like the amount of time that we are saving and the code that we are writing, like everyone was able to understand the code that they were writing. Previously,

 

Mm-hmm.

 

it was like, I want to make this work and move on to the next project. Right now it was like, okay, I've written this, how can I improve this? Because...

 

Mm-hmm.

 

We were saving a lot of days writing code. And the code was, everything was in React and JavaScript. It was easier to reason, easier to debug. Server-side rendering was a bit tricky, but once you get the hang of it, it becomes very easy. Not

 

Yeah.

 

very easy, it becomes easier. Server, client-side rendering, debugging, that is always easier on production

 

Yeah.

 

at least. But when you don't have a lot of logging, okay, here comes the logging. Initially, we didn't have logging. and production. So when something goes wrong in a server-side environment like Next.js, it becomes very difficult to debug. But

 

Yeah.

 

we sort of use technologies like Datadog and all where we got logs and tried to figure out how we can make it work, where the issue was happening. And

 

Mm-hmm.

 

that was another issue that I was talking about earlier.

 

I will say for one thing, it sounds like you picked Next.js at around the right time, because

 

Yeah.

 

you should have got in it on the investment front or something, because they're taking

 

I can't

 

off. I

 

stop now.

 

actually am curious, as we're recording this, Next 13 was just announced, I think, a week or a few days ago. Have either of you been following along with any of that? Are there any of the new features you're excited about or wanna try out?

 

I mean, yeah, it all sounds great. It sounds like, like we said, maybe before we started recording, there's a lot of breaking changes that Next.js 13 is bringing, but it's, I mean, it also sounds like the React team has gone completely in on Next. They've got the server rendered components, they've got suspense, they are integrating data, all the concurrency stuff. I don't know, I honestly wonder how long Create React app is going to continue to be its own thing because it seems like the React Core team is really betting big on Next, which is cool, and also scary at the same time because they don't own Next. And so it'll be interesting to see. But I mean, I'm really interested in it. I'm just a little bit concerned about the path to upgrade because there are so many changes that are really big changes.

 

To be honest, this was one of the picks that I wanted to discuss. But since we're doing it right now, yes, I'm very excited about next year's 13th, the new release. And like in RapidAP, we're building this platform of blogs, interactive documents. And my manager, Amit Avis, he gave a talk in that conference where he spoke at length about how we are developing things like this. So. Yeah, I'm very excited. And honestly, because I always wanted to have a system or a framework or a library or anything like that. It's confusing, I know. But it sort of does the work for you. And you don't have to understand. I mean, if you want, you can understand. But you don't have to understand everything that's happening.

 

Mm-hmm.

 

Next is if you want to understand how stops are happening, you can understand. But for example, When you are a senior, it makes a lot of sense for you to dig deeper into applications or frameworks to understand what's happening. But a company has senior developers, middle developers, and junior developers. So a junior doesn't have to do everything. Next.js or React in particular has this new way of fetching data, which becomes very easy because when you are building Next.js and you want to sort of fetch data in the component. You cannot do that. It doesn't work. I mean, you can use use effect and all. But it's not the ideal approach. It's not the wrong approach, but not the ideal one. If you want to make a fast application, a maintainable application, you sort of have to use getStaticProps or getInitialProps or getServerSameProps or something like that. Whereas when you have something like this, like ReactUse, something like that, it becomes very easy to reason about. It becomes very easy. to help juniors understand like okay this is the way you fetch data you don't have to worry about those three different functions get server-side browse get static browse and those things and to be honest like when I'm working with the framework I don't want to remember those things I mean obviously after you work with it for a few weeks you always understand or remember those things but I don't want to I want to just write the main logic for the code and make it work to fetch data

 

Mm-hmm.

 

it should be very seamless and very easy And I think like the path is correct, like react is going the correct path where it's sort of evolving from a library to a framework sort of thing, where it's not only a view layer anymore, but it also thinks about how you can get the data, sort of manage the data with react context and those kinds of things. And I really like this approach. I really like the path that is going and pretty excited about it.

 

Yeah, what's your take on it TJ? Have you been keeping up with all the announcements and debuts?

 

I've been keeping up, but not so much of the features. I'm more just fascinated by the fact that they're running like Apple style events with like, and just the, like the amount of money in it and the smooth video and the transitions, like it's, it's, it's kind of weird, like we're entering a weird space in the front end world where there's like this venture capital money. Behind some of these frameworks, uh, remix was just bought by Shopify. Like

 

Mm-hmm.

 

it's. Like I'm sort of fascinated from that angle and it gets it, what you said, page two with like the React team is like a core part of this. And it's like such a weird business aspect for like meta, sort of this company that makes this framework for free is partnering

 

Uh huh.

 

with Next.js, this like VC backed thing with a hosting platform. I'm just sort

 

Yep.

 

of curious where all that is going. But at the moment it's still like at the end of the day. my job as a developer is to use really the best tool for the job. And I mean, we used Next for, Paige and I use it all the time and we'll continue to use it. So I think they're heading technologically in the right direction.

 

Yeah.

 

But yeah, that's the thing that stuck out to me was just like the craziness of how big and like well-produced their release announcements are. And I've yet to get into like specific features. So that's why, that's kind of why I asked, right? I'm curious to check them out.

 

Yeah, same.

 

One thing that I'd like to mention here is that people who have been working with React for a few years, they will remember that sort of similar issue was there with the license of React a few years ago.

 

Yeah.

 

Uh huh.

 

But that also has been resolved. So I think that it's going in the right direction when you think about it. Like, for example, the framework called Astro, which is a framework I really like, but that is

 

Mm-hmm.

 

also backed by a company. the framework called Quick, which is a very new framework, which picks up all this whenever necessary. That is also, I think, done by Builder. So that is also a company. I think that it's fine, like except Vue, everything is backed by a company. It can be like small, it can be as big as Google, Facebook, or stuff like that. But I think, like right now, the environment is really good. Like if you're a JavaScript developer, you're already getting the shiny toys to work with.

 

No, I agree. It's open source. To their credit, Next.js is still completely free to use. And you could argue that it is a more sustainable way of paying people to work on these frameworks, honestly. So I'm not even arguing that it's a bad thing. I'm just saying I'm just sort of fascinated by how it's all playing out.

 

Mm-hmm. Yeah, the VCs have gone from backing tech, or I guess tech companies with a product to backing tech companies building the tools to build products, which seems like a good investment. And I like that, like you said, it supports open source, it makes it more sustainable and more stable and less of a chance that the open source maintainer will just burn out and have to get a day job to pay their bills. So yeah, I think it's I think it's a good a good move. We'll see how it turns out, I guess.

 

All right, so we also definitely wanted to talk about Rapid API a little bit as well. So I wanna make sure we have some time to get into it. And you gave us a little bit of an intro to it already, just a quick

 

Mm-hmm.

 

way of using APIs. I am curious, like what is the business model

 

Thank you.

 

there? Do you, is it like something that's free to use? Like if I just wanna use APIs, can I use it? Do you charge? How does all that work?

 

Alright, first apologies because the music becomes slightly loud here. Okay, so coming to Rapid API, as I mentioned, it's like GitHub, but for API. So where we have a hub where a lot of APIs are already present and you can take those API and start building your application. You don't have to worry about building back in part of your application. You can. choose any front-end application and then start using it. Or if you want to use our APIs instead of one of your microservices, you can also do that. Like if you are only building a backend application, but you don't want to build separate applications for fetching with that data, you can sort of use one of the popular APIs from the AppDPA hub and use that to build a one application on the backend part of it. Your front-end can work as it is. And we sort of provide, we sort of give the freedom to the developers that are hosting their API. There are two parts to it. One is, like a developer builds an API and then they list it or enlist that on the rapid API hub. And they can put restrictions like, they can add pricing tiers to it. They can say like, okay, you can do like 200 API calls per day. But if you exit 200 API calls, then you have to pay this much amount of money per 100 API calls. They can also have like a free tile, which we call premium. If you have like a premium part associated with it, like after you exit 200 API calls, then you will be charged. Some APIs are fully premium, where to use them, you have to sort of pay something or pay an amount to use the APIs. So it depends on the developer or the company who is giving access to the API enlisting them on RapidAPI Hub. And let's see, you want to use that API to build your own stuff. So someone who has already hosted an API, you can search for it and you can find like, okay, this is the way that API want to use. I don't want to invest my time, my company's time or my developer's time to build something like this from scratch. I want to use this API from RapidAPI Hub. So you create an account, you subscribe to that API. And if it's a... free API, you can just start using that. If it's a premium one, you sort of have to add your payment details to get that access to work with that API. So that's how Rapid API works for connecting the API and getting the API data. But there are other parts to it. For example, when you are a developer and you want to host your API, you can sort of earn money based on how popular your API is, how many users are using your APIs. and how many API things are happening on your endpoints. And we sort of have built this kind of infrastructure where we make everything very secure. We have like rate limiting built in, we have a few other security, like vulnerabilities testing and all those things in there. We also have rapid API testing, which helps you test your API. So it's, we call it rapid API studio, where you can... use our studio to build our APIs and then use that data in our application or let others consume that data. It's two ways. One is consumer, another one is provider. It sort of depends on what type of model you are looking for. And recently, we launched a VS Code extension, which is very helpful if you want to test your APIs or you want to generate types because the VS Code extension, which is called Rapid API VS Code extension, you sort of install that, and you do an API call to any APIs. And whenever it returns a response, you can sort of check out the schema. You can also do GraphQL API calls. You can also, which is my favorite part, is get types from it. And being a friend and developer who works with TypeScript throughout this whole day, it helps me a lot because it's sort of. Like responses are always unknown. You can never predict all the time how it's going to send the response or what response is it going to send. It can also frame. So based on the response that your API returns, our VS Code extension generates types automatically based on the schema of the response. And you can see if that schema or the types generated by the extension in your application and start referencing that. So... That is one thing that I have been using for building my next-gen application, like Rapid API Guides is a next-gen application which we have built where we write about API development stuff, like for example, how can you use GraphQL, how can you use GraphQL in an application, how you can use REST APIs, and they're not so popular in the startup environment, like SOAP APIs and other kinds of APIs, like async APIs. And we also have covered those things because we wanted to be like the MDN for API documentation or API kind of stuff. We also have another platform which is called RapidAPI Learn, which is rapidap.com.com. Where if you go, we have curated like how you can learn about GraphQL, how you can run What the hell is a REST API? What does it do?

 

Eh.

 

How can I use that? Because as a junior, as a beginner, you always hear about stuff like REST API, GraphQL API, but

 

Mm-hmm.

 

they don't have any clue. We have all

 

Yeah.

 

been in those shoes. So we wanted to build something which hand holds you throughout that whole journey and helps you understand that this is an API. This is how you do API calls. This is a REST API. This is a GraphQL. This is the difference. And if you're interested, this is the SOAP API, this is async API. Because even though we don't really use those last two, like async API or SOAP API, but it's always good to know about those things and what those things are.

 

Yeah.

 

And as a process, my job there was to build out this cute little Markdown components, an interactive Markdown components, where you can play with it. And then you can. just understand like, okay, you are doing an API call based on the click of a button that dot is going to the server and the server is returning some data, which is showing inside a monitor of sorts. So, you know, like it's not boring only about text and you just read it and then forget about it.

 

Mm-hmm.

 

It sort of like gives you the illustration of how this kind of stuff actually works.

 

Yeah.

 

And we also have rapid API courses where we work with like YouTubers where they create courses using how they can use rapid API APIs and build applications. So it's rapidapi.com slash courses

 

Cool.

 

Yeah, we sorry We also have one more thing which is rapid API comics if you haven't seen if you visit our Twitter twitter.com slash rapid underscore API you can see like we have Written a lot of comics which are illustrations to show how API works I think that is a really popular thing on twitter. I'd urge you to check it out if possible.

 

Yeah, no, in general, I think that your idea here, the company is a really, is I think you're onto something because I work in developer relations and as such, I build a lot of demo apps that need a lot of random APIs. And I can tell you from years of experience that it's the wild west. If you just go onto a Google search and go looking for an API, because you'll find stuff, but you'll find this API and you'll go, okay, what in the world is this? Does this even work? Because sometimes you'll find some API somebody built five years ago and isn't maintaining, or

 

Right.

 

it's like some flight status stuff, but it's only like returning like historic flights. Not like you, you don't know if you can trust it. You don't know how much it costs. Uh, you

 

You

 

don't

 

don't

 

know

 

know

 

if

 

if

 

it's

 

it'll

 

even going

 

exist?

 

to work.

 

Yeah.

 

Yes, exactly. So I like the idea of having a platform that kind of aggregates all of this. And it sounds like you have some really cool tooling and such around it. So, uh,

 

That's

 

Yeah,

 

a great

 

I wish

 

idea.

 

you the best because it sounds like a really good idea.

 

Yeah.

 

Uh, thank you. And that is exactly how I came to know about rapid API initially before I joined the company. I was trying to build something for my own blog. And when I was searching for something, rapid API popped up. And that's when I came to know about like, okay, something like this is there. Maybe use the free tag to build certain things, which I wanted to write tutorials about.

 

Yeah, I'm definitely gonna check this out in the future when I need something like this. But, I mean, we can talk to you all day because this has been really interesting and informative. But I think that we should try and wrap it up and get into the picks section. But before we do, where can people find you online if they want to get in touch or learn more or just talk to you about, you know, their own migration issues or API needs?

 

Definitely. So I can be found at twitter.com slash coach Nirmalia. So it's my surname before my first name. Sorry.

 

Mm-hmm.

 

It's github.com slash coach Nirmalia. So my surname before my first name and on Twitter it's my first name underscore first name last name underscore.

 

And we'll make sure to put links in the

 

Yes.

 

show notes. So.

 

Thank you, I appreciate that because I, you know, like it's on Twitter, I just wanted to have like the same thing on GitHub and everywhere, but

 

Yeah.

 

I couldn't find it. And it's difficult when you have a name, which is slightly difficult to pronounce.

 

We can relate.

 

Ha ha ha.

 

Alright, so we're going to move into the picks section of the show and this is where our hosts and our guests talk about things that they think are cool. Could be movies, could be kitchen tools, we've done a lot of those lately, could be, you know, good shows that you're watching or books that you're reading. So TJ, would you like to kick us off today?

 

Sure, I'm gonna pick an article that's titled Welcome to Hell, Elon on the verge. And I am, I don't know, I'm neither pro Elon or anti Elon, but I'm sort of pro chaos because I'm super entertained by all of the craziness of him acquiring Twitter and all the drama afterwards. And this article is just, it's somewhat of a comedic take on it, but it also like. walks through some of the actual logistical problems that come with content moderation and all the stuff behind Twitter. So it's written by a guy that used to be a copyright lawyer. So he has some background and some of the stuff that goes into that. So I check it out. If nothing else, it's just an amusing read. If you're as fascinated by all the Twitter dramas I am.

 

Nice, that sounds good. I mean, I have been watching the Twitter drama from afar and it seems to just be getting more dramatic. So that sounds

 

I'm sorry.

 

definitely like a good one. Normalia, would you like to give us a pick?

 

I was thinking about next year's week Astro, but we have been through that already. I mean, okay. Let's talk about it anyways, a little bit more deeper into it because, you know, like with the release of next year's 13th, last week or a few days ago, it, it struck me that, okay, everything's working fine. And one framework is taking inspiration from other frameworks. I mean, it's always nice to see that because. It's not the first time that it's happening because Angular sort of created something. React also had that view also copied certain things from Angular. React also copied certain things from view and Angular. Angular also did the same thing. So it happens like it cannot be like everything is from scratch and everything is from new. And when I noticed certain things like, okay, this is how it's happening. It's always a good thing because like for developers and for. people who want to get into this kind of system like juniors or someone who is in college and wants to get into certain things like this. Based on whatever is happening, it becomes very easy for them to understand like these are the topics that they need to understand because these are the popular ones and I don't think like it's a bad thing to take inspiration from other things because that's how designers design, that's how developers code. We copy paste stuff from Stack Overflow directly.

 

Hehehe

 

So, I mean, it's always fine to do something like that. And what I sort of want to say is that whatever happens on Twitter, on LinkedIn, or on any other place, I think for developers, it's always a very nice thing because they sort of understand like this. framework is like this, this framework is like this. You don't have to understand the differences, but if you want to build something, you want to get a job, you can work with certain things, which is the most popular at that point of time. And if next year's copy is certain things from some of the framework and other things, copies from certain other things, it's always good for us because we get the shiny new things. And personally, I'm very excited about the layouts, the new layouts because...

 

Mm-hmm.

 

That was one thing which I really liked about Remix. I really liked about Spell. I really liked about Astro. It was one thing just slightly difficult or needed more code in next-gen, but I'm very

 

Mm-hmm.

 

happy that it's there right now, and I cannot wait to play with it.

 

Nice. That is a good one. And I agree with you. It's, it's, everybody copies everything from each other, especially the things that users and developers tend to really like. So it's not, it's just nice to have those things and have that familiarity, even if it's a new framework that you're starting with, you know, being able to kind of connect the dots from something that you know, to something that's new, I think is really a good experience for developers. So yeah, I say, you know, take take all the good ideas from each framework and make the ultimate one, the next ultimate one from it.

 

how you definitely build applications using that.

 

Yeah. So my, oh, go ahead.

 

It's sort of like praising the other framework. Like, OK, this thing wasn't better in your system, but mine wasn't that great. So I copied it over. And it's always like giving sort of praise to other people. Like, for example, if I like someone and I get inspiration from him or her, I want to be like that person. It's a good thing. Like, I am inspired by that person. So it's always a nice thing.

 

Yeah, agreed. All right. So my pick for this week is going to be a TV show that I have been binging lately and that is, um, Star Trek, strange new worlds. So I've been on a Star Trek kick from next generation and then just forward and finally made it up to strange new worlds, which is one of their newest ones and man, even the, the jump in. in graphics and storytelling and everything from Enterprise, which was back in the early 2000s to now, is just amazing, especially when you've been watching it and then immediately go forward in time. So if anybody is looking for a new sci-fi series and you have not checked out Star Trek, I would say do like I did and start from Next Generation, which is know, Patrick Stewart and one of the best actors in the Star Trek franchise by far, but Strange New Worlds is awesome. The acting is great. The story is really good, and it was really a fun watch. So I'm looking forward to the next season that comes out.

 

Very fun.

 

Yeah.

 

Yeah

 

Well, I think that that is all we have for this episode of React Roundup. So Thank you for joining us, Normalia. It's been a pleasure to talk to you.

 

Happy to be here. It was great meeting and talking to both of you.

 

and we will see everybody on the next episode.

 

Bye everybody.

 

Bye, everyone.