Skip to content

Latest commit

 

History

History
261 lines (167 loc) · 12.6 KB

READMEintro.md

File metadata and controls

261 lines (167 loc) · 12.6 KB

Dark-Roasted Coffee Catalog + API

Build a brewing hot mobile app screen & the API endpoints it needs.




🎯 YOUR ASSIGNMENT

🎭 Backstory

Ahh, coffee. The universal beverage. In every country on the planet, people drink it. It's one of those special things that binds us together as human beings. No matter the culture we come from. Or the language we speak. Most of us share a common respect for a great cup of coffee.

No other beverage has inspired developers more. And so, we dedicate this challenge to coffee. A universal challenge, for a universal beverage.


Summary

The designers & system architects have been hard at work developing the UI & API you'll find in this project. And now, two important pieces are ready to be built:

  • the Coffee Catalog screen (front-end) — for discovering different coffee drinks
  • the Coffee API (back-end) — providing coffee drink data to the catalog

👉 P.S. As a full-stack developer, you'll be implementing both. The Coffee Catalog screen on the front-end. And the Coffee API providing the essential data from the back-end.


🖼️ Visual Reference

Chart Challenge


➡️ Handoffs

Design Handoff
Coffee App Designs
Password: 6MUiW

System Architecture
Coffee API - OpenAPI Spec File (the api you'll implement)
You can find the OpenAPI specification file in the spec/ folder.

Dummy Data
Dummy Data - JSON File
You can find the dummy data in the data/ folder.


📝 Acceptance Criteria

  • the Coffee Catalog screen looks & works as expected, based on the design handoff
  • the API is implemented perfectly according to the OpenAPI specification
  • the front-end renders based on data from the API

For more details, continue reading. The next section (Tasks) will provide more specifics.


Tasks

A breakdown of the assignment into smaller tasks — with more details.

  • API Implementation (back-end) 🪙18 points

    Implement the Coffee API according to the OpenAPI specification.

    The Coffee API relies on data about various Coffee Drinks. You can find this data as a json file in the /data folder. You need to provide this data through your endpoints.


    ➡️ Handoffs

    System Architecture
    Coffee API - OpenAPI Spec File (the api you'll implement)
    You can find the OpenAPI specification file in the spec/ folder.

    Dummy Data
    Dummy Data - JSON File
    You can find the dummy data in the data/ folder.


    📝 Acceptance Criteria

    • the API project is initialized inside the api/ folder — with a well-organized folder structure
    • the API is implemented perfectly according to the OpenAPI specification
    • unit tests are provided, together with clear instructions on how to run them


    • Initialize Your Project 🪙3 points

      Initialize your project inside the api/ folder, and use an well-organized folder structure.


      📝 Acceptance Criteria

      • the API project is initialized inside the api/ folder
      • a well-organized folder structure is used

    • Implement the Coffee API 🪙8 points

      Implement the Coffee API, percisely according to the OpenAPI speficiation.

      The Coffee API relies on data about various Coffee Drinks. You can find this data as a json file in the /data folder. You need to provide this data through your endpoints.

      P.S. Don't implement a database. It's not needed... yet.
      Feel free to follow best practices like the repository pattern to improve code readability, but don't go any further than that.


      ➡️ Handoffs

      System Architecture
      Coffee API - OpenAPI Spec File (the api you'll implement)
      You can find the OpenAPI specification file in the spec/ folder.

      Dummy Data
      Dummy Data - JSON File
      You can find the dummy data in the data/ folder.


      📝 Acceptance Criteria

      • the API is implemented perfectly according to the OpenAPI specification
      • modern software development principles are followed
      • clear instructions on how to run the project is provided in an easy-to-find location (such as the README.md file found in the ./api/ folder)

    • Write Unit Tests 🪙7 points

      Write unit tests for the Coffee API.

      If you don't know where to start, UnitTest by Martin Fowler is a good resource to check out. Remember, tests should help ensure high quality, make maintenance & refactoring easier, and improve the overall developer experience.

      Make sure to:

      • select & use high quality software testing packages
      • aim for balance - don't test too much, or too little


      📚 Relevant Resources

      • UnitTest by Martin Fowler


      📝 Acceptance Criteria

      • unit tests are provided, together with clear instructions on how to run them

  • Coffee Catalog Screen (front-end) 🪙19 points

    Build the Catalog Screen, as seen in the design handoff, and connect it to your Coffee API.


    ➡️ Design Handoff

    Coffee App Designs
    Password: 6MUiW


    📝 Acceptance Criteria

    • the catalog screen look & work as expected, based on the design handoff
    • the catalog is integrated with, and renders based on data from the Coffee API
    • the user is able to search through the catalog using the search box

    • Build the Catalog Screen 🪙8 points

      Build the Catalog Screen, as seen in the design handoff.

      The target screen dimensions are 375x812. Aim to make it work on any mobile device size. You can find colors, fonts and other design details in the design handoff.


      ➡️ Design Handoff

      Coffee App Designs
      Password: 6MUiW


      📝 Acceptance Criteria

      • the catalog screen look & work as expected, based on the design handoff
      • a component-based approach is taken, and components have easy-to-understand and clearly documented inputs (i.e. props).

    • Integrate with the API 🪙8 points

      Provide the UI with real data coming from the Coffee API you built.

      You need to fetch data from the Coffee API you've implemented.

      P.S. Don't worry about the rating and price values. We haven't collected these yet, so just use the values you see in the design as placeholders for now.


      📝 Acceptance Criteria

      • the right endpoints of the Coffee API are called to fetch the data needed to render the UI
      • the UI is displaying correct values coming from the Coffee API

    • Search 🪙3 points

      Implement search functionality.

      Do your best to implement search in a way that provides a good end user experience.


      👤 User Story

      From the perspective of the end user: "When using the coffee catalog, I want to search for particular coffee drinks, so that I can find what I want quickly."


      📝 Acceptance Criteria

      • search looks & works as expected, based on the design handoff and data from the API
      • the end user experience is smooth and seamless (e.g. without annoyances)
      • a component-based approach is taken, and components have easy-to-understand and clearly documented inputs (i.e. props).


⚠️ Your solution will also be quality assured. Make sure to read the Quality Assurance section as well.


Quality Assurance

In addition to the acceptance criteria associated with each task, there are also overall criteria for evaluating the quality of your work & final result. That's what this section is about.

Your solution will be reviewed by professionals, just like it would in a normal day-to-day work situation. Below you can find the criteria specifically related to quality - which together with your task completion will determine your score in the challenge.

  • Clear Component Interfaces 🪙5 points

    Are your component interfaces logical and well-named, and are they easy for others to build with?

    Your component interfaces matter. The names you choose for props, their descriptions and the default values all help to make it easier for other developers to build with your components.

  • Code Readability 🪙4 points

    is your code easy to understand (i.e. simple naming & syntax) and well presented (i.e. consistent & well documented where needed)?

    Readability is the ease with which a reader can understand your code. In programming, things such as programmer comments, choice of loop structure, and choice of names can determine the ease with which humans can read computer program code.

  • Software Package Selection 🪙5 points

    Have you chosen well-designed (e.g. easy to use & understand) highly adopted (e.g. big community, common issues raised & resolved already) and reliable (e.g. good performance, well maintained, no security vulnerabilities) and otherwise solid software packages?

    A software package (accessible through software package managers like NPM) is a collection of software components which when combined perform a set of generalized tasks that are applicable to a range of use cases.

    Selecting the right software package can lead to a better developer experience, less maintenance overhead, ease of fixing issues, and avoidance of security vulnerabilities. Selecting the wrong software package can lead to a host of issues, including unforeseen bugs, security vulnerabilities, maintenance nightmares, and much more. All of this makes selecting the right software packages an essential measure of quality.


📑 MORE INFO

❓ Frequently Asked Questions (FAQ)

Common questions and answers for getting started quickly.

How do I deliver?

To deliver your solution you'll have to commit and push the repo, and then go to the DIGGIT dashboard to submit your solution.

How do I know if I'm ready to submit?

First, check your tasks. Make sure you have given all of them your best shot. Second, check the quality assurance section. Verify that your solution is high quality by cheking your solution against this section. Once you've done your best, both in terms of tasks & quality, you're ready to submit.

I'm Stuck... help?!

Oof... sorry, but we can't do debugging for active challenges. But what we can recommend is that you take some extra time. You may just need to take a break, go have a coffee or take a walk. Or all of the above! We often find it helps to simply take your mind off the problem for a little while... Once you come back, check again your progress on both tasks & quality, and see if there is something you haven't considered or tried before. All we can ask is that you do your best. And regardless of the final result, there's a lot to gain from submitting your solution. We wish you the best of luck!