zephir-anagram-users

Objective

Provide a full-fledged web application in our tech stack:

• frontend: react.js + typescript + next.js + Apollo client
• backend: node.js + typescript + nest.js + graphQL + postgres

Database tables schema:

• users:
  • id -> primary key autoincremented
  • email -> unique
  • fib -> result of fibonacci
• anagrams:
  • id -> primary key autogenerated
  • user_id -> foreign key for user id
  • anagram_map -> json blob with the map of anagram counts

The web application should have the following:

• a button that opens a modal (a popup that overlays on top on the main page) containing a form allowing to create a user. To create a user on the backend, one must:
  • calculate the fibonacci value for a random number of either 50 or 51 (the function to do so will be provided) and save the user entity with this value and the email
  • create a file with a list of all anagrams for a random set of 60 words -> the function to do so will be provided
  • read the file and calculate, for each of the words, the number of generated anagrams. For the anagram map, We do not need to know the word per say, simply one of its anagrams.
  • use the anagram counts map to create the anagram entity on the database
• the frontend should show the amount of time it took to create the user (from the frontend perspective, not the backend)
• show a list of users with their respective Anagram counts and fibonacci number in the main page. This list should be automatically refreshed every time a new user is created (even if the user creation is performed by another tab or browser), and should show the user email, her anagram count and her fibonacci number (format the result the way you prefer)

General constraints:

• One can only create users with emails on the format {USERNAME}@zefir.fr
• The application must be stable, and should only fail if the user with the respective email being created already exists and has an associated map of anagram counts.
• The application should be able to receive A MINIMUM of two parallel requests without hindering the server performance (i.e. at least two of the responses should have taken a minimum similar amount of time for being treated, saw from the client perspective) -> in other terms, the server should be able to scale to accomodate any amount of charge, if needed.
• The application should be ready to be deployed, either by providing a runtime (such as docker-compose) or by providing a script and set of instructions to launch it.

Please contact julio@zefir.fr for any doubts and questions during this exercise, the goal is to mimic a normal development cycle as best as we can