고경철

고경철님의 아티클

고경철

고경철

DeepBlue

This project is part of [Silicon Valley Winter22 Bootcamp]

Github: https://github.com/SVTeamJ/DeepBlue

Are you a fish enthusiast looking to learn more about the different types of fish in the ocean? DeepBlue is a website that utilizes machine learning to classify other fish species accurately.

With DeepBlue, you can upload a photo of a fish, and our machine-learning algorithm will give you its species name and some interesting facts about it.

Our website is designed for user-friendliness with an intuitive guide. As the user uploads the image, the user will be able to see the result on the page that shows all the fish information immediately. The data is retrieved from our trained database. DeepBlue has the potential to serve fishers, aquariums, researchers, and many more parties who need to identify fish species. Enough with the background; let’s dive into our journey of the project.

Git Commit and Convention

As the collaboration tools, we used git and GitHub for version control and slack for general communication. Our general workflow is the following:

  1. Assign tasks on Monday
  2. Create issues and make the branch according to the convention issue names and issue numbers
  3. Switch to the issue name with the issue numbers
  4. Implement the task
  5. Make the pull request to the development branch
  6. Get reviews of the tasks
  7. Push to the development branch

We also tried to follow a consistent commit message pattern. We used the following format:

<type>: <description>

We chose these seven types for git commit:

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes to the styles such as space, formatting, and missing semi-colons
  • refactor: A code change that neither fixes a bug nor adds a feature
  • test: Adding tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

We kept the descriptions simple in the commit message because further descriptions and implementation details can be found on the issues we created.

System Architecture

ERD

Here is the picture of our ERD. Based on this ERD, we made models using SQLAlchemy, a python ORM(Object Relational Mapper) for communicating with the database. For the database, we used MySQL, a powerful and reliable open-source RDBMS(Relational Database Management System). SqlAlchemy provides an easier way to interact with the database, allowing us to create, update, and delete data from the database. With MySQL and Sqlalchemy, we can strongly interact with the database, ensuring our data is secure and consistent.

Tech Stacks

Frontend

We used react because of the following reasons:

  1. Community Support
  2. Reusable Components
  3. Fast render with Virtual DOM

Recoil

We could have used reduce as a state management library but reduced all unnecessary rendering, but we chose to use recoil for the management library. One reason is that reduce is not optimized for React. Additionally, recoil keeps track of only changed components for rendering.

React-query.

React-query is great for diving server and client data. One big advantage of using react-query is that it is easy to bring data from the server, and it is convenient to update values and use cache, error handling and write asynchronous codes.

Typescript

Typescript is JavaScript for application-scale development. Type checking is one of the most significant features of TypeScript. We define types in Type-script and can reduce unexpected errors. We call this “static typing”. That is the reason why we chose TypeScript.

Sass

We used sass because Sass enables us to write responsive websites easily and uses variables for reusable components.

Backend

We chose FastAPI as an API framework because of the following reasons:

  • Easy to learn and implement APIs
  • Fast development
  • Auto-generating documentation with swagger
  • Validations with Pydantic
  • Well-organized official documents

And, We chose uvicorn as an ASGI server because it is light and compatible with FastAPI.

💡 ASGI? ASGI (Asynchronous Server Gateway Interface) is a specification for building asynchronous web applications such as web servers, frameworks, and clients. ASGI provides a single API abstraction for Python web applications and allows the application to be served by any ASGI-compliant web server without waiting for DB transactions and API; at the same time, the CPU could do other jobs in the meanwhile.

Swagger

Swagger is a powerful open-source framework for creating and documenting APIs. It uses a language-agnostic interface to define an API's structure and automate documentation generation. Swagger provides an easy way to interact with the backend and test endpoints. It also allows us to view the structure of our API in a graphical representation and easily generate code samples in several programming languages. We chose this tool because it is fast, efficient, and provides an easy way to document our API.

We have the following APIs:

  • signup, login, logout
  • upload images to ai servers
  • create and get the fish history
  • charts information

AI

We used pre-trained models from five different fish. We used AI models from YOLO v5; once the users upload the image, the AI models return the fish information, which is mapped to our fish database and returns the fish information through our API. Since it takes time to process the requests for the AI server, we decided to add celery for non-blocking, which reduces the AI requests time. On top of that, RabbitMQ is added so that it ensures the credibility of our AI responses.

DevOps

We used dockers, in which we containerize each component so that it can be run on multiple operating systems. On top of dockers, we used Amazon EC6 for deployments, an Amazon Web Services (AWS) service that provides scalable computing capacity in the cloud. We figured AWS would be the perfect fit since AWS offers free tiers. We used Amazon S6 for storing uploaded fish images. S6 stores data as objects, which are organized into buckets.

To make the deployment easy and smooth, we chose to implement github action as CI/CD.

CI/CD? It stands for Continuous Integration and Continuous Delivery. CI/CD is the practice of continuously integrating code changes into a version control system and then delivering those changes to the production environment, usually through automated processes. We used GitHub Actions for our CI/CD pipeline.


Demo Videos

Home Page

Chart Page

Login/Sigup

Thank you so much for reading!

5
2