General remarks

[olavloite]

@vignesh-sdev @rohan-searce @yogirk

I had a couple of general remarks on the current application setup, but as those files are currently not touched by any of the open PRs, it's a little bit difficult to add comments on it. I've therefore summarized it here in an issue.

Please feel free to let me know if something is not clear, or if I've misunderstood anything.

Data Model

The data model of the application uses FLOAT64 for several properties that would be better represented by other data types:

• Number of shares, both of a company as well as trade volumes, are always integers. It would be better to use INT64 instead of FLOAT64.
• Share prices are normally specified as fixed-precision numbers. It would therefore be better to use NUMERIC instead of FLOAT64 for these properties.

See https://github.com/searceinc/spanner-terraform-example/blob/09dafc74ff17a236bdd466e14937940d14c76d74/modules/cloud-spanner/variables.tf#L56

Executing queries

There are multiple queries in the application that do manual conversion of the query results to JSON. That can be done automatically by the Spanner client library by setting the json: true option in the query.

For example the function here could therefore be simplified to this:

Users.prototype.getAllUsers = async function () {
    try {
        const query = {
            sql: 'select * from company',
            json: true,
        };
        return await database.run(query);
    } catch (err) {
        throw ("error in getAllUsers function", err)
    }
}

You should also consider adding some kind of protection against out-of-memory problems in a query like this. Selecting all rows from a table without a WHERE or LIMIT clause could bring down your entire application if the table grows beyond the size that you expected.

[vigneshsdev]

@olavloite Regarding the data model, The stocks schema has been changed as below. I've removed some fields like adj_high,adj_low as it is not needed for this application and updated the needed fields only.

CREATE TABLE companyStocks ( companyStockId STRING(36) NOT NULL, companyId STRING(36) NOT NULL, companyShortCode STRING(36), open NUMERIC, volume NUMERIC, currentValue NUMERIC, date FLOAT64, close NUMERIC, dayHigh NUMERIC, dayLow NUMERIC, timestamp TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp=true) ) PRIMARY KEY(companyStockId)

@rohan-searce will add this DDL in PR-3

[vigneshsdev]

Regarding the query of fetching all rows in the companies table, we are expected to have few thousand rows only for this application, so I've handled the pagination, sorting, and search feature in frontend itself.

[olavloite]

Thanks for looking into this, I really appreciate it.

Regarding the query of fetching all rows in the companies table, we are expected to have few thousand rows only for this application, so I've handled the pagination, sorting, and search feature in frontend itself.

Ok, that sounds reasonable. It might be worthwhile adding a short comment to the code where the query is executed, so people know why it is safe to run the query as it is. As far as I understand, this application is intended as an example application with best practices when using Spanner, Terraform and NodeJS. So when you are doing something that is OK in this application because you for example know the size of the table, it might be good to document it for other users who might be looking into the application for concrete examples on how to perform certain actions.