Little Web Services

Little Web Service is a non-profitable project to test our skills in networking and Go 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 a gateway that will not only direct the traffic but also create billing to users with amounts depending on the usage of their web services.
As you can all conclude based on the text above, the project will have 8 main parts. We can look at them all as separate services, all named by the greek/roman gods. Those services are:

1. Jupiter - Cloud storage API
2. Minerva - Database API
3. Vulcan - Third-Party Service Manager API
4. Mercury - Gateway, Authentication and Statistics API
5. Portunus - Cloud storage web application
6. Apollo - Database management web application
7. Juno - Third-Party Management web application
8. Venus - Main web application

Note that this specification is subject to change, and will certainly be modified in the future!

Jupiter - Cloud storage API

Jupiter is API used for managing users and their storage. The user will have the ability to host public and private files. Users will have the ability to share files only with certain people. The maximum size of local storage will be upgradeable. People working on this project will be:

• Bogdan
• Marko
• Mateja
• Marija
• Teodora

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

1. [POST/PUT] Request for uploading the file to cloud storage
2. [POST/PUT] Request for updating the file to cloud storage, preserving the link from the old file
3. [GET] Request for receiving all data for the logged user or available folder
4. [GET] Request for getting available(free) space and space taken by file
5. [POST] Request for creating a database specified by Minerva API
6. [POST] Request for deleting a selected file
7. [POST] Request for creating user space, afterward avaliable for a user to upload files to
8. [POST] Request for sharing the file for a given account name or adding a new account to list of users
9. [POST] Increasing/Decreasing available data for upgraded users

Except for the 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 need to implement some type of user privileges, possibly just by using an 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 uploaded or expansion of those files that exceed the total maximum size that is available for the user.

Minerva - Database API

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

• Filip
• Emilija
• Comi
• Stefan
• Andrijana

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

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

Except for the 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 the new query language that has the ability to translate to MongoDB query language.

Vulcan - Third-Party Service Manager API

Cloud computing offered is called Vulcan. Users can have the ability to upload their dockerfile and source code and run their own applications through our services. Usually, the users should not upload stuff like this, but in order to simplify this part of the project, users must upload dockerfile(YAML configuration) and the application's source code. People working on this project will be:

• Amela
• Lea
• Mirko
• Pavle
• Dragan

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

1. [POST/PUT] Request for uploading archive with required dockerfile and other files for starting the program on docker container
2. [GET] Request for getting CPU/RAM usage for a given container

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

1. Internal management and monitoring of containers, can be done using some type of docker swarm
2. Calculating CPU/RAM usage for containers, can be extracted using docker's own statistics.
3. Algorithm and functions to create whole docker file and communicate with them
4. This part might be tricky, but engineers here should create a way to expose the port for Docker rest API on the local network so Mercury can target it. I assume the Mercury service should create some sub-domain for that service. Will be investigated

Mercury - Gateway, Authentication, and Statistics API

The gates of our server are called Mercury. This service will manage the rest calls sent to users' applications or databases. At the same time, this API will calculate how much traffic is used by each user and initiate a bill. This service should also handle the authentication of users that want to host on our server. People working on this project will be:

• Sofija
• Aleksa
• Bojana
• Jelena
• Gazmend

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

1. [POST] Request for creating an account on LWS
2. [POST] Request for signing in on LWS
3. [GET] Request for receiving current data plan and available services
4. [GET] Request for receiving current account balance
5. [POST] Request for updating password
6. [POST] Request for updating username
7. [POST] Request for updating email
8. [GET] Request for receiving account statistics and usage of account's services
9. [POST] Request for validating authentication header

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

1. This is basically the main part of service, the gate of all other services. This means that except for other requests, this app should send emails to clients with news updates for their accounts (statistics and balance).
2. Should be able to route and navigate to subdomains made for cloud storage, database, and microservices hosted by Vulcan.
3. Authentication should be checked by this part of LWS, meaning this service needs to generate a token for the user, that the user will send to the header, service will check if it is right and proceed to forward the request to further service.
4. There should be a good algorithm for calculating how much data is used by a given service(requests sent to Vulcan). E.g. Should not calculate with the number of requests and instead should be done with a number of responses
5. Should manage the database created by the Minerva system.

Portunus - Cloud storage web application

Frontend part of the application will be described after the next meeting;

Apollo - Database management web application

Frontend part of the application will be described after the next meeting;

Juno - Third-Party Management web application

Frontend part of the application will be described after the next meeting;

Venus - Main web application

Frontend part of the application will be described after the next meeting;