- You should have Node.js and NPM installed (NPM is installed automatically with latest versions of Node.js) which are needed by both frontend and backend projects. You can verify whether you have both by running
node -v
andnpm -v
in terminal or command prompt. - You should have Angular CLI globally installed on your machine (
npm install -g @angular/cli
). - You should have Ionic globally installed on your machine (
npm install -g ionic
).
- Clone this repo on your machine and immediately delete
.git
folder.
- The main project folder contains two subfolders: frontend and backend. These two are projects on their own which you will run independently.
- The backend folder contains an express project that serves as a REST API, exposes endpoints to accept HTTP requests. For received HTTP requests, it in turn returns JSON data.
- The frontend folder contains an Angular project, which makes HTTP requests to the backend and processes the JSON data received i.e. make changes if required and display it on the UI.
- Projects are separated in this way because in the future one can easily replace either of them if the team decides to use another technology e.g. React JS for frontend or Django REST framework for backend.
- Install Node.js (must be done already, as it is a part of prerequisite!)
cd
into this frontend folder with your terminal or command prompt- Run
npm install
which will install all the required dependencies - Run just
ng serve
for a dev server. Navigate tohttp://localhost:4200/
. The app will automatically reload if you change any of the source files. - For a mobile view, run
ionic serve --port 4200 --lab
Run ng build
to build the project.
- Install Node.js (must be done already, as it is a part of prerequisite!)
cd
into this backend folder with your shell (note: if you're on Windows, you can for example use Git Bash as a shell)- run
npm install
Run npm run tsc
to compile the TypeScript code to Javascript. After that, this folder should have a build
folder containing a bunch of JavaScript files
Note: The tests in the test folder are directly written in javascript, but you still need to compile before being able to run the tests.
- Compile the backend with
npm run tsc
- Run
npm test
to execute all backend tests
In this mode, db.sqlite
is used as the database (or created if it doesn't exist).
The database isn't altered, except if an admin doesn't exist. In this case, a default admin
is created with username: admin
and password: admin
.
- Compile the backend with
npm run tsc
- Run
node build/server.js
to execute the backend. The command line output should say something likeListening at http://localhost:3000/
In this mode, a database testDb.sqlite
is created and filled with test offers and
two test users. If the database already existed, it's content will be destroyed and
replaced by the test data. This mode is useful for demonstrations.
Credentials for the created users:
- username: admin, password: admin
- username: 123, password: 123
- Compile the backend with
npm run tsc
- Run
node build/server.js testdb
to execute the backend with the test Database
The inline comments in the .ts files of this scaffolding should help you understand most of what's going on. Here are a few additional explanations:
- While the application is just JavaScript code running in Node.js (see next point), the actual source code is written in TypeScript (.ts). TypeScript is essentially "JavaScript with types", and will be compiled to JavaScript to run in Node.js. Bottom line: only edit the .ts files, since all JavaScript files in this backend are compiler-generated and will be overwritten as soon as you recompile the application.
- Since this is the backend, the JavaScript code compiled from TypeScript will not be running in a web browser. Instead, we use Node.js as our JavaScript runtime. You can think of Node.js as something similar to the Java Virtual Machine to run your compiled Java program, or a Python interpreter to run your Python code.
- Because we want to build a web server, we are using the Express.js JavaScript web framework to help us with handling requests and providing responses. If you study the import statements in this scaffolding, you can see Express.js how is being used here.
To add a new endpoint that logically belongs to an existing controller, you simply have to add a new route to that controller's Router.
If you need to define a new controller, there are a few things you need to do:
- create a new file
<mycontroller>.controller.ts
in thecontrollers
folder. Check out our example controllers to see what to do within that file. - Import your new controller in
server.ts
- in
server.ts
, mount the new controller analogous to the ones that are already in there (usingapp.use(...)
)
Mocha is used for the testing in the backend.
So far, you need to recompile your TypeScript code and restart your express application after every change. This can get annoying really quickly, but can streamline this process by doing two things:
- Instead of
npm run tsc
, usenpm run tsc -- --watch
. This will automatically recompile your TypeScript code to JavaScript every time a TypeScript file has changed on disk, as long as this command is running (i.e. until you abort it or close the shell). Don't forget to check that shell for compiler errors! - Install nodemon on your system (
npm install -g nodemon
), then run the express application usingnodemon build/server.js
(instead ofnode build/server.js
). Similar to the--watch
command above, this will restart your Node application (and thus, your server) every time a JavaScript file has changed on disk.
As long as you let these two processes run in two separate shells, your Node server should always be running and be up to date with your latest changes, every time you save one of your TypeScript files.
The frontend must be running on port 4200 and the backend on port 3000, no matter what enviroment the programms are running in.
A regular user can see offers, but can't do anything with them. A logged in user can see offers as well as contact data of the user submitting the offer. If the user wishes to purches the offer, he must contact the user by the means provided outside of the platform. A logged in user can also create an offer, which needs to be validated by the admin, however. An admin has all the powers a regular user has, but can also validate offers, or deny them with a reason. He can also delete offers that are not his own; whis option is mainly to delete obvious nonsense offers, rather than sending them back to the user to change and resubmit - or to remove fraudulent offers that have already been set to public.