Fit Gorillas

A social network for gay men with an interest in fitness & connecting beyond nearby hook-ups

Comment

Inspiration

A gap in the market…

Our goal is to create a niche social network to connect gay men with a common interest in fitness around the world in a more social & friendly way than the current main stay of gay social apps - gay hook-up/dating apps.

Secondly to offer a photo sharing social app with a bit more privacy from family & work colleagues (a completely gay men network) than current social apps, which is important for many gay men, especially in the ‘coming out of the closet’ 18 – 24 age group.

Basically in between the gay hook-up apps & the global social apps we feel there is a gap in the market.

Fitness is a perfect social niche…

We started with a brand on social media and found that many gay guys resonate with the fitness niche. This niche is very socially active and very visual, making for a powerful social app niche.

What it does

The Fit Gorillas app allows gay men with a common interest in fitness to create a profile and post photos. They can explore their feed, like & comment on photos. Browse the global gorilla & nearby grids and ‘pack/follow’ guys that appeal to them. Private chat with guys and send private photos, follow #topics they are interested in, and customise their experience with themes, language, privacy and chat settings.

How we built it

The Fit Gorillas stack comprises of both a frontend app and backend services. Being a small team we focused on maximising our resources by using technologies that use JavaScript so developers could easily work throughout the full stack. We use NodeJS mostly for our backend services and React Native on the frontend.

Fontend

The Fit Gorillas app frontend is built in React Native, written in JavaScript and targets both the IOS and Android platforms. Over 95% of the codebase is shared between the two platforms. We use Redux to manage state, websockets for live chat and notifications, multiple login providers (Instagram, Facebook and AccountKit) and the l18n library for language settings (currently translated into Spanish and English).

We use the Animated library for native animations and the React Navigation library for navigation and transitions between screens. The use of both these libraries have enabled us to do lots of really nice native animations and transitions.

The project files are grouped into the following folders: actions, pure components, containers, libraries, navigators, reducers, stores and themes. Sharing pure components between containers has enabled us to build a modular app and easily maintain a consistent design throughout the app. Pure components don't re-render themselves unless some data has changed which allows us to maintain performance. The app is styled using a base style and themed styles. The themed styles allows users to change the theme of the app (currently light and dark).

Following our philosophy of keeping things simple we try and have as few screens as possible and instead mashup relevant data to be displayed. To achieve this we use the Re-Select library to combine data using algorithms we have developed from our different Redux stores. The algorithms are designed to maximise both relevance and entertainment. For example the Feed screen includes timely data, trending posts, posts from hashtags, posts from followers and advertisements.

Backend

Our backend is designed as a service oriented architecture split into various layers. Each layer is able to auto-scale horizontally based on physical system resource demands. Our main layers are API, Worker, Data, AI, Chat, Cache, Media, Content and Build.

API

The API layer is a RESTful based JSON API. The API authenticates clients via the oAuth protocol, handles requests and posts actions to message queues for processing by the Worker layer. All data is transferred securely over HTTPS and HTTP2.

Worker


The worker layer processes requests from our message queues and does the grunt of the processing work. This layer is used to process user posts, synced posts from Instagram, user interactions, hashtags, generate trending data and data relationships.

Data

The Data layer uses both NoSQL and structured SQL data stores. For our NoSQL data stores we use Azure Tables and CosmosDB. Data in these stores are indexed in lexicographical order in the direction of consumption so no sorting is required when consuming the data. This saves time, the need for secondary indexes and processing power when requesting and updating data. We also developed a design pattern to mimic they way a traditional relational database maintains one-one and one-many relationships by encoding this relationship in the data stored in the indexed key column. Our design pattern allows us to use NoSQL data stores and achieve similar features traditional databases like SQL Server have with their referential integrity and atomicity but without the overhead and costs.

For our structured data and for other features such as querying geospatial data to list users and posts nearby we use Azure SQL Server.

AI

All content uploaded to the app gets automatically assessed by our AI layer. We use Azure Cognitive Services to analyse images and flag any pornography or unsavoury content. The user gets a notification with the reason if their content has been flagged. Our administrators will then manually approve or reject content. The AI layer is also used to analyse and process trending posts.

Chat


The Chat layer is build with NodeJS and uses WebSockets for realtime client/server communication. Redis Cache is used to maintain chat sessions across multiple chat servers. All data is transferred securely over HTTPS and HTTP2.

Cache


The cache layer uses Redis Cache and stores session and frequently accessed 'hot' data in fast in-memory data structures. The cache servers sit close to the other servers that use them such as the API, Chat and Worker for fast millisecond data retrieval times.

Media


The media layer processes images and videos uploaded to blob storage via the API. The image processing uses Azure Functions and is triggered asynchronously by the blob storage.

Content


The content layer is also responsible for serving multimedia content files and static JSON data files to the client application. This layer uses various CDN (Content Delivery Network) providers to store content as close to our customers as possible to dramatically improve the performance of the app loading this content.

Build


We build software using the scrum-agile software development methodology. These hourly-daily deployments help us track down bugs, design and software issues much faster and devise new solutions or enhancements. Each day as tasks are completed they are checked in to source control against a scrum task item. As soon as the code is check into to our development source control our build server automatically builds the software and deploys it to the relevant UAT servers or emails the relevant UAT users to install a new version of the app. A UAT release can then be approved for a production release and deployed to the production servers. This dramatically reduces our deployment cycles.

Challenges we ran into

Being a very small team and not having enough resources to build our frontend mobile app in native technologies for both IOS and Android we initially decided to settle on using Cordova and building our app with web technologies. We planned on using NodeJS for most of our backend services and having both ends of the app written in JavaScript made for a compelling choice. Developers could easily move between frontend and backend code as both were written in JavaScript.

Initially we used the Sencha Touch JavaScript framework to build the app and were able to release to both platforms quite quickly, but as our app grew in complexity it would become sluggish and we were increasingly hacking our way through to improve performance and handle browser limitations on each platform. Not to mention in recent times the Sencha framework became prohibitively expensive to licence.

Whilst doing some research for other multi-platform app frameworks we came across React Native and learned that we could code our app in JavaScript and it would compile down to native views. We did a few small tutorials on using React Native and our initial results were impressive. We decided to take the plunge and migrate our app over to React Native. The process took less time than we anticipated and the end result was a native performing app for both IOS and Android that were have been really happy with.

Having built a very successful social brand the market had high expectations of our social app. It was a big challenge to provide a fast & entertaining app whilst ensuring a critical mass of users that fit the niche we have focussed on. Getting to a critical mass is key for a social app, and also the greatest hurdle. This is something we are improving on each month with improving retention and return rates. Design simplification upgrades, AI to monitor all new profiles & photos uploaded to app, and a Verified profile system have all helped drive these improvements in recent months.

Accomplishments that we're proud of

Fostering our community

Fit Gorillas has a very large social network following with over 1.1 million followers on Facebook (http://facebook.com/fitgorillas) and Instagram. The brand has grown year on year and is well known and respected in the gay men community. Many businesses that target the gay community want to partner with our brand due to the positive, healthy and fun associations it represents and brings to the gay community. Gay guys want to be part of the brand and be known as a ‘Fit Gorilla’, which is a very powerful emotion and what makes us the most proud of what we have achieved – A brand gay guys love.

In Tech - Maintain both speed and cost as first class citizens

Each layer of the Fit Gorillas application has been architected and built from the ground up to be fast, responsive, efficient, scalable, horizontally elastic and low cost where design, speed and costs are first class citizens.

One of the biggest (if not the biggest) costs and performance bottlenecks of an application tends to be the data layer. This is amplified even more when dealing with big data and our app being a social network uses a lot of data. To overcome this we came up with an innovative design to our data layer.

Building the system data layer to be scalable up to terabytes of data whilst still responding to data reads and writes for a very large number of requests per second with millisecond response times requires a data layer architecture which enables horizontal partitioning of data where data is sharded and stored across a large number of servers.

No-SQL data stores are built to tackle this issue and are very good at horizontal partitioning of data with flexible data structures but they are usually limited in they way data is indexed. To overcome this we developed a design pattern to mimic they way a traditional relational database maintains one-one and one-many relationships by encoding this relationship in the data stored in the indexed key column. Our design pattern allows us to use NoSQL data stores and achieve similar features traditional databases like SQL Server have with their referential integrity and atomicity functionality but without their huge cost.

What we learned

Keep things simple…80/20 rule…

Keep things simple. Just because it can be done doesn't mean it should. Prioritise resources according the 80/20 rule. Do the basics really well before adding new additional features. This was a huge learning for us. On our initial iterations of the app we had a lot of sections in the app. People tended not to drill into the different sections. We came up with the concept of 'Screen Cadence', essentially what is the rhythm of information that would be most relevant and entertaining on that screen. Then we would develop algorithms to satisfy the screens cadence and mashup all related content to maximise user engagement. This enabled us to have less but more engaging screens. Finally…we paired the simple way of working with a clean simple intuitive design so users could use the app with the least friction – another critical learning.

Focus on your Niche…stay ’on brand’…

Delivering according to your customers expectations is critical. When guys install our app they expect to find guys that fit the niche. This requires a very focussed and disciplined approach to how you market your brand/app and also how you design your app and what features are required. We found these nuances are what enabled our app to start to ‘work’ and hit the mark for our customers.

What's next for Fit Gorillas

To continue to build our community of gay guys that are into fitness & something beyond nearby dating/hookup across the world. Continue to add more social connectors and features like full screen video, Live broadcasts, groups and more. Also to launch to the gay business community so they can have business profiles on the app to connect to the audience through social content. We have an opportunity to connect B2C as our brand is positioned as ‘clean gay social’ as compared to many dating app brands.

Built With

Share this project:

Updates