Peachy: A Social Network made in React Native

calendar_today Posted 1 year ago · 8 minute-read · Showcase

Today I’m show­cas­ing the mobile app I built for Android and iOS for my final-year project using React Native plus a few oth­er JavaScript tech­nolo­gies.

I want­ed to build kind of a social net­work for mobile, but with a twist: you need­ed to chat with some­body for a while to be able to view their pro­file pic­ture and infor­ma­tion.

I thought about all the fea­tures the app would have:

  • Typ­i­cal login, reg­is­tra­tion, account recov­ery pages.
  • A place to “Dis­cov­er” peo­ple that are already on the plat­form, through cards (Tin­der-like aes­thet­ics).
  • A real-time chat to be able to com­mu­ni­cate with peo­ple you met from the “Dis­cov­er” page.
  • User loca­tion han­dling to show cards from peo­ple that are near the user.
  • A “flag­ship” fea­ture: Unlock­ing user pro­file infor­ma­tion grad­u­al­ly by engag­ing in con­ver­sa­tion.

The idea was to make the app cross-plat­form. I knew how to build Android apps, but I felt like learn­ing a new frame­work this time. I also have lit­tle to no expe­ri­ence with iOS devel­op­ment.

I found out about React Native, but the chances I’d choose it for devel­op­ment were very slim: I did­n’t know any­thing about React, and that meant I had to learn React and its ecosys­tem, how to “think in React”, and then learn React Native.

We did­n’t real­ly have much time for the project either, about a month. And I want­ed to bake a ful­ly-work­ing social net­work, along with its doc­u­men­ta­tion.

I final­ly decid­ed to learn React Native and build the whole app with it. Woohoo! 🎉

Getting to work! 🛠

I had to decide which libraries I was going to use for the React Native client though, which was­n’t an easy task. I end­ed up choos­ing the fol­low­ing:

  • MobX for State Man­age­ment. I did­n’t real­ly under­stand Redux at the time so I went towards the more famil­iar object-ori­ent­ed approach with Mobx. Nowa­days all I can use is Redux 🤣.
  • React Nav­i­ga­tion for UI nav­i­ga­tion.
  • Native React Web­Sock­et APIs for the real-time chat­ting expe­ri­ence.
  • Native React Fetch API for com­mu­ni­cat­ing with the back­end.
  • rn-fire­base for Push Noti­fi­ca­tions, a very impor­tant fea­ture in this app.

That’s about it for the client. I usu­al­ly build the back­end before doing the client though, and I decid­ed to go with Node.js. I had used it a lot in the past, and I thought it would be neat to keep all the code­base in JavaScript.

Here are the libraries I used for my Node.js back­end:

  • Express.js for build­ing the API: Data­base <=> Express API <=> React Native REST Client.
  • Mon­goose ORM for Mon­goDB. I thought Mon­go would be the best choice for this project since it’s a fast-paced app, lots of data­base writes in short time-spans, and that is where Mon­go excels.
  • A reverse geocoder to find out the users loca­tion on coun­try and city lev­els. The back­end receives the user’s coor­di­nates obtained from the React Native client and returns the user’s city, coun­try, time­zone, and oth­er use­ful info. This worked with great accu­ra­cy (and is free!) but was very CPU-inten­sive. This end­ed up being a bot­tle­neck − my serv­er at the time was­n’t that pow­er­ful.
  • node-ws pack­age for duplex Web­Sock­et com­mu­ni­ca­tions.

Figuring out the authentication flow 🍃

So, I had all my libraries sort­ed out, and now I had to sort out the app’s archi­tec­ture − decid­ing how it was going to work as a whole.

Authen­ti­ca­tion is one of the first things that, in my opin­ion, you must sort out at the begin­ning of any devel­op­ment. There were essen­tial­ly two parts to pro­tect in this app: A REST API-dri­ven part, and a real-time, Web­Sock­et-dri­ven part. The client had to be authen­ti­cat­ed on both com­mu­ni­ca­tion chan­nels for the app to be secure. Here’s how I did it:

Peachy’s authen­ti­ca­tion flow
  1. User opens the app and imme­di­ate­ly starts a Web­Sock­et con­nec­tion to the serv­er, which will return a uniqueID to iden­ti­fy the client and its sock­et.
  2. User logs into the app. The REST client asks the serv­er for a JSON Web Token (JWT) with a default expi­ra­tion time of 6 hours.
  3. The serv­er authen­ti­cates the clien­t’s sock­et with the gen­er­at­ed JWT and returns a response to the REST Client with it.
  4. Now the client can receive mes­sages from the serv­er through a ful­ly authen­ti­cat­ed bi-direc­tion­al Web­Sock­et con­nec­tion and can access the pro­tect­ed resources of the Express REST API serv­er.
  5. The client per­sists the JWT in the mobile phone’s stor­age for future use until expi­ra­tion.

Once authen­ti­cat­ed with a valid, non-expired JWT, a client could then access pro­tect­ed resources, and receive real-time data.

React Native client access­ing a pro­tect­ed resource on the serv­er

Here’s an exam­ple of real-time chat­ting using Peachy’s archi­tec­ture, giv­en two users React Native Client 1 and React Native Client 2:

Designing the database 🤔

The data­base design was pret­ty straight-for­ward:

The ER Dia­gram for Peachy’s data­base

It basi­cal­ly had 5 enti­ties:

  • User: Rep­re­sents a user of the app, ONLY con­tains the nec­es­sary data for the user to authen­ti­cate itself.

  • Pro­file: The user’s pro­file. I want­ed to sep­a­rate this enti­ty and not just stick it in the user enti­ty because I had planned to allow users to delete their pro­files. Pro­files con­tained the user’s real name, inter­ests, skills, and the loca­tion: lat­i­tude, lon­gi­tude, time­zone, and city. Lat­i­tude and lon­gi­tude were obtained from React Native APIs, time­zone and city were com­plet­ed from the back­end’s reverse geocoder.

  • Mes­sage: Rep­re­sents a mes­sage with sender, receiv­er, and body. Also con­tains a read-receipt, a boolean field that indi­cat­ed if the receiv­er had read the mes­sage or not.

  • Post: Posts cre­at­ed and tagged by users, that appear in the “Dis­cov­er” screen for peo­ple to swipe through. Card con­tent could be about any­thing.

  • Book­mark: I had planned to let users book­mark their favorite cards, or save them for lat­er. This was not imple­ment­ed in the end.

Building the UI 🤤

OK. So with all this laid out, I was ready to work on the React Native client! The most excit­ing part, build­ing the visu­als, right?


Before real­ly div­ing into the del­i­cate art of build­ing the apps visu­als, I had to think about the nav­i­ga­tion flow. Anoth­er real­ly impor­tant point of any app. The way the user nav­i­gates through your app will deter­mine how flu­id and over­all “nice” your apps feel.

Peachy’s Nav­i­ga­tion flow

Each card is a screen, and the arrows show how a screen can be accessed (through UI com­po­nents like but­tons, the draw­er, tabs, etc…).

I kept tin­ker­ing with this nav­i­ga­tion flow until I felt it was “just right”, I first tried set­ting up the nav­i­ga­tors with emp­ty screens, before design­ing any­thing.

With the nav­i­ga­tion flow sort­ed out, we can start build­ing the UI, right?


Before design­ing and imple­ment ANY screen, I had to decide how I was going to orga­nize these screens in the apps fold­er struc­ture. As with the nav­i­ga­tion flow, I tried out dif­fer­ent fold­er struc­tures until I was hap­py with it:

  • android: Native Android files.
  • ios: Native iOS files.
  • app
    • Assets: Images, sounds, etc.
    • Com­po­nents: Indi­vid­ual UI com­po­nents. Each have their own fold­ers with declar­a­tive React UIs and stylesheets.
      • Avatar
      • But­ton
      • Lists
        • Chat
        • Posts
      • Emo­ji
      • OAuth
      • Pill
    • Con­tain­ers or Screens. Each have their own fold­ers with declar­a­tive React UIs and stylesheets.
      • About
      • Chat
      • ChatList
      • Dis­cov­er
      • For­got
      • Head­er
      • Side­bar
      • Post
      • Pro­file
      • Set­tings
      • Signup
      • Splash
    • Stores: MobX data stores. Inter­act­ed with Web­Sock­ets and REST API.
    • Ser­vices: Class­es to con­sume exter­nal ser­vices, such as Push Noti­fi­ca­tions, etc.
    • i18n: Inter­na­tion­al­iza­tion files.
    • Nav­i­ga­tion: The nav­i­ga­tor con­fig­u­ra­tions: Draw­er­Nav­i­ga­tion, Stack­Nav­i­ga­tion, and Tab­Nav­i­ga­tion.

Fair­ly sim­ple to find and mod­i­fy any­thing from the get-go.

At this point, I was ready to design each and every screen in the app. It was the only thing left — I had sort­ed out every­thing in the back­end, and had planned out what I want­ed to do with the client.

Believe me, by doing the back­end first, build­ing app screens was a walk in the park. I knew what part of the API each screen was going to use, and with MobX there was­n’t much to think about in terms of state man­age­ment.

I used Adobe XD for pro­to­typ­ing the app in a very sim­ple man­ner, and then went one by one imple­ment­ing each screen.

Intro­duc­tion 1
Intro­duc­tion 2
A Dis­cov­er card
Chloe’s pro­file

Cre­at­ing a new post

And more… Here’s the full, high-res album of most of the screens:

My final thoughts

So… I was able to fin­ish my app in time, and the project got a pret­ty good grade. Nonethe­less, the grade was­n’t that impor­tant to me. I was just hap­py that I was able to learn a new frame­work, and think out, design, and build a com­plete mobile app in just a month. I kin­da then real­ized I was made for this.

The pre­sen­ta­tion and demo went great, I actu­al­ly had no oop­sies! that I can remem­ber. 😜 And that’s a huge achieve­ment for me since I get ner­vous about any­thing…

Oh yeah, I also made and wore my own merch to the pre­sen­ta­tion. You know what they say… GO BIG OR GO HOME. And boy, did I go big:


Any­way, I hope you found this post inter­est­ing. I felt like shar­ing this expe­ri­ence today with you all.

Wish you the best!

– Kedi