Speaker 1: Hey, everyone, Welcome to another episode of React Roundup. I
Speaker 1: am your host today, Paige Needringhouse, and I am joined
Speaker 1: by our panelist TJ.
Speaker 2: Vantold.
Speaker 1: Hey everybody, and our special guest today is Akash Joshi. Akash,
Speaker 1: can you say hi to the audience and tell us
Speaker 1: a little bit about yourself why you're famous? But we're
Speaker 1: going to talk about today.
Speaker 3: Hey guys, So my name is Akash, and I think
Speaker 3: the thing that I might be famous for is talking
Speaker 3: a lot about myself and the things that I do online.
Speaker 3: And primarily I work as a React developer, and I
Speaker 3: try to simplify the complex things that I have learned
Speaker 3: and try to share that knowledge through my blog and
Speaker 3: through posts on places like record camp and YouTube. And
Speaker 3: that's primarily what I try to do.
Speaker 2: That's awesome.
Speaker 1: So what kind of complex things are you learning about
Speaker 1: that you're trying to help others get better at?
Speaker 3: So I think React itself might be a complex thing
Speaker 3: because we have a lot of web developers here in India.
Speaker 3: Most of my friends work in web development, but they
Speaker 3: never seem to go beyond just htmls yes, his, JavaScript
Speaker 3: and bootstraf and never go into the more productive parts
Speaker 3: of web development. Like being able to build applications at
Speaker 3: a much faster speed and in a much more scalable
Speaker 3: way using technologies like React. So that's where I try
Speaker 3: to position my content, and that's what I'm trying to do.
Speaker 4: So I'm curious before we get into some of the
Speaker 4: topics themselves, what got you into the teaching aspect of this.
Speaker 4: Was it doing running problems you ran into the work
Speaker 4: that wanted to help into others, or what made you
Speaker 4: want to actually blog and talk about some of these things.
Speaker 3: So, actually, I've been writing about things that I've learned,
Speaker 3: and I guess I mean, you could call it teaguing,
Speaker 3: but it was a way of noting down the things
Speaker 3: that I have learned myself. I started. I mean, am
Speaker 3: I allowed to name brands on here like hacker Noon
Speaker 3: and publications like that?
Speaker 1: Yeah?
Speaker 3: Yeah, So I kind of started by reading hacker Noon
Speaker 3: and it was kind of it used to be the
Speaker 3: highlight of the day for me looking at posts that
Speaker 3: people have written, and I saw that a lot of
Speaker 3: them were people my age who were just learning new
Speaker 3: things and writing about them. And that's how I myself
Speaker 3: got started. I started with learning note js and then
Speaker 3: contributing to a few open source repositories on GitHub, and
Speaker 3: as I learned new things while learning notejs, like, for example,
Speaker 3: how to publish your own NPM library for example, then
Speaker 3: I used to write articles on those things, and that's
Speaker 3: also what ended up. I mean, that's how I also
Speaker 3: got my first job, because people found out about me
Speaker 3: through my articles, And yeah, that's kind of how it's
Speaker 3: been progressing so far.
Speaker 2: That's fantastic.
Speaker 1: I've I didn't start writing until after i'd actually gotten
Speaker 1: my first job, so it was a little bit backwards
Speaker 1: to the way that you went about it. But I've
Speaker 1: definitely found that learning things at work and then writing
Speaker 1: about them really helps me, helps it solidify in my mind.
Speaker 1: And it also helps me when I've forgotten something like
Speaker 1: an article I wrote two or three years ago, I
Speaker 1: can go back and search through and find how I
Speaker 1: did something. So definitely multiple benefits for it. But like,
Speaker 1: what do you remember which articles it was that made
Speaker 1: your current or your employer reach out to you.
Speaker 3: Those were actually articles about to react. So I used
Speaker 3: to reach out to publications like CSS tricks on zero,
Speaker 3: and I think publications were more open back a few
Speaker 3: years ago to new writers and letting them write for
Speaker 3: them basically, So that's how I got started with it.
Speaker 3: Like through note js, I ended up learning React while
Speaker 3: contributing to an open source organization, and then I tried
Speaker 3: to translate some of those skills to an article and
Speaker 3: trying to explain how to learn React hooks, which were
Speaker 3: the big thing back in twenty eighteen, like the end
Speaker 3: of twenty eighteen. I think, so, yeah, that's how it
Speaker 3: got started. Cool.
Speaker 4: Well, I know one of the articles you had written
Speaker 4: is about structuring React projects, So I'm curious maybe you
Speaker 4: could walk people through roughly what you covering that in
Speaker 4: any advice you have to people, Because it's stretching React
Speaker 4: projects is not a small topic, right, There's lots of
Speaker 4: opinions around that. I'm curious what advice you have there.
Speaker 3: Right, definitely, So structuring React projects is one of the
Speaker 3: more recent articles that I've written, and I think it
Speaker 3: got more eyeballs on it, specially especially because it's such
Speaker 3: a polarizing topic. Everyone kind of has their own opinion
Speaker 3: on it, and they're willing to read about someone else's
Speaker 3: opinion and how I So, how I got started it
Speaker 3: with it was basically in my first job, the React
Speaker 3: the React projects that I was building weren't that complex,
Speaker 3: so I didn't really get a chance to get to
Speaker 3: the depths of React. But in my second job, I
Speaker 3: had to build uish which had to scale between various
Speaker 3: teams and so kind of while building upon the fundamentals
Speaker 3: that next JS has set in for the how a
Speaker 3: React project should be structured, I kind of added my
Speaker 3: own sort of small twists on top of that, and
Speaker 3: that's how I landed up at the project structure that
Speaker 3: I'm currently using. So should I walk through that what
Speaker 3: the project structure is?
Speaker 1: Yeah, definitely for anybody who hasn't read the article, which
Speaker 1: we will link to in the show notes, but yeah,
Speaker 1: it'd be great to hear what your what your take.
Speaker 2: On it it is.
Speaker 3: Yeah. So one of the first things is that to
Speaker 3: not clutter the root folder of the project. It's helpful
Speaker 3: to have all of your files separated into a specific
Speaker 3: source folder. And then I mostly talk about how various
Speaker 3: components of the project should be structured inside of the
Speaker 3: source folder. So the primary aspect of any web project
Speaker 3: is the routing. So next Days has a good way
Speaker 3: of maintaining routes through the pages folder, and I talk
Speaker 3: about that how you can create top level routes inside
Speaker 3: of these pages, but I don't recommend having any UI
Speaker 3: components or the code itself stored inside of these pages,
Speaker 3: but having separate component having a separate component folder, and
Speaker 3: then naming these folders according to the page or the
Speaker 3: set of pages where these components will be used, and
Speaker 3: then storing these components inside these name folder structures. And
Speaker 3: then I talk about other things like data adaptors and
Speaker 3: context stores. So data adaptors would be adaptors like in
Speaker 3: the adapter project adaptor pattern of writing code, where these
Speaker 3: would just be functions which you would call, and then
Speaker 3: the adapter in its own back end would then make
Speaker 3: any API call or any ware socket call, or any
Speaker 3: anything like that, and then return the data in whatever
Speaker 3: format that the original Collie expects. So I also recommend
Speaker 3: splitting those splitting the adapters folder into various folders and
Speaker 3: files according to the structure of the pages, and context
Speaker 3: stores would be Generally, context stores wouldn't be applicable to
Speaker 3: simple UH projects, but for more complex projects where generally
Speaker 3: people end up using data management library like React, UH,
Speaker 3: react context or reducts, then generally UH these context folders
Speaker 3: can hold the context stores for these for the set
Speaker 3: of pages and yeah, that's what I recommend there, and
Speaker 3: the rest of the article then just talks about how
Speaker 3: you can store your styles and public assets.
Speaker 4: So I'm curious, just because I haven't done much with
Speaker 4: next GS, how much does next enforce Because you said
Speaker 4: the pages folder is like a built in next GS thing.
Speaker 4: Are there other like special folders with that framework or
Speaker 4: is some of that just stuff that you made up
Speaker 4: for your recommendations.
Speaker 3: So there are two things which next Days enforces, which
Speaker 3: is having a pages folder for storing your routes and
Speaker 3: having a public folder to store all of the static
Speaker 3: asset files. And the rest of the things or the
Speaker 3: rest of the folders were something that I enforced myself,
Speaker 3: that I made up myself. I guess, yeah, gotcha.
Speaker 4: So it sounds like you're because usually I find that
Speaker 4: most folder structure there's almost like two different paths people take.
Speaker 4: Either you group your stuff by your files, by their
Speaker 4: type of file, their components, their adapters there, whatever the
Speaker 4: case is, or you group by feature, like you have
Speaker 4: a folder that this is my I don't know my navigation,
Speaker 4: or this is my widget, this is my menu, And
Speaker 4: it sounds like you prefer just grouping by feature, right,
Speaker 4: like components, adapters, that sort of thing.
Speaker 3: Right, So if you consider a set of files like
Speaker 3: catering to a particular feature, then yeah, I agree that
Speaker 3: it's kind of similar to grouping by a feature. But
Speaker 3: I've heard more. I mean, I've heard the counterargument that
Speaker 3: my full destructive actually goes counter to having your having
Speaker 3: story having to store your files in terms of features.
Speaker 3: So I guess it depends on how you see, how
Speaker 3: you look at your application.
Speaker 4: I guess yeah, And I think there's no like right
Speaker 4: or wrong way, because angular is very specific, just to
Speaker 4: give one example of they recommend not having folders like
Speaker 4: that because they'll tell you to do things like just
Speaker 4: just no name by features. But that, like, I don't
Speaker 4: think there's a right or wrong answer, because I've seen
Speaker 4: both get messy when you start to deal at scale,
Speaker 4: because then if you're grouping only by features, then in
Speaker 4: a complex app, it's like, well, which features are within
Speaker 4: what features? And like sometimes you'll have nested features and
Speaker 4: then you'll need to refactor them out of it. And
Speaker 4: I don't think there's a clean answer to this. But
Speaker 4: I always find it interesting what people come up with
Speaker 4: for best practices. I don't know, page would you do
Speaker 4: at the home depot if you have a folder structure
Speaker 4: that you've magically solved solved this problem with it all.
Speaker 1: I don't think that we have that at all. But
Speaker 1: the way that my team typically approaches it is we
Speaker 1: have a folder that is purely for the API calls
Speaker 1: that we call our service layer. We have one four components,
Speaker 1: which are the smaller pieces of a React application, like buttons, inputs,
Speaker 1: maybe even something as large as a table. And then
Speaker 1: we have containers which are kind of the I guess
Speaker 1: the pages quote unquote that a next day as project
Speaker 1: might contain, So it's things like our whole navbar or
Speaker 1: the main contents of a page. And then we have
Speaker 1: helper functions that are just used throughout the project, which
Speaker 1: are usually kind of plain JavaScript functions that might be
Speaker 1: used to format particular data or kind of transform it.
Speaker 1: We have hooks, which are the custom hooks that we
Speaker 1: use throughout different components in the application. But you know,
Speaker 1: it follows the Java pattern a little bit because most
Speaker 1: of our back end services are built using Java, and
Speaker 1: Java is very prescriptive and how it wants things done,
Speaker 1: so we lean on that a bit. But React is
Speaker 1: so unopinionated about it, really, however it works for you,
Speaker 1: is probably a pretty decent way to kind of filter
Speaker 1: your application.
Speaker 4: I think, Yeah, gotcha. I think that's why your article
Speaker 4: gets so much attention is because no one's really solved
Speaker 4: this and people like hearing other's opinions on the issue.
Speaker 1: Oh yeah, it's a great opportunity to just see how
Speaker 1: other people are approaching it, and maybe you can get
Speaker 1: something good out of it that you can take back
Speaker 1: to your own app.
Speaker 2: Totally.
Speaker 1: So, Akash, I was looking at your website, which I've
Speaker 1: also linked to, and I noticed that you're not only
Speaker 1: working full time. It looks like you've also got a
Speaker 1: couple of side projects, and I'd love to hear a
Speaker 1: little bit more about them, because you have a link
Speaker 1: to this thing called cash parser and also a link
Speaker 1: to product hunt, So can you tell us a little
Speaker 1: bit about what you're doing there.
Speaker 3: Yeah. So, gas Sponsor is a kind of fintech micro
Speaker 3: startup that I am running with a friend of mine.
Speaker 3: So he it's basically his being and I provide all
Speaker 3: of the front end help that he needs in going
Speaker 3: through that. So cast statements are basically consolidated account statements
Speaker 3: that get generated for all of the mutual funds that
Speaker 3: a person holds. So mutual funds are basically a set
Speaker 3: of stocks that people can buy, and a set of
Speaker 3: these mutual funds is stored in that cast statement, and
Speaker 3: we allow passing of that statement and generating the data
Speaker 3: in whatever format that the user needs. So that's where
Speaker 3: that's what cash pars is about. And on product hunt,
Speaker 3: I generally try to post about some fun side projects
Speaker 3: that I have I might have built. Like for example,
Speaker 3: I used to have a telegram bot which used to
Speaker 3: give notifications whenever a website changed. So I used to
Speaker 3: use this spot to track the results page for my university,
Speaker 3: and some other people did some other fun projects with it,
Speaker 3: like tracking the careers page of a place ef work
Speaker 3: that they wanted to work at or something like that,
Speaker 3: and so I had to take that brought down because
Speaker 3: it was too resource intensive. But I have made its
Speaker 3: API open and basically the other projects small small projects
Speaker 3: like this that I have found useful for myself, and
Speaker 3: then I try to put them on product and to
Speaker 3: try to get some other users for it.
Speaker 1: Yeah, that's very nice of you to share that kind
Speaker 1: of software because that sounds really useful for different.
Speaker 4: Things with sites here, where you would you just paying
Speaker 4: like a configurable amount like paying a site store. What
Speaker 4: was there and like if if it notices like any changes,
Speaker 4: then sends a message.
Speaker 3: Yeah, yeah, that's exactly what it used to do.
Speaker 2: Very cool.
Speaker 1: So are you continuing to work on side projects like
Speaker 1: this or is there anything else that you're doing, like
Speaker 1: I don't know, writing courses or kind of blogging more.
Speaker 1: What are you like, what are you most focused.
Speaker 3: On right now? Yeah? I think I'm too young to
Speaker 3: write a course or you know, ask payment for someone
Speaker 3: to teach them something, while there are like more smarter
Speaker 3: people who can who freely provide content for things that
Speaker 3: people want to learn about. So that's what I also
Speaker 3: tried to do earlier. I used to make side projects
Speaker 3: for fun, and later on it became that I wanted
Speaker 3: to try to monitor some of the work that I
Speaker 3: had done earlier and try to build on that. But then,
Speaker 3: I mean, when you're trying to monetize something, things start
Speaker 3: to become less fun because you have to worry about
Speaker 3: things like marketing. There might be search engine optimize, building
Speaker 3: landing pages, stuff like that. So then I kind of
Speaker 3: slowed that down a little bit, and now I'm creating content.
Speaker 3: Content that is that would be fun for me to make,
Speaker 3: if it makes sense. So when I feel like it,
Speaker 3: I write a blog. When I feel like it, I
Speaker 3: try to record a YouTube video. Now, editing a YouTube
Speaker 3: video is not fun. Recording can be fun.
Speaker 1: Sometimes I can totally relate to that.
Speaker 3: That's what I do.
Speaker 2: Nice.
Speaker 1: I can definitely relate to that, not the whole monetizing thing.
Speaker 1: But the second something goes from being just kind of
Speaker 1: like a hobby project too, and I must do this
Speaker 1: or get this to work, it's it's usually a lot
Speaker 1: less fun that way.
Speaker 4: Yeah, having lots of users is like a double edged sword.
Speaker 4: It's cool. But at the same time, then people have demands,
Speaker 4: especially if they're paying money then they have they have
Speaker 4: a lot more demands and.
Speaker 1: A lot more sway over what you'll actually do for them. Yeah, yeah,
Speaker 1: well that's cool. So what kind of day to day
Speaker 1: things do you get to use for your work with
Speaker 1: your company that you work for, Like what kind of
Speaker 1: tech stack and tools?
Speaker 3: So it might sound boring to some people that I
Speaker 3: get to work with React a lot, but it's actually
Speaker 3: really fun for me because JavaScript is how I got started,
Speaker 3: and React for me is the best expression of JavaScript
Speaker 3: and especially via typescript, where I can kind of automat
Speaker 3: aly most of my workflow. And then it's fun to
Speaker 3: think about how I can build something with the minimum
Speaker 3: amount of lines of code by trying to create the
Speaker 3: optimum function which can be reused everywhere, or basically reduce
Speaker 3: the amount of work that I would have to do
Speaker 3: to build something. So yeah, mostly I do get to
Speaker 3: work with reacting typeescript, and I hope to learn rest soon.
Speaker 1: I've heard a lot of people who seem to be
Speaker 1: jobs script developers kind of gravitating towards Rust. What's kind
Speaker 1: of drawing you towards it?
Speaker 3: So I especially like the functional programming paradigms inside of JavaScript,
Speaker 3: and I try to use them as much as possible.
Speaker 3: So when I look at last, I like most university
Speaker 3: students have of course learned CNC plus plus and nobody
Speaker 3: like after playing with modern programming languages, going back to
Speaker 3: that is not fun. But Rust is something different because it,
Speaker 3: even though it has some complex programming paradigms like it
Speaker 3: quite strictly defines the life cycles of a variable and
Speaker 3: you have to deal with things like borrowing memory values
Speaker 3: between variables. It's still fun because the kind of strictness
Speaker 3: that it applies is eventually what results in better, better
Speaker 3: code being written. But of course I don't speak this
Speaker 3: from my experience. This is just from things I've read
Speaker 3: on link. But more experienced Trust developer would probably be
Speaker 3: able to give this answer better. But yeah, that was
Speaker 3: my opinion on this.
Speaker 2: It's funny page.
Speaker 4: You're right, I feel like Rust is the cool thing
Speaker 4: for JavaScript developers to do. I feel like we missed
Speaker 4: the memo here at some point because I haven't gotten
Speaker 4: into Rust at all. But I also think like it's
Speaker 4: funny that a lot of JavaScript tooling is now starting.
Speaker 4: There's like some Rust based tools that are supposedly faster
Speaker 4: that are starting to become more popular. So it's going
Speaker 4: to be interesting to see how that changes over time.
Speaker 4: Maybe I'll have to learn it too.
Speaker 1: I now I hear this kind of stuff pretty regularly,
Speaker 1: like Rust Go. But I guess my problem is a
Speaker 1: time management one where I use Java and I use
Speaker 1: React mostly for my job, and so that's what most
Speaker 1: of my time goes towards, is those two programming languages.
Speaker 1: I've used Python a little bit. I'd like to learn Go,
Speaker 1: I think, because I've heard really good things about it.
Speaker 2: But it's there's just so.
Speaker 1: Many languages and so little time to learn them and
Speaker 1: then apply them, I guess, is the main thing.
Speaker 4: Yeah, And I think like, at least for me, I
Speaker 4: have to have a reason to do it, right, like
Speaker 4: if I have a project in mind, and Akash, like,
Speaker 4: it's interesting hearing some of your stories too, because you're
Speaker 4: like a lot of these side projects came out of
Speaker 4: actual problems you had or things that you wanted to do,
Speaker 4: which is always interesting to see because at least for me,
Speaker 4: and I don't know about you too, but I can't
Speaker 4: just sit down and say, like, well, I'm going to
Speaker 4: learn erlink today, right, Like if I do that, like
Speaker 4: there's no amount of focus the world that's going to
Speaker 4: get me to learn earlang. But if I had like
Speaker 4: some problem that I needed to solve in my life
Speaker 4: or for my job, and like, okay, sure, like that
Speaker 4: gives my brain a reason to sit down and focus
Speaker 4: and do it.
Speaker 2: Absolutely.
Speaker 1: I tried that with Haskell one time because a programmer
Speaker 1: who I work with had a senior developer he had
Speaker 1: recommended it as a good way to kind of get
Speaker 1: your feet wet with functional programming. And I made it
Speaker 1: through I don't know, maybe three two or three chapters
Speaker 1: of getting started with Haskell book and then just put
Speaker 1: it down and never picked it back up again.
Speaker 2: So yeah, you definitely have to have.
Speaker 1: Something that you're trying to solve, not just trying to
Speaker 1: learn for the fun of I think.
Speaker 4: Actually, Akasha, I'm curious because you said that you had
Speaker 4: kind of liked the functional style of programming, and I'm curious,
Speaker 4: is that come from like work experience or school, because
Speaker 4: I say this as someone that functional is never totally
Speaker 4: clicked from me, and maybe like because like page, I
Speaker 4: came from a Java background, and Java is very much
Speaker 4: not I mean, there's you can kind of do some
Speaker 4: functional things, but it's very much not a functional language really,
Speaker 4: so I struggled to get my brain to work that way.
Speaker 4: So I'm curious why, like, what made you interested in
Speaker 4: that approach.
Speaker 3: Yeah. So I didn't pick up functional programming in university
Speaker 3: because most of the university classes are based on objectory interprogramming.
Speaker 3: But where I initially started picking up functional programming was
Speaker 3: again when I was reading Hacker Moon back then, and
Speaker 3: there were a lot of articles written about things like
Speaker 3: I guess monads, which nobody really understands. But then there
Speaker 3: were things about like topics like composibility of functions and immutability.
Speaker 3: So immutability and pure functions. Those are the two things
Speaker 3: which really got me into functional programming because then I
Speaker 3: could write code, which wasn't surprising kind of so in
Speaker 3: seeing you end up writing code which you don't understand
Speaker 3: what it does, like at least I used to, because
Speaker 3: I couldn't try see well, I guess. But with functional programming,
Speaker 3: I could write JavaScript, which even if I come back
Speaker 3: to later, I could still understand what it does basically.
Speaker 3: And I that's also kind of how I got into
Speaker 3: open source, because I see that open source repositories, which
Speaker 3: are written in a more functional way, are generally more
Speaker 3: readable because everything has its own like, everything is separated
Speaker 3: into its own concern kind of yes, And I'm not
Speaker 3: sure if the exact terminology here.
Speaker 4: Yeah, that makes sense.
Speaker 1: Yeah, I think I think we get kind of the
Speaker 1: separation of concerns is what you're an encapsulation, I guess.
Speaker 3: But I guess. I mean these two terms are generally
Speaker 3: used for dictorian in the programming do so yeah.
Speaker 4: Yeah, I feel like functional programming is like a cult
Speaker 4: that I haven't gotten an invite into because everybody, like
Speaker 4: I feel like, once you've drank the functional kool aid,
Speaker 4: like you can't stop talking about it and you start
Speaker 4: recommending has scale to your co workers and like like
Speaker 4: all this stuff, and I still like, I still like, see,
Speaker 4: I've heard the term monad literally hundreds of times, right
Speaker 4: and if you ask me right now to explain to
Speaker 4: you what a monad is, I couldn't even try, Like,
Speaker 4: I will not nothing, nothing will come out interesting. So
Speaker 4: it's actually I find it quite interesting that, like just
Speaker 4: from some articles that you were able to pick up
Speaker 4: on that, because it's, at least to me, it's pretty impressive.
Speaker 1: Yeah, Like, currying is something that I know is is
Speaker 1: very big and functional, and I can understand the general
Speaker 1: idea of it, but then actually trying to put that
Speaker 1: into practice in my code somewhere is a very large
Speaker 1: challenge to me.
Speaker 4: Still, yep, exactly.
Speaker 1: But it's definitely super powerful when you know what you're doing.
Speaker 1: I've seen some really just great, great code written from it.
Speaker 1: But man, the people who know how to do that
Speaker 1: and can visualize it ahead of time hats off to you.
Speaker 1: That's a great skill to have for sure.
Speaker 4: So cash another thing you've got you have and your.
Speaker 3: Getting I would definitely not put myself into the leagues
Speaker 3: of great functional programmers because Monald is something which I
Speaker 3: can still not explain. Currying is something I generally don't
Speaker 3: use myself. But just with immutability and writing pure functions,
Speaker 3: which is like functions which only have one use case
Speaker 3: and don't affect any values outside of the function except
Speaker 3: for the ones which are provided as input to it,
Speaker 3: I mean, just by these two concepts, you can go
Speaker 3: pretty far in functional programming, is what I feel very cool.
Speaker 4: But there's another project on your GitHub that I wanted
Speaker 4: to bring up. Is you have this project called functions
Speaker 4: without Borders. Maybe you could tell us a little bit
Speaker 4: about what this is in what you're trying to solve
Speaker 4: with this this project.
Speaker 3: Yeah, so functions without Borders was built to again solve
Speaker 3: a problem that I had. I basically hate writing server
Speaker 3: side interfaces because a lot of time gets spent in
Speaker 3: doing that. Like whenever I have to write something, I
Speaker 3: have to write ten httpa API. What is it called?
Speaker 3: If I write it on the server side, like an
Speaker 3: end points or yeah, I have to write a lot.
Speaker 3: I end up having to write a lot of endpoints
Speaker 3: and then a lot of getters on the client side.
Speaker 3: So what this library does is it kind of abstracts
Speaker 3: away everything and it also mixes in a lot of
Speaker 3: typescript to basically make a server side ATI calls fail
Speaker 3: like a native function call on the client side, So
Speaker 3: it allows you to use the same typescript types between
Speaker 3: the client and the server. So while defining your server,
Speaker 3: if you're using a set of types, then you can
Speaker 3: pass the same types to the client side also, and
Speaker 3: then basically you can call those functions on the client
Speaker 3: as if they were written on the client itself. But
Speaker 3: actually the library makes a web socket call and then
Speaker 3: gets the data from the server.
Speaker 2: Very cool.
Speaker 1: So it's like your own version of server side rendering.
Speaker 3: Yeah, I guess.
Speaker 4: So then where do you deploy the server code too?
Speaker 4: Is it just like any like is it like a
Speaker 4: Lamba city situation or where would the server code end up?
Speaker 3: I don't think. I mean, I haven't tried deploying it
Speaker 3: to any server less library yet, but it's mostly about
Speaker 3: a server full situation where you might have a server
Speaker 3: constantly running and then the client can be anything. It
Speaker 3: can be a browser, or it can be another server
Speaker 3: or wherever you want to run it on. Basically very cool.
Speaker 1: So, Akash, is there anything that we haven't covered yet
Speaker 1: that you think that you'd.
Speaker 2: Like to talk about?
Speaker 3: I don't think so. I've covered mostly everything that I'm
Speaker 3: passionate about what I like to learn and talk about.
Speaker 3: I guess yeah.
Speaker 2: Very cool.
Speaker 1: So if people would like to get in touch with you,
Speaker 1: what are the best ways.
Speaker 3: They can reach out to me? On Twitter? At the
Speaker 3: writing dev. They can check out my blog at the
Speaker 3: writing dot dev where they can subscribe to my blog,
Speaker 3: and if they reply to any of the emails, the
Speaker 3: reply actually reaches to me directly.
Speaker 2: Very very cool, awesome.
Speaker 1: So I think this is the point in the show
Speaker 1: where we're going to move into picks and we'll share
Speaker 1: things that we've been using that we're fans of things.
Speaker 1: It could be a site that you've found, a product
Speaker 1: that you like, basically a show you've watched that you've enjoyed. So, TJ,
Speaker 1: would you like to start us off this week?
Speaker 4: I can start us off yeat. So my pick for
Speaker 4: this week is going to be kombucha. There's no page Akasha,
Speaker 4: you have you had kimbucha before? Do you get the reference.
Speaker 1: I have not tried it, but I've seen it at
Speaker 1: the grocery store.
Speaker 4: Okay, So I had never tried it in my life.
Speaker 4: I didn't know yeah ferm entity, which I couldn't totally
Speaker 4: explain exactly what it is. So I'm glad you know
Speaker 4: more about it than I do, apparently, but the i'd
Speaker 4: heard of it before in a fee shot near me
Speaker 4: had it, so I was like, what the heck, let's
Speaker 4: let's try it. And it was I think it started
Speaker 4: a new obsession of mine because I just went to
Speaker 4: the store and bought a whole bunch of it because
Speaker 4: it's quite good. It's it's since it's tea based, it's caffeinated,
Speaker 4: but it's got just a little bit of caffeine right.
Speaker 4: So I've I've had a bit of a coffee problem lately,
Speaker 4: where working from home, the coffee consumption was getting a
Speaker 4: little out of control, and I've really enjoyed kombucha. The
Speaker 4: place near me has it in a lot of different flavors.
Speaker 4: So if you haven't tried it before, Paige, you might
Speaker 4: want to just get some from the grocery store.
Speaker 2: Just to say.
Speaker 4: You say you've done it.
Speaker 1: I will definitely give that a try now that I
Speaker 1: know somebody who is a fan of it. Is there
Speaker 1: a particular flavor that you've liked.
Speaker 4: I like the fruit based ones Akasha. I don't know
Speaker 4: if you have any. Let me see if I can
Speaker 4: dig up exactly which one. I've Hadasha's kombucha popular in
Speaker 4: India around you Mark Randy.
Speaker 3: I had kind of found it in a norveety Japanese book, So,
Speaker 3: I mean, it's a bit expensive, but it's really tasty
Speaker 3: at least I think the taste is quite different from regularity,
Speaker 3: so it's fun to drink.
Speaker 4: Yeah, So I've had some that are like cherry based. Interestingly,
Speaker 4: it was quite good and like like a cranberry orange
Speaker 4: one as well that I like. So that the fruity
Speaker 4: ones I thought worked really well. So that's that's my pick.
Speaker 2: Nice, I like it. I will go next. TJ.
Speaker 1: You've inspired me with your choice of kombucha. I will
Speaker 1: choose a loose leaf earl gray tea that I recently
Speaker 1: found and I've been drinking just typical tea bags of
Speaker 1: Earl Gray probably about the past year or so. My
Speaker 1: husband has been doing it since he was a kid,
Speaker 1: and since I've been working from home also, and we
Speaker 1: work from home together. We will now have tea at
Speaker 1: about three o'clock and take a quick break and just
Speaker 1: kind of check in and see how the other one's doing.
Speaker 1: But recently we've upgraded from the tea bags to this
Speaker 1: loose leaf version from Harney and Sons, and wow, what
Speaker 1: a difference that day. It's It's definitely got a lot
Speaker 1: of extra flavor in it. It's a little bit more
Speaker 1: involved because you can't just dunk the bag and you
Speaker 1: have to have a little tea strainer that you put
Speaker 1: in your cup. But I think it's really worth it.
Speaker 1: It's been really, really enjoyable. So that's what I would
Speaker 1: recommend today. If we're going along the eating and drinking route.
Speaker 2: It's available on Amazon.
Speaker 1: It's not too too expensive and you can certainly get
Speaker 1: a pretty decent amount of it for the price. So
Speaker 1: I'm going to go with Harney and Son's Earl Gray
Speaker 1: Tea and Akash. Do you have anything that you'd like
Speaker 1: to share?
Speaker 3: Yeah, I don't have anything, especially on the eating and
Speaker 3: drinking side, since the lockdown has stopped all of the
Speaker 3: random things that I used to eat. But what I
Speaker 3: would recommend is a label MIC. So I'm using one
Speaker 3: right now, and it dramatically improves the audio quality that
Speaker 3: I have in zoom calls and video calls or you know,
Speaker 3: while just recording audio on for my YouTube channel or
Speaker 3: anywhere else. So yeah, I would recommend having a label
Speaker 3: MIC as a starter kit for a YouTube channel.
Speaker 2: I guess fantastic. That's always good.
Speaker 1: I think people are always looking for good microphones, good cameras,
Speaker 1: good good, all that stuff, especially since our lives are
Speaker 1: very video driven nowadays.
Speaker 2: Very cool.
Speaker 1: So we'll have a link to that in the show notes,
Speaker 1: and we will have all of your links where people
Speaker 1: can reach you, see some of your articles, check out
Speaker 1: your website as well. So thank you so much for
Speaker 1: joining us today. It's been really fun to talk to you.
Speaker 3: Thank you, guys, it's been fun talking with you also excellent.
Speaker 1: So we will see you next time on the React
Speaker 1: Roundup Show By everyone,