greeting_drawing

Little Web Services

Little Web Service is a non-profitable open-source project to test our skills in networking and golang development.
The goal of this project is to create simple IaaT(Infrastructure as a Service) and SaaS(Software as a Service) using Go programming language.

The users of our service should be able to upload their web service, use our non-relational database and use cloud storage similar to Google Drive. Everything will be regulated with gateway which will not only direct the traffic but also create billing to users with amount depending on usage of their web services.
As you can all conclude based on text above, the project will have 4 main parts, each containing backend and frontend. We can look at them all as separate services, all named by greek/roman god. Those services being:

  • Mercury - Gateway, Authentication and Statistics
  • Jupiter - Cloud storage
  • Minerva - Database
  • Vulcan - Microservices Manager API
  • Venus - Main web application 🚧
  • Portunus - Cloud storage web application 🚧
  • Apollo - Database managment web application 🚧
  • Juno - Third-Party Managment web application 🚧
Frontend services will be done at later stage of the project 🚧
drawing

Mercury service_drawing

The gates of our server are called Mercury. This service will manage rest calls sent to users applications or database. At the same time, this API will calculate how much traffic is used by each user and initiate a bill. This service acts as a managment service for our users, too.

Mercury should be implemented as REST API Server, with functional requirements being:

  1. POST Creating account on LWS
  2. POST Signing in on LWS
  3. GET Receiving current data plan and avaliable services
  4. GET Receiving current account balance
  5. POST Updating account balance
  6. POST Updating password
  7. POST Subscribe to alert
  8. GET Receiving account statistics and usage of account's services
  9. POST Validating authentication header
  10. GET Getting the UUID from username

Except for given request, this service should realize the following features:

  1. This app should send emails to clients with news update for their account(statistic and balance).
  2. Should be able to route and navigate to subdomains made for cloud storage, database and micro services hosted by Vulcan.
  3. Authentication should be checked by this part of LWS, meaning this service needs to generate token for user, that user will send in header.
  4. There should be a good algorithm for calulating how much data is used by given service(requests sent to Vulcan or Minerva). E.g. Should not calculate with number of requests and instead should be done with number of responses

Jupiter service_drawing

Jupiter is cloud storage API. The user will have ability to host public and private files. User will have ability to share files only with certain people. Maximum size of local storage will be upgradable.

Jupiter should be implemented as REST API Server, with functional requirements being:

  1. POST/PUT Uploading file to cloud storage
  2. POST/PUT Updating file to cloud storage, perserving the link from old file
  3. GET Downloading file
  4. GET Receiving all data for logged user or avaliable folder
  5. GET Getting info about file
  6. POST Creating database specified by Minerva API
  7. POST Deleting selected file
  8. POST Creating user space, afterwards avaliable for user to upload files to
  9. POST Making file or directory public
  10. POST Sharing file or directory with another user with given privileges
  11. POST Increasing/Decreasing avaliable storage space for upgraded users

Except for given request, this service should realize the following features:

  1. Controlling the internal structure of file-system, something like unix-like(Linux e.g.) systems directories. Basically meaning each user can have his own directory, and can access only that directory, while he can also see shared directories of other users. This means that engineers working on this service needs to implement some type of user privileges, possibly just by using authentication header.
  2. Internally, this service should be able to host any type of file, but should check the size of those files and should terminate uploading or expansion of those files that exceed the total maximum size that is avaliable for user.

Minerva service_drawing

Database solution which is offered using our services will be simple document NoSQL database. Users will have the ability to initiate simple queries using this API. Integration of this database will be used for authentication of users using our services, too. Tokenizer should be implemented with this API.

Minerva should be implemented as REST API Server, with functional requirements being:

  1. POST Request for creating empty database
  2. GET Request for getting data for given query
  3. POST Request for sending query that modifies database(like ALTER, INSERT, DROP, DELETE equivalent of Relational Databases)

Except for given request, this service should realize the following features:

  1. Internal NoSQL database implementation and handling the queries, mongoDB can be used
  2. Queries should be custom, meaning engineers working on this service should create grammar, parser and lexer for new query language that has the ability to translate to mongoDB query language.

Vulcan service_drawing

Cloud computing service is called Vulcan. Users have the ability to upload their dockerfile and source code and run their own application trough our services. Usually, the users should not upload stuff like this, but in order to simplify this part of project, users must upload dockerfile(yaml configuration) and application's source code.

Vulcan should be implemented as REST API Service, with functional requirements being:

  1. POST/PUT Uploading archive with required dockerfile and other files for starting program on docker container
  2. POST Starting the docker container
  3. POST Stopping the docker container
  4. POST Removing the docker container
  5. POST/PUT Updating the archive with required dockerfile and other files for starting program on docker container
  6. GET Getting CPU/RAM usage for given container
  7. GET Getting time container worked this month/week/day
  8. GET Active period statistics

Except for given request, this service should realize the following features:

  1. Internal managment and monitoring of containers
  2. Calculating CPU & RAM usage for containers, can be extracted using docker's own stastics.
  3. Algorithms and functions to create whole docker file and communicate with them
  4. Expose port for Docker rest api on local network so Mercury can target it. I assume Mercury service should create some sub-domain for that service. Will be investigated

Venus - Main web application service_drawing

Frontend part of the application will be described later;

Portunus - Cloud storage web application

Frontend part of the application will be described later;

Apollo - Database managment web application

Frontend part of the application will be described later;

Juno - Microservices Manager application

Frontend part of the application will be described later;

Table of Contents