MovieDex - My first React project!

#showdev #beginners #react #node

A React and Node.js app that searches for movies using the TMDB and OMDB database ⚛✨🎥. Try it out here: MovieDex

The Project

I came across this article: 9 Projects you can do to become a Frontend Master in 2020 while I was browsing around Dev and I wanted to build the first one in the list and so I did!

I made the first prototype in a single sitting. My app was able to search for movies and display them. Great!

But I wanted to amp things up!

I thought what if you even showed the movies details in form of modals?

And here you are, an app that searches movies and gives you the relevant details!

Powered by ✨

Node.js : A server for handling all the API calls to the TMDB and OMDB API. I did not implement the calls in the client side as they involved calling with secret API keys.
React : What I really focused on in this project. ⚛💙
Material-UI : Absolutely loved the components! Some of the components I've used in this project are: Card, TextField, Dialog and my personal favorite, Skeleton loaders.
The Movie Database : For searching the movies.
Open Movie Database API : For extensive data. (Ratings were not provided by TMDB API).
Logo by me. Font used: BLANKA. Some Photoshopping around and Ta-da! 😂

Some background about my React journey:

I started learning React in the beginning of July, I guess?
My learning sources included the awesome React tutorial by Codevolution on YouTube and the official React docs and some random but highly insightful blog posts by various authors.

I highly recommend the above mentioned tutorial.

I hope to make better and bigger things in the future! Continually learning and improving. If you like the project, please consider giving it a star on GitHub and sharing!😇 Any suggestions and feedback is greatly appreciated. 😄

Top comments (17)

ecyrbe • Aug 7 '20

Hi,

Nice work. Here is a succinct review.

in server.js try to follow REST resource naming conventions : restfulapi.net/resource-naming/
to not have your heroku instance spammed, you should protect your server APIs with jwt access with resource limiting for each distinct user. Refuse to answer requests without a jwt. Jwt : jwt.io/
in client, you are using the same pattern everytime with fetch/abortController. I would create a new hook called useAbortableFetch to wrap and reuse this Idea.

Abhijit Hota • Aug 7 '20

Hello and thanks a lot for the points!

I did not know about the REST API naming conventions. I'll surely follow the guidelines. Most of my requests are verbs like getMovies and getMovieDetails like functions. I'll change them to nouns as per the guidelines. (I haven't read the guidelines fully so I may come up with something more appropriate).
I do not understand why would I need JWTs here.

Refuse to answer requests without a JWT.

But can you elaborate why would I need that? What exactly does "not have your Heroku instance spammed" mean?

Any pointers will be appreciated. 😄

Yes. I agree that part of the code is little WET. I was thinking the same while coding that part. A custom hook is a very good way indeed!

Thanks again for digging deep into the code and writing this! 😄

ecyrbe • Aug 7 '20

I do not understand why would I need JWTs here

OK. Imagine that i'm a hacker wanting to shut down your website and deny to all your users the ability to request anything.

How would i do that ? as your project is open source i can see that your APIs are not protected. So if i spam your server with requests, i will for sure encounter the limits that where granted to you via your API key.

So ONE user can deny access to your APIs to ALL your users.

To mitigate that, what you usually want is to only deny the spamming user access to your APIs. for this you need to give the user a unique id and require each user to access your API with this id.

You can rate limit users based on their IP address (but if many different users are behind the same adress you will block all the legitimate users behind the adress),
You can rate limit users based on a unique id for each user behind the same IP adress by giving them a distinct JWT. In server side you create an id for a user (with IP inside as payload for exemple) and sign it by encapsulating it in a JWT. You then just check that this JWT is valid, and you should also give this JWT an expiration time (5 minutes to 20 minutes might be a good idea). Note that you need to use asymetric algorithm (like RS256) to really protect an API with JWTs.

Using the user IP for starting is fine, so you are rigth, you don't need JWT, but for more fine grained propection i would use a JWT that combine IP/expiration date to protect you APIs.

Now for your API you can plug a rate limiter middleware, like this : github.com/animir/node-rate-limite...

You can use a memory store instead of redis to not need another server.
You can use a jwt instead of user ip to check access.

Abhijit Hota • Aug 7 '20

Thanks for the detailed explanation.
I understood what you are saying. I'll start implementing the said method of JWTs along with the IP as a payload. I'll figure out a good way.

I'll check the mentioned middleware too.

Thanks a lot again!