eiffelfly / curioucity Goto Github PK

Context

All the discord context will be returned as string from Discord API, let do the same in our API

Context

Right now we only support page_size query body for backend to operate simple pagination. But it is not ideal.

• If other user adds resource right before the user query our API, the data will miss or the order will change

Cursor based pagination is far better than limit and offset pagination.

Context

The K6 need to know the proto file of the API to test the API. But when import the proto, the k6 can't find the imported proto from the original file.

Context

Right now we only use javascript to write the integration-test, it's not so elegant in my opinion. We can re-write the whole tests file to typescript file, build by esbuild and output to /dist file and then run the integration-test.

Reference

• https://github.com/grafana/k6-template-typescript

Context

Currently, we use this match pattern in our backend

let discord_message =
        match db_third_party::discord::DiscordMessage::create(client, &payload).await {
            Ok(discord_message) => discord_message,
            Err(error) => {
                return Err((
                    StatusCode::INTERNAL_SERVER_ERROR,
                    format!(
                        "Something went wrong when create discord message: {}",
                        error
                    ),
                )
                    .into_response())
            }
        };

In order to reduce the overhead of coming up a variable name for Ok(), I purpose that we unify that as below

let discord_message =
        match db_third_party::discord::DiscordMessage::create(client, &payload).await {
            Ok(result) => result,
            Err(error) => {
                return Err((
                    StatusCode::INTERNAL_SERVER_ERROR,
                    format!(
                        "Something went wrong when create discord message: {}",
                        error
                    ),
                )
                    .into_response())
            }
        };

Instead of coming up a new name, we use result

Currently our REST API endpoint is

• GET /resource_name/:resource_id: get resource
• GET /resource_name: list resources
• POST /resource_name: create resource
• DELETE /resource_name with resource_id in body: delete resource

In order to make it more consistent, I would like to alter the design to

• GET /resource_name/:resource_id: get resource
• GET /resource_name: list resources
• POST /resource_name/create: create resource
• DELETE /resource_name/:resource_id with resource_id in body: delete resource

Context

According to protobuf spec, int64 will be serialized as string in the form of JSON. Currently, int32 should suit our need enough.

Context

order_in_thread comes from Discord message object's position. It appears to be integer but without specifying the type. I think int32 will be enough to store it.

Reference

https://discord.com/developers/docs/resources/channel#message-object

Currently, in our API we provide JSON object and markdown content in the DiscordThread object.

#[derive(Queryable, Serialize, Deserialize, Debug)]
pub struct DiscordThread {
    pub id: Uuid,
    pub kind: String,
    pub thread_id: String,
    #[edgedb(json)]
    pub full_messages_json: HashMap<String, String>,
    pub markdown_content: String,
    pub tags: Vec<Tag>,
    pub messages: Vec<DiscordMessage>,
    pub url: Url,
    pub created_timestamp_at_curioucity: String,
    pub created_timestamp_at_discord: String,
}

The upcoming questions are

• When user delete discord message, how do we update the full_messages_json and markdown_content
• We generate the markdown_content beforehand or when user query it
• Do we need to provide these data at this moment?

Context

Currently, we have this kind of test to test the list endpoint

check(http.request("GET", `${API_HOST}/tags`, undefined, { headers }), {
      "listTag - GET /tags - have two tags, should response 200": (r) =>
        r.status === 200,
      "listTag - GET /tags - have two tags, should response size=2": (r) =>
        r.json().size === "2",
    });

Sadly, it will have chance to get polluted by other testing, we may need to find better way to solve it.

Context

Protobuf will serialize int64 to string in the form of JSON.

JSON cannot store 64-bit integers, instead only storing double-precision floats (which have a maximum integral precision of 52-bits)

We better store our timestamp in the form of string like GitHub API 2020-01-10T14:59:22Z

Reference

• influxdata/pbjson#91 (comment)

Context

• This is the repo to reproduce the issue https://github.com/EiffelFly/axum-tonic-string-response
• In short, the response should be int64 but get serialized into str