deweb-io / videbate Goto Github PK

do we need?

If there is already an endpoint in the server, we should use it as cached data, and then (slowly) update data locally with bbs-common.

I'm thinking of locking master from merges that don't have 100% coverage. We are totally in a place where we can afford it. What do you say?

before post is being saved on DB, we need to validate that all fathers posts exists on db. for example:

if we want to save post 1 - nothing to check
if want to save post 1:2 - we need to check that post with path 1 exists
if want to save post 1:2:3 - we need to check that post with path 1 :2 exists

Obviously we don't, since the post ID does not exist until the post is published. One possible solution is to change the flow of the core UI, at least when creating a videbate post, to get the ID earlier, either by setting it manually (generating a UUID and using it when saving the document to firestore) or by publishing the post earlier and marking it as hidden until the final publish.

Another option is to save the new post to a secondary index table which links a surrogate ID (serial) to a BBS community ID and a videbate ID (materialized path of the BBS post IDs). When an item is created the videbate ID will be null, and the server will poll the community's posts and write the data to the posts table when it is found (updating the videbate ID in the index table).

Not a priority, but we should consider this.

This should be very very easy. If you think it takes more than an hour - don't do it. Maybe we will just delete videbate.js, since without this step it is fundamentally broken.

Sadly, it's the thing to do.

For starters, let's not have all these silly files crawling in our root dir.

The storage.js module requires a couple of env variables that are not documented in README.md.

It's also a good idea to check and give better error messages for missing env vars (dotenv probably has something that does it). If this is very easy, we can do it as part of this ticket. Otherwise just open a new one and we will get to it when and if.

Full experience:

1. show video player
2. show navigation buttons
3. play the next video automatically in case of timeout (user didn't click on any button for X seconds after current video finished).

Normal:

1. show video player

Recognizing the state: by listing to change size event on window (https://developer.mozilla.org/en-US/docs/Web/API/Window/resize_event)

This will be called by some scheduler.

Will probably run on a new project on GCP

looks like dotenv lib is good for local dev, but when deploying to gcp env variables are not loaded to the running process, so need to configure env variables on the service itself (like being done for other services we have).

we need to agree on a way to do it.

Not urgent, but we will want something better than refreshDatabase.

This basically means it calls the mount function with an element as a parameter. It's low priority, but will probably make our integration with the Web app easier and more "native" feeling.

https://cloud.google.com/architecture/elastically-scaling-your-mysql-environment

Switch to the 14-tests-bug, run npm run test, and see the horror for yourself. Note that I'm using a local bbs-common.debug.js version of bbs-common.

This is probably the right thing to do, so I'm writing it here, but it's not a priority.