About OSlash

https://osl.sh/launch-video

πŸ““ Problem statement

The πŸ₯‡ primary goal of this assignment is to build a barebones clone of the OSlash app backend β€”

  1. The backend will be an API server (can be gRPC, GraphQL or REST) that is backed by a database.
  2. The database will hold all user accounts and shortcuts created by users.
  3. Every API (except login) will have to be authenticated.
  4. The APIs that will need to be built are –
    1. Login & logout.

    2. Create a shortcut – includes the fields shortlink (string), description (string), the full url (string) and tags (multiple strings).

      1. Note that the shortlink should be unique for a user.
      2. URL should be validated to be a WHATWG spec compliant URL.
      3. Tags can be optional.

      <aside> πŸ“£ If you haven't tried out our app yet, please do. It will help you understand these fields better.

      In short, OSlash helps you create "shortcuts" for URLs – for example, the shortcut o/assignment can take you to this document. Here, the shortlink is assignment and url is https://www.notion.so/getoslash/OSlash-Backend-Engineering-Assignment-OSlash-Clone-6a72b110f7c24b8f928138a9a8ed0ee5

      </aside>

    3. List all shortcuts for the authenticated user (along with all the above fields).

      1. The list API should optionally take sort filters – for example, sort shortcuts alphabetically, sort description alphabetically, sort by created date, etc.
    4. Delete a shortcut.

    5. Search a shortcut using strings matched with shortlink , description and tags fields.

The πŸ₯ˆ secondary goal of this assignment is to document this app's design –

  1. The kind of API chosen, and why, and how it compares with other popular solutions.
  2. The kind of authentication mechanism chosen, and why.
  3. The database chosen (please don’t use MongoDB unless you have very strong justifications to do so – and if you do, please include sufficient links to trusted resources), and why, including performance considerations.
  4. Table(s) design.
    1. The tables should be built in such a way that with linear growth of shortcut data (say from 1 shortcut to a million shortcuts), search performance should not be affected.
    2. Internal metadata fields (for debugging, auditing, sorting & filtering, etc.) should be thoughtfully designed as well.

πŸ›  Technology stack

πŸͺ Bonus points

Bonus points if your solution includes any of these β€”

⛳️ Expectations

The most important things we look for in your solution are β€”