Using Libraries or Frameworks for Data Fetching
Going through the problems with other libraries
Get the project source code below, and follow along with the lesson material.
Download Project Source CodeTo set up the project on your local machine, please follow the directions provided in the README.md
file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.
Lesson Transcript
[00:00 - 00:15] We've previously spoken about why you shouldn't use the Use Effect hook for data fetching, and in this video we're going to talk about why you might not want to use a framework or library to fetch data. Let's first talk about libraries.
[00:16 - 00:38] Libraries in general are a great way to add functionality to your app very quickly, and most of them are really well maintained, but there are a few reasons why you might not want to use them. The first reason is that they might not be well maintained, and a library that is well maintained now might not be well maintained in the future.
[00:39 - 00:50] If there's an issue with security in the library that you're using, then you'll have to wait for the maintainers to fix it. This could take a while, and in the meantime, your app could be at risk.
[00:51 - 01:01] If you work in finance, health, government, or any of those security conscious companies, then this could be a big problem. In fact, this was a problem in a finance company I worked at in the past.
[01:02 - 01:22] We used a static analysis tool to check for security issues in our code and dependencies, and because we used a lot of packages, some of these packages had security issues. We either had to get a different package or declare that it was a known issue, which was a really long and somewhat embarrassing process.
[01:23 - 01:35] The second reason that you might not want to use a library is that libraries are not that flexible. Imagine that you're using a library to fetch data, and you have to do something that the library doesn't support.
[01:36 - 01:51] You either have to file an issue and wait for the maintainers to add it, or you 'll have to fork the library and add it yourself. This is an ideal since you could miss out on important updates from the library , and you may have to maintain it yourself.
[01:52 - 02:07] A third reason you may not want to use a library for data fetching is that it could send extra data to the client. Now, I don't want to pick on a specific library, but I do know that these data fetching libraries have a lot of features.
[02:08 - 02:33] If you're only using a small feature set of that library, like you're doing some simple data fetching, then you could be adding a lot of extra code to your app. Now I know that modern bundlers like VIT or Turbo Pack have tree-shaking built in, but if you're using a library that hasn't been written with tree-shaking in mind, or if you're not using a modern bundler, then you could be adding a lot of code to your app.
[02:34 - 02:50] Okay, so those are some reasons you might not want to use a library or package for data fetching, but what about a framework? Well, a full stack framework like Next.js or Remix can solve the issue of bloat since data fetching can be done on the server.
[02:51 - 03:02] This means that a small amount or no.js is sent to the client, which is great. But there are a few other reasons why you might not want to use a full stack framework.
[03:03 - 03:24] If you're building a client-side-only app, then there are a few benefits of a framework like routing, code spitting, etc, but you may not need all of those features. A full stack framework is great for server-side rendering and a static site generation, but for a basic client-side app, it could be a bit much.
[03:25 - 03:46] If you have a server-side app built with a framework and you want to do client- side data fetching to give it a mobile app-like feel, then you still may need to use a library to do that. If you use Remix, then that pretty much has React through to build into it, so you can go ahead and use that functionality to do client-side data fetching.
[03:47 - 03:59] And if you use Next.js, well, for self-recommend using SWR since that's what they built. But for other full stack frameworks, you're going to have to use a library or the use effect hook.
[04:00 - 04:08] Now I'm not saying that you shouldn't use a library or framework for data fetch ing. In fact, I use Lexus all the time and I think it's great.
[04:09 - 04:22] However, I want to highlight the fact that there are certain scenarios where you might not want to or wouldn't be able to use a library or framework for data fetching . Okay, so let's recap some of those points.
[04:23 - 04:31] The first point is about security vulnerabilities or updates. If you have a library, you need to make sure you're always updating it so that your code isn't at risk.
[04:32 - 04:51] And if you want to do something that a library doesn't support, you have to file an issue to the maintainer or you can try and add it yourself. But that will take a long time for you to figure out how the library works to add the feature or the maintainer might not even have time to add the feature in the first place, so it might never get added.
[04:52 - 05:04] Library could add bloat to your app, so you need to keep that in mind if you want to use it just for simple data fetching. And if you're building a mainly client-side app, you may not need all the features a full stack framework provides.
[05:05 - 05:19] Another reason is if you're a beginner and you just want to know how to fetch data without using these effects hook, the React team doesn't give you a good solution. So if these are all things that you want to solve, then this is the right course for you.
[05:20 - 05:33] I'm going to show you how to fetch data in a performant way without using a library or framework and in a few lines of code. This data fetching technique will address all the issues raised in the React documentation.
[05:34 - 05:41] It's going to be small and easy to understand, which means you can customize it however you want. Sounds exciting, right?
[05:42 - 05:43] Well in that case, let's get started.
[00:00 - 00:15] We've previously spoken about why you shouldn't use the Use Effect hook for data fetching, and in this video we're going to talk about why you might not want to use a framework or library to fetch data. Let's first talk about libraries.
[00:16 - 00:38] Libraries in general are a great way to add functionality to your app very quickly, and most of them are really well maintained, but there are a few reasons why you might not want to use them. The first reason is that they might not be well maintained, and a library that is well maintained now might not be well maintained in the future.
[00:39 - 00:50] If there's an issue with security in the library that you're using, then you'll have to wait for the maintainers to fix it. This could take a while, and in the meantime, your app could be at risk.
[00:51 - 01:01] If you work in finance, health, government, or any of those security conscious companies, then this could be a big problem. In fact, this was a problem in a finance company I worked at in the past.
[01:02 - 01:22] We used a static analysis tool to check for security issues in our code and dependencies, and because we used a lot of packages, some of these packages had security issues. We either had to get a different package or declare that it was a known issue, which was a really long and somewhat embarrassing process.
[01:23 - 01:35] The second reason that you might not want to use a library is that libraries are not that flexible. Imagine that you're using a library to fetch data, and you have to do something that the library doesn't support.
[01:36 - 01:51] You either have to file an issue and wait for the maintainers to add it, or you 'll have to fork the library and add it yourself. This is an ideal since you could miss out on important updates from the library , and you may have to maintain it yourself.
[01:52 - 02:07] A third reason you may not want to use a library for data fetching is that it could send extra data to the client. Now, I don't want to pick on a specific library, but I do know that these data fetching libraries have a lot of features.
[02:08 - 02:33] If you're only using a small feature set of that library, like you're doing some simple data fetching, then you could be adding a lot of extra code to your app. Now I know that modern bundlers like VIT or Turbo Pack have tree-shaking built in, but if you're using a library that hasn't been written with tree-shaking in mind, or if you're not using a modern bundler, then you could be adding a lot of code to your app.
[02:34 - 02:50] Okay, so those are some reasons you might not want to use a library or package for data fetching, but what about a framework? Well, a full stack framework like Next.js or Remix can solve the issue of bloat since data fetching can be done on the server.
[02:51 - 03:02] This means that a small amount or no.js is sent to the client, which is great. But there are a few other reasons why you might not want to use a full stack framework.
[03:03 - 03:24] If you're building a client-side-only app, then there are a few benefits of a framework like routing, code spitting, etc, but you may not need all of those features. A full stack framework is great for server-side rendering and a static site generation, but for a basic client-side app, it could be a bit much.
[03:25 - 03:46] If you have a server-side app built with a framework and you want to do client- side data fetching to give it a mobile app-like feel, then you still may need to use a library to do that. If you use Remix, then that pretty much has React through to build into it, so you can go ahead and use that functionality to do client-side data fetching.
[03:47 - 03:59] And if you use Next.js, well, for self-recommend using SWR since that's what they built. But for other full stack frameworks, you're going to have to use a library or the use effect hook.
[04:00 - 04:08] Now I'm not saying that you shouldn't use a library or framework for data fetch ing. In fact, I use Lexus all the time and I think it's great.
[04:09 - 04:22] However, I want to highlight the fact that there are certain scenarios where you might not want to or wouldn't be able to use a library or framework for data fetching . Okay, so let's recap some of those points.
[04:23 - 04:31] The first point is about security vulnerabilities or updates. If you have a library, you need to make sure you're always updating it so that your code isn't at risk.
[04:32 - 04:51] And if you want to do something that a library doesn't support, you have to file an issue to the maintainer or you can try and add it yourself. But that will take a long time for you to figure out how the library works to add the feature or the maintainer might not even have time to add the feature in the first place, so it might never get added.
[04:52 - 05:04] Library could add bloat to your app, so you need to keep that in mind if you want to use it just for simple data fetching. And if you're building a mainly client-side app, you may not need all the features a full stack framework provides.
[05:05 - 05:19] Another reason is if you're a beginner and you just want to know how to fetch data without using these effects hook, the React team doesn't give you a good solution. So if these are all things that you want to solve, then this is the right course for you.
[05:20 - 05:33] I'm going to show you how to fetch data in a performant way without using a library or framework and in a few lines of code. This data fetching technique will address all the issues raised in the React documentation.
[05:34 - 05:41] It's going to be small and easy to understand, which means you can customize it however you want. Sounds exciting, right?
[05:42 - 05:43] Well in that case, let's get started.