Designing the Backend System of an Agritech App

Designing the Backend System of an Agritech App

Play this article

With over 206 million people living in Nigeria (Source: Nigeria Population (2021) - Worldometer), it is evident that food is one of the most critical factors in the sustenance of its people and economy. Over the years, the country has noticed a decrease in the rate of food production and an increase in the rate of food importation. This is primarily due to an increase in the cost of local production and a shift of focus to Crude Oil as the major source of revenue since its discovery.

Although the Nigerian government, in recent years, has placed restrictions on the importation of certain kinds of food, local farmers are still in stiff competition to meet up with the demands and taste of the Nigerian people.

In November 2020, a team of 4 (myself included) decided to address the concern around agriculture in the SauceCode Hackathon. You can read the UI/UX case study for this project here.

Note: I will be using the words investment and capital interchangeably.

Problem

The inability of farmers to easily access funds for their capital-intensive business which threatens its sustainability.

Solution

AgroFarm is a platform that connects farmers and customers together for the purpose of raising interest-bearing capital for farmers. This interest (or return on investment) will be shared between the service providers and the investors (customers) at an agreed rate.

Timeline

4 weeks

Tools and Technologies

  • Node.js/Express
  • PostgreSQL as database
  • Sequelize ORM
  • Dbdiagram.io for database schema design
  • Paystack for payment processing
  • Heroku for hosting
  • Cloudinary for image storing
  • Postman for API documentation

Database design process

After scoping out the basic features, I began to design the database using Dbdiagram.io. But before then, I asked myself some questions.

  • Who are the users? Can they be divided into categories?
  • Are there similar properties all users should possess? What distinct properties should each category of user possess?
  • What information are farmers required to submit when making requests for capital?
  • Can a farmer have multiple ongoing investments?
  • Who determines the return on this capital? How will this be split?
  • Who can approve a request for capital? Is there any form of pre-approval and what qualifies a farmer for that?
  • When can customers see the investment requests and make payment?
  • What platform will be used to process payment? How do they process payment? Where will the payments from customers be received and payments to farmers be made from? Will the processing fee be passed to customers? Do they support recurrent payments?
  • What information about transactions will be recorded and at what point (initiating, or confirming success)?

In answering these questions, I came up with the schema as seen in Fig 1 below; creating tables and fields before creating the relationships between tables. I decided to use a relational (SQL) database (PostgreSQL) to create standardization, avoid duplication and data integrity, to mention a few. (You may argue that MongoDB provides for the following but NoSQL databases, in general, serves a purpose quite different from SQL databases).

AgroFarm DB Schema.png Fig 1: Database schema

User flow

Users are categorized into 3- Customers, Farmers and Service provider.

Service Provider refers to the company providing the platform, and by extension, its staff. It is the middleman between the customers and farmers, liaising with both sides to ensure ease of use and smooth operations on the app. It can also approve or reject investment requests from farmers.

Farmers are the users who can make request for investment for their businesses.

Customers are the users who invest in approved and available farm businesses.

Farmer Flowchart.png Fig 2: User flow for farmers

Tough times

This project was my first attempt at building an agritech solution. While thinking about the architecture, I had to think about what exactly was my expectation was concerning

  • Wallet-enabled or not
  • Saving customer's card details to make recurrent payments, if needed
  • Accounting entries
  • Whether or not to use a micro-service architecture, even though I was the only backend developer.

With the help of my mentor who works in the fintech sector, I was able to scope out what I wanted to achieve.

Lessons Learnt

1) No one starts a project without an objective. The design thinking (solution architecting) phase is key because it helps to:

  • break down the overall objective into product features and work items.
  • identify resources (people, technology, time) needed.
  • identify the cost-benefit of the project.
  • save time.

2) I learnt how to integrate into a payment processor. Read my article about integrating multiple payment processors here.

3) Ask for help when you're stuck. If I didn't reach out to people I knew had solutions to the challenges I had, it would've taken a much longer time to break the phase of the implementation that needed it.

4) A challenge makes you better. My team ranked top 20 in the hackathon and I'm glad I decided to opt-in. I'm looking forward to more challenges and wins in the near future.

Image credits

Cover image and Fig 2 by Emmanuel Okononfua

If you like this article, feel free to comment and share. You can also reach out to me on Twitter | LinkedIn | Github

Ciao👋🏼