My First Javascript App
Introduction
As part of my training at Ironhack, I had to build up a final project that gather all the different tools I worked on these past weeks. Mongo, Express, Vue, Node, and everything about them. For this purpose, I decided to keep a daily record of my progress on how to develop an application.
This development diary is also tailored to show all my no-tech readers that it is possible to quickly develop their projects. Of course, developing and maintaining a mainstream application would require more knowledge, but building an MVP is quite feasible.
Thus, during the next two weeks, I would try to edit this post daily in order to share with you all the details of my approach.
For this project, I wanted to build a dating application.
Pain
Tinder made a big shot by imposing a standard on dating apps: the swipe. However, other applications succeeded without using this feature. I am mainly thinking about Happn which uses the user’s geolocation.
Nevertheless, an outsider, Bumble, succeeded in getting out of the game. The #1 feature is the following: girls have 24 hours to engage in a conversation after the match. Otherwise, the match will be deleted.
It’s interesting to mention Abricot, an app which reinvents marriage agencies. They’re facing an outstanding success with women.
Thanks to some interviews, I realised that dating applications like Tinder (which doesn’t emit any kind of restrictions) are less popular among women.
We all know this one fellow able to collect 300 matches per second :)
Indeed, there is a major imbalance between the aspirations of women and men on this kind of apps. Men’s behaviour is often perceived as inappropriate by women.
Datas
Nowadays, 50% of Parisians girls are single. Ifop
Dating applications are democratized among young people. BVA
Users don’t hesitate to use several datings apps. interviews
One person out of two confesses to their entourage their presence on dating apps. BVA
It’s easier to attract men rather than women on dating apps. interviews
Answer
The idea here is to replace the swipe with a quiz to create a more authentic experience when meeting somebody.
E.g: User A enjoys User B’s profile and pictures on the app, and decides to “like” User B’s profile. The application will then invite User A to take part in a quiz previously created by User B, with themes like music, movies, trips or books. A score will then be calculated based on User’s A answers and depending on the success rate, User B will be notified and will be able to start chatting with User A.
MCQ
As a cornerstone of this project, this quiz is intended to challenge the users to make them work a little for their reward (the ability to chat to their new crush) with the use of multiple-choice questions…
In connecting the different APIs from Spotify, TMDb, Google apps & books, it is possible to process basic information like:
- Music: What is your favorite artist? What is your current favourite song?
- Movie: Which movie do you like the most? Who is your favorite actor?
- Trips: What is you beloved holiday destination? Next trip?
- Literature: What is your bedside book right now? The author who inspired you the most?
Threshold
However, the final user has the possibility to control the level of challenge in requesting the app to be notified whether the success rate is low or high.
For example, some users could request to receive notifications only if a user took part in their quiz and got a perfect match based on their answers.
On the other side, users could ask to be notified of unsuccessful users as well.
The author of the quiz is free to accept or not a first connection with the other user.
If the user does accept, the chat feature will be enabled and both will be able to start communicating.
The concept of the quiz is to help the users to break the ice and quickly find topics to discuss to get to know each other.
User B: Hi! Are you a Tarantino’s fan too?
User A: You bet I am!
Used technologies
To successfully reach my final result, here are the technologies I will be using:
- Database: MongoDB + Mongoose
- Back: Nodejs + Express
- Front: Vuejs + Vuerouter
- Mobile: React + ReactNative (second time)
Following steps
As previously explained, I will do my best to record my obstacle course. But at this step, I’m interested to find some beta testers who would have ideas or suggestions to offer.
Day#1: Conception
A day without opening my code editor. It was my goal. I had already executed mini projects that had been started too early under a technical aspect in the past, at the expense of the user experience. Today, the idea was to collect as much feedback as possible from my classmates. This exercise is essential and will help you avoid making errors that would be very complicated to fix later. Thanks to this first step, and some interviews given beforehand, I refined some details, especially regarding the user flow.
When should the user be asked any information?
What can I do if the user doesn’t want to share their personal information, or create their quiz?
For the rest of the day, I only focused on sketching wireframes. Let’s be honest, I’m going to take a lot of inspiration from Tinder’s desktop app.
The main difference will lie in the “like”, which will trigger the quiz to be sent to the user who “liked”; quiz created by the “swiped” (or “liked”) user.
Datas schema
It was by far the most complex task of my day. Indeed, data modeling can let you save a lot of time, or waste a lot of it after.
These are my 4 major models which should allow me to build the app:
- User: id, bio, photos etc
- Quiz: data model linked to the user
- Match: represents the success with answers and both users
- Chat: data model filled by exchanged messages
The chat model is generated when the the match model moves from pending to granted (second user confirming the relationship.)
Do not hesitate at this point to draw to better picture each step.
Save time
To make it easier while creating my quiz, I decide to connect several APIs together in order to:
- Offer the best selection
- Sanitize data
- Create multiple choice quizzes more efficiently as open questions are complicated to manage
I then took the time to create a Google Spreadsheet with all my logins, passwords API keys and associated documentation.
Repo
The keyboard call. I couldn’t resist to type a few lines, or rather execute some commands to generate my app.
To do so, here are the commands to type from a common folder.
For Express, Views isn’t needed. You can clean your folder. As for Vuejs, you just need to add the router view and you’re sorted.
I then made sure the two environments work on the 3000 and 8080 ports.
Ok, that’s not exactly it, but here is how your app should look like after this setup.
More or less…
Day #2: Models & signup
Let’s really get into the matter now. The goal of the day was:
- Create my models thanks to Mongoose
- Generate seeds (fake data based on the scheme)
- Create a signup process via Facebook
The goal is reached with difficulty, but at least everything is ready to launch the app on the database side.
Models & Seeds
Instead of describing my four models, I will describe only one: the User model.
This model is classic but it takes care of all the necessary fields for the next steps (well, I think it does).
I do believe I should keep a record of creations and modifications (cf createdAt & updatedAt).
The Gender andthe Looking for will then allow me to deal with the different sexual orientations.
To make sure everything works correctly, the idea is to create a seed to check my app is sending the desired data to my database (MongoDB). To do so, here is a script example:
TA-DA! It works!
The first one is the hardest to create, but then it’s all nice and easy. This part can seem redundant but is actually essential.
Signup
This was a hell of a challenge. After discussing the matter with several more or less experienced developers, I can confirm the signup and login forms are always a pain to code, even if implementations like Passport and JWT will make your life easier.
For my app, I decided to allow login only via Facebook. This was a decision previously made for the project MyBetFriend and we didn’t get any negative feedback then. Plus, almost all dating apps now use this signup process.
To gather the following data:
- First Name
- Gender
- Photos
- etc.
Facebook is the perfect solution :)
If I can give an advice on this: with the help of developers if needed, create a boilerplate you can use again in the future.
Day #3 : API Preparation
Transition day. On this third day, I wasn’t working solely on the app development. At this stage, another essential detail showed up: the realisation of my API REST.
This API allows me to link the client (Vuejs) with my server (Express).
I was already able to spot an error with my signup process. I spotted it from the server side although it would have been more productive to spot it on the client side, but practice makes perfect, right?
Signup & data
So today I focused on transferring my signup form to my client and start my API preparation. I could also improve the signup process by matching Facebook data with my data model. Thanks to this, I can now match the user’s first name on Facebook with my data model.
I innocently thought it would be easy enough to transfer photos from a Facebook profile to my model but this open thread on Stackoverflow put a damper on my enthusiasm.
You now have to provide Facebook with a screencast of your app to be able to use profile pictures.
I will then have to develop my app a bit more before submitting my review to Facebook.
Timestamps
I discovered a rather interesting tip on Mongoose to help me collect timestamps for user data creations and modifications.
It’s all very easy, you just need to add a second argument to my model.
And here is the result:
I also updated my model by replacing the numbers 1 and 2 with male and female.
API
As for the API, I want to create an api.js file on the client side which will communicate with the server. To protect this path, I’ll use the token generated upon signup.
I’ll use the Axios client to make my life easier.
I can expect a lot of work tomorrow: the creation of the first API methods to collect all the necessary data on my client side.
Day #4 : API & Vuejs — Tome I
If Google is your friend, Postman is my best friend. Especially when you start to create your first API REST. Managing an app from A to Z is starting to get pretty complex. Manage 4 different environments (front, API, server and db) and ensure they communicate together isn’t an easy task, especially when you start encountering CORS issues.
CORS
Cross-Origin Resource Sharing… Didn’t you know this acronym? Well, aren’t you lucky. The Cross Origin is what will allow the front (mine works on a localhost:8080) to communicate with the server (localhost:3000). Due to security reasons, your browser will struggle to tolerate this non-stop back and fro between the two. Thankfully a Chrome extension exists to manage this.
Bear in mind that websites like Facebook or Github might act up if the extension is enabled.
Node –inspect
Aka the command that will save your life! On the client side, it’s fine to execute the console.log(‘tutu’), but how do we debug on the server side? Well, thankfully the inspect command exists and allows you to open an ad hoc interface to insert breakpoints in your server.
Signup
Same old story…
Right, Facebook might be “fun”, but they don’t make it easy to create a proper signup form. I think I’ll just get on Firebase straight away next time!
Here are the new steps to make all of this work:
- Front: click on the signup
- Facebook: send information back to the server (id,firstName…)
- Server: send the token and Facebook info using a redirect
- Front: use the req.params to make the app run
- There’s no 5, I’ve had enough.
Vuejs, the blueprints
Following my skilled teachers advice, I decided to develop both front and API at the same time, in order to efficiently align with future users wishes.
I couldn’t thank enough the people who came up with Buefy or Element. These tools provide you with components with blinding speed, how cool!
For example, here is the component I got from Element to offer an age range on my app.
Day #5 : API & Vuejs — Tome II
How many more Tomes, you say?!
I have 9 days left to code and I feel like I’m getting nowhere. I don’t want to put on a sob act, but still, I’m struggling. And it doesn’t get any better when your IDE (Visual Code) starts to go crazy. That’s 2 hours lost, thanks man.
Spotify
The challenge of the day: connect the Spotify API to my quiz model. I ask the user their favourite music band upon signup.
It was very time-consuming as I had to collect first the code then the token but it was very educational. The other advantage is I’ll be able to quickly duplicate on my other APIs over the weekend.
Simultaneously, I also learn about React (which is probably a bit more complex for beginners). I won’t start a meaningless war on different Javascript frameworks but I have to admit Vuejs has some advantages over React.
Syntactic sugar
Vuejs is pretty easy to read and write. For example, here is what I could do; this goes out to the the artists of my time:
Spotify doesn’t have pictures for every artist. If a picture is missing, the entire request will be nulled. Thanks to Vuejs, with 2 lines of code, you can prevent this behaviour. That’s pretty sweet.
If the picture’s here, then great, if it isn’t, placehold.it takes care of it!
Day #6 : API & Vuejs — Tome III
“The other advantage is I’ll be able to quickly duplicate on my other APIs over the weekend.”
Nothing.
Gets.
Done.
“Quickly”.I should know it by now! Although I could quickly apply what I had previously done for music and use it for films. The TMDB API is really well done and you can find many wrappers on GitHub.
I shared my project with a friend and she suddenly made a very a good point…
“Yeah, all the music and films stuff is great, but what about personality traits?”
Damn. She was right. So, I stopped working on the API integrations and started a very simple autocomplete: strength and weakness.
Autocomplete
Loving this good old Buefy. You’ll find your happiness in the Forms Controls.
Source : https://buefy.github.io/#/documentation/autocomplete
As you can see, even the .js part is already dealt with. Done, I’m out.
Tomorrow I’ll get a little break from the crazy Express/Mangoose duo and will integrate the landing page.
Day #7 : Landing Page
A chilled Sunday: landing page integration. Easy.
My first attempt is available here.
As we’ll have to provide a landing page of our project, I might as well do it now. I think the production phase will bugger me way more at a later stage.
But it’s not an excuse to create a lame landing page. I wanted to insert some parallax and CSS animations. To do so, I used two very interesting tools: Paroller and Animista.
Paroller
Source : https://github.com/tgomilar/paroller.js/
Paroller is a plugin based on jQuery and enables parallax animations easily. Yes I know, using jQuery is wrong, blah blah… but you know what? It’s easy, it works and you don’t have to waste hours recreating the same thing with Tween.
What I love the most in Paroller is its very simple configuration. You only need to declare a class on the part you wish to animate and from there, everything is easy:
You just have to manage those 3 parameters and voilà.
Animista
Source : http://animista.net/
Animista is the Google of CSS animations. Simply pick an animation, copy paste its class and keyframes and… done.
Day #8 : some data
A rather productive day: Trello update and quiz finalisation. Now moving on to a significant piece of work: the linking (swipe + quiz + chat) interface.
But before that, I need to deal with two essential tasks: save the user data locally (local storage) and create fake user profiles.
It isn’t to pretend I have subscribers on my app, but to test several scenarios, as the possible search combinaisons are numerous (age, desired age, gender and sexual orientation).
Save user data locally
I saved this part for later thinking it wouldn’t be too tricky to do at a later stage — it isn’t, but I still think it will be worth taking care of it earlier next time :).
Upon signup, I collect the id from the Facebook callback URL.
I can then send it with Axios to my local storage (developer tools > application > local storage).
At the sign-up step, I get the id from the Facebook URL callback.
NB : I also send my token but I do so somewhere else :)
These aren’t the funkiest lines of code but they do the job.
Faker.js
The Holy Grail. I thought I would have to scrape dating websites to get a first testing database. But, as you might know, scraping is bad, bad, bad.
Thankfully, I stumbled upon Faker, a library which can generate a humongous amount of data. One of the biggest highlights is that Faker can generate based on your location, which means I could get French users exclusively.
Life is good.
Day #9 : Vuejs and its components
Today, I got to taste Vuejs power. One of its strength is the structure of its components and its views.
For my swiper interface, I have a Card component and a Quiz one, both being in a Swipe view.
- Swiper.vue — view
- Card.vue — component
- Quizz.vue — component
The quiz is automatically disabled. It gets enabled with the Like click on the Card.vue. And I make sure it goes away with the event $this.emit(‘hide’) from the Quizz.vue component.
It is then recovered in Card.vue with @hide=hideQuizz
Pretty easy, am I right?
Last tip: use beforeMount() to load the API before the component in order to display data as soon as the component loads.
Day #10 : Like & Dislike + Heroku
My project presentation is on Friday. Shall we get on those advanced functions? And eventually roll all of this out?
Today I focused on coding my key features, the Like and Dislike, with a first implementation to make sure Friday won’t be too painful.
No one implements on a Friday anyway… Source
Like & Dislike: MongoDB & Vuejs
To make sure the app fulfills the user wishes, it is essential to offer matching profiles based on gender, sexual orientation and age.
To do so…
Route
I will improve it tomorrow…
As you can see, nothing’s too complicated. Based on the user ID, I collect the necessary information to offer the user the profiles matching their taste and desire.
Then, I search the entire database based on their criteria. My search is limited to 100 to begin with (no need for more when testing).
Methods
You need to conceptualise several things on Vuejs.
The API call is made based on the user ID. So collecting it from the local storage makes sense.
I use an incrementation so profiles display one after the other. It might be interesting to filter the output object on the registration date, so it shows older profiles first. Food for thought.
Let’s not forget the beforeMount() and we’re good.
Heroku
Meh… The roll-out phase is a real burden to me. You can easily spend an insane amount of time to debug and still get disappointing results. Although you can show off to your friends at the end of the day.
Joking aside, Heroku is very useful and well documented to help you on this. And on top of it all, it’s free.
Day #11 & #12 : The End.
I am really struggling to find some time to write during the last days. On Day #11, I made at least 20 commits on my app: a new record! :)
Quiz
I finally managed to set up the main function of my app: the quiz.
The trickiest was to create dummy quizzes and link them to fake users.
I am still using this good old Faker.js which saves me a considerable amount of time. Once I’m done creating the file, I send it to the database using Mongoose.
Refacto
I found something very interesting in React documentation: Thinking In React. I am yet to find something similar on Vuejs.
It explains how to split a small web app into components. it’s very interesting because if you’d start creating an app with a wonky architecture, adding any feature would be very complicated.
That’s why I decided to re-factorise my swipe interface (the day before my presentation).
I don’t regret making this choice — it helped me speed everything up afterwards.
When I will work on my next app, I will spend way more time conceptualising the app on paper.
Toasts
Interesting little feature for the final user, the toast. Setting it up is a child’s play and the result is rather cool for the user.
You can quickly add this little code in your API return data, which will notify the user everything is fine, before redirecting them to the next page.
It’s a match!
For my presentation, I had to apply a fixed pattern on the right answers. Obviously, I wouldn’t have done so for a real implementation but this had to be done quickly and and it did the job…
npm run build
Another important element I learnt during these crazy coding days is how important it is to quickly generate a build. Vue (and the others) compile the code and place it into a folder /dist. If you moved css natives classes like me, you’ll end up with a messy app. To make sure everything looks ok, generate a build at the end of the day.
Or you don’t need to do this because you code correctly and create classes everywhere.
Conclusion
There it is. http://mtmt.viviansarazin.com/
NB: the application is not mobile optimised.
Two weeks of coding, one application. I think I could do this app in a week now, but this had to be done!
Retrospectively, I’d say I could have spent a bit more time on the conception phase to better prepare my API, my components and all that jazz.
I also wasted a lot of time on setup, especially on the Facebook signup. Next time I think I will work with Firebase directly. Another solution would be to create a MEVN boilerplate to save myself some time.
Thanks
Time to get the Kleenex out! Every good thing comes to an end!
The teachers: Thanks to Eduardo, Guillaume, Maxence, Mickaël A, Mickaël B, Nizar & Yacine.
And the others: Thanks Antoine, Charlotte, Karim, Maya & Sacha.
Yours faithfully :)
