Public To-Do List?

[garindra]

Is there any public to-do list/project task board somewhere? I'm thinking of contributing, but want to make sure I'm doing something that the core developers are not in the process of doing.

[fikriauliya]

Currently I am the only main contributor, and honestly no well-defined to-do list on my mind, most of the updates were spontaneous 😄

If you have some ideas, just raise it here first 😃

[fikriauliya]

Oh, actually I have one:

• Open http://rapbd-dki.kawalapbd.org/
• Notice that there are some nearly-similar duplicates, e.g. "Pengadaan Alat Book Sanitizer SMP Negeri 205", "Pengadaan Alat Book Sanitizer SMP Negeri 224", "Pengadaan Alat Book Sanitizer SMP Negeri 225", etc.
• I am thinking of putting content summary in each page (probably on right top corner).
• The algorithm should be smart enough to group those nearly-similar entries into shorter list. Can just take the longest comment substring, e.g.: "Pengadaan Alat Book Sanitizer SMP Negeri", or combine them with commas, e.g.: "Pengadaan Alat Book Sanitizer SMP Negeri 205, 224, 225"
• This way, we can read the page much faster

[garindra]

I'm thinking of contributing on changing the data source to something like Parse.

Using a single JSON file clearly won't scale -- the list of the kegiatans will only get bigger overtime (let me know if this is not a correct assumption). This also hinders the site from having good home page load performance (will get worse as time goes) and a reasonable data access pattern for single-kegiatan view page, which I think is a page that is paramount to the site's virality.

Parse has a reasonable free plan (30 req/s), and since the data is mostly read-only, it should be possible to put a caching server in front of Parse for the production deployment of the site to eke more requests out of the free plan. I also happen to live with a Parse engineer -- that might make things easier.

[fikriauliya]

I had planned to migrate from Firebase to Parse when the traffic was peak (free Firebase plan limit reached). However, after looking at the pricing model of Parse, I decided not to choose that option. Yes, for 30 req/s it's free, but the next higher plan costs $100/month. So, eventually I simply upgraded the Firebase plan (costs $49/month).

Btw "the list of the kegiatans will only get bigger overtime" is not correct. The list of kegiatans are fixed, it was extracted from RAPBD PDF file from Pemprov website (code here https://gist.github.com/fikriauliya/59b19b2ce8b08fa46644).

[garindra]

Got it. What do you think about moving the kegiatans data to Firebase then?

[fikriauliya]

I think it would increase the bandwidth to Firebase. In addition to that, since Firebase plan model is based on the number of concurrent connection, having longer connection to Firebase would possibly increase the cost.

I believe for this app, it is ok to load all data at once to browser's memory. Yes, it makes loading time slower, but still tolerable. The benefit is, the filtering and sorting could be done offline. Once the data is loaded, filtering and sorting could be done quickly using client's browser's resource only. No server need to be maintained.