waktu solat v2

[iqfareez]

Objective

• Develop new endpoint for /api/solat/.
• Make data fetching from JAKIM occur before the upcoming month

TODO

• Design in intended responses
• Design new data fetching and processing pipeline (waktusolat-fetcher)
• Setup schedule to automate fetching
• Migrate database from using JSON to Firebase
• Add /v2 to mpt-server (keep the original as is, to prevent breaking)

Motivation

Currently the responses that returned from that endpoint is same and identical to what JAKIM API returned. This is fine because the original objective is to use this endpoint as a backup when JAKIM API goes down (Originally introduced in mpt-backup-api).

However, the current implementation has few drawbacks.

Current problems and possible solutions

Delay in data updates

Problem	Solution
The earliest data fetching can only be done in the first day of the month. In addition, the CI workflow is scheduled using Zulu time. So, it will take a few hours before fetching for the month can be done. So, app will be fallback to use JAKIM API when mpt-server data is not ready yet	We can use other 3rd party cron job services to fetch the data at 00:00, but I'm afraid everyone is doing the same at it would cause problem to JAKIM server. Instead, we'll try to retrieve prayer data for upcoming month in advance

Data responses and parser

Problem	Solution
The API currently return a date and time separately, in text (See it yourself). A parser needs to be designed to properly parsed the data (See current implementation in mpt app). In addition, sometimes, an expected changes with JAKIM API (for example: mptwaktusolat/app_waktu_solat_malaysia#103 (comment)) require a new app update.	Parse date and time to UNIX epoch, so it will be up the client to parse easily to whatever they want. Also, if unexpected changes occur to the JAKIM API, a fix can be issued immediately without publishing a new app update

Storing data

Problem	Solution
Currently. the fetched data stored in JSON database. It doesn't cause any issue, it just for every data update, a new site deployment is made. This approach has one benefit because the data and the server are in one server (not separated by physical distance)	Store the fetched data in database (I'm thinking of mongodb/Firebase). Additionally, we can add versions so the endpoint will be able to retrieve the previous month, current month, and upcoming month. There might be some latency issue. However, that can be overcome by properly setup caching etc. We need to make sure that server and database are physically close to each other

Risks

Keep this risk in mind. Since we are using JAKIM API, which is undocumented, and I don't think it is for public use. The API can break anytime and can mess up our API database.