First, we decided to divide the target audience by platform. We determined that employers would find a web version of the app more convenient, while job seekers would prefer accessing the platform using native mobile apps.

We created detailed wireframes and chose appealing color palette and fonts so as not to distract users from the seriousness of the job and applicant search. Our designers avoided unnecessary animations and applied a swipe feature to make it easy for applicants to filter through job postings. This swipe logic is often used in entertainment and dating apps, but this pattern turned out to work really well for our client’s job app as well. We designed the mobile apps to be simple, clean, and highly intuitive.

Our backend choices were driven by our need to support multiple platforms: native iOS and Android apps and a web app. We decided that the Django REST framework was a good match for our needs, so we used it to build the RESTful API.

To power real-time chat, which is an important part of the platform, we created a WebSocket server using an asynchronous web server (Aiohttp) and a asynchronous redis client (Aioredis).

Email and push notifications are handled by a separate notifications microservice backed with a distributed task queue powered by Celery. All scheduled operations and asynchronous tasks are handled with Celery as well.

Data security and integrity is ensured with the latest version of the PostgreSQL database and regular automated backups.
 

When developing a complex app like JobMatch, we prefer using reliable tools that have proven both flexible and effective. To uncover its full potential, every powerful API must have an exhaustive documentation system. There's a lot of software instruments that help generate documentation for API's. Each of that instruments has its pros and cons, but we are choosing what best fits our current requirements on per-project basis. The documentation for JobMatch API also had a few essential requirements. It should be easy to generate, update, and expand.

The first users of this documentation were our colleagues from iOS, Android, and Web departments and the main requirements for it was ease of use, descriptive information along with a detailed technical information for each API call, and built-in functionality to send test requests and analyze responses. Django Rest Swagger best meets all requirements, so we chose it as a documentation tool.

JobMatch connects employers with potential employees, and this process seems very natural and easy when using the app. But under the hood, there are a number of criteria and various factors that go into what we call the “matching process.” One of the main things that ensures the efficiency of this process, along with smart querying, is a PostgreSQL database.

One of the challenges our team ran into was connected with chat. We built the chat functionality from the ground up with the help of the secure WebSocket protocol based on aiohttp and aioredis microservices.

Traditionally, we’ve used Stripe to handle finances and payments, and we used it again in JobMatch.

JobMatch was written in React as it’s a convenient tool that works perfectly for team development. React is optimized and easily expandable due to its component-based approach.

Since React is still a library and not a full-fledged framework, we decided to use the FLUX architecture, which was popular at that time. With the FLUX architecture, all application data is kept in one place – the flux store, which is conveniently used to receive and manage data, make an additional  optimizations of requests to API, and speed up the application as a whole.

The bundling and development of React was implemented with the help of create-react-app (tool for creating a bundler). To manage the layout seamlessly, we used gulp and the gulp-less, gulp-autoprefixer, gulp-sourcemap, gulp-svg-sprite, and other plugins.

We used axios to enable interactions between REST with the server and used react-router v3 to build routes and navigation in the app. We also used a number of open source components – for example, react-datepicker (UI component to select dates), react-modal (shows floating windows), react-s-alert (shows notifications), react-select (provides a cross-browser multifunction selection component), and react-simple-dropdown (a UI component for displaying and configuring drop-down menus). We also used the moment.js library, which provides a lot of localization functionality and works with time output. Classnamesis a utility for flexible management of CSS classes (styles). We used the validator.js library to validate forms.
 

Our iOS developer used Swift for the JobMatch app as it’s fast, safe, modern, and simpler than Objective-C. We chose the MVC (Model-View-Controller) architecture to make the code flexible and easy to test.

To detect bugs and fix them quickly, we applied Crashlytics by Fabric. This approach made the development smooth, allowing us to reduce time spent on testing.

We integrated the SDWebImage library to process and cache images, as it ensures good performance.

To power in-app chat, we used SwiftWebSocket as it’s easy to implement and works well.

All animations and custom UI elements we made on our own using only the native UIKit.

The Android app is written in Java. We chose a Model-View-Presenter (MVP) architecture, which is a basic pattern used for the majority of modern apps. However, we divided the View to View as the facade object into Activity (or Fragment) to make the code clearer than it would be with the two components combined. The MVP architecture makes the application more modular and allows us to implement changes in each MVP component.

We applied Material Design concepts and guidelines to develop the app. We used Retrofit for REST interaction with the server and RxJava to make interactions with the server more flexible.

To store user settings, we used the famous Hawk library. The main benefit of this library is that it encrypts all user data  and is easy to implement for developers. We also used the Lombok library to save time on development and simplify the writing of data classes. Instead of writing getters and setters, we prefer code generation.

To display images, we used Picasso. This library covered all requirements for both developers and our customer, both saving time and loading images faster by simply using links. For custom fonts, we chose the Calligraphy library, which adds the ability to play with fonts and configure changes across the whole project.

To ensure smooth communication between the app’s screens, we used EventBus, as it’s very simple to deploy and is time-efficient.

The Timber library allows us to read application logs and is simple to deploy and use.