The web-page for the task can be found here.
The first questions I ask myself is how do we keep data integrity. I'm used to a sql database and I expect that MongoDB has (different) ways of realizing this.
The domain has several constraints
Creates an MongoDB Session entry (if not already present) OR updates an existing Session document.
In sql language this would be a unique constraint on some id/ids that represent
a session. For now I assume MongoDB will allow me to add unique indexes and
would have a possibility to upsert.
Another (unique) constraint mentioned is:
Creates an MongoDB Session entry (if not already present) OR updates an existing Session document.
Although sql has excellent JSON support; it does not have concise ways of adding constraints on nested values. One would make a new table with the necessary unique constraints and at a later moment in time join the relevant tables.
At this point I'm thinking that a time series database approach is the right solution. This removes the need for an upsert and removes the need for indexes. However, this requires considerable changes to the schema which breaks away from the task at hand.
After some searching I discovered that mongoose allows one to define unique indexes on fields and also allows defining an index on nested values.
Another note of concern:
The optIn part in the job is variable, it can be up to 10 items in there
- there can't be a fieldName twice in one optIn list though
What the strategy is for resolving conflicting fieldNames is not mentioned.
As mentioned in the work sample:
A test driven approach is preferred
Testing is at the core of building reliable software. The tests should use actual Redis and MongoDB processes.
To catch edge cases we use generative testing. This style of testing generates test data pseudo-randomly and then uses that as input for the program. We combine this with property based testing to check for different properties for the program.
Properties of the program we would like to test are:
- Should store data on valid input.
- Should error on invalid input.
- Should store or error on random input.
At his moment my time cap alarm rang and I noticed that this is not a one/two hour task as my research itself exceeded the one hour mark. The implementation of the tests, getting more information regarding the conflicting fieldNames, extending the schema, writing the program and finally debugging it would have exceeded the mentioned time limit by far. I hereby deliver my research and somewhat of a testing strategy. I hope it peaks your interest and is reason for a discussion/interview. Regardless, I would appreciate receiving feedback.
Kind Regards, Bas Huis