Aplikacja na magisterkę - Cześć 2 - Konfiguracja BE

Aplikacja na magisterkę - Cześć 2 - Konfiguracja BE

Poprzedni wpis był swego rodzaju zapowiedzią tego, co zamierzam ukończyć przez najbliższy rok, by przed terminem obrony móc pochwalić się gotowym, w pełni działającym i spełniający moje wymagania produktem. Przedstawiłem listę technologii i narzędzi, których chce używać i używam, a także ostatnimi dniami doszedłem do wniosku, że dobrym pomysłem byłoby postawienie całej aplikacji na usłudze pokroju AWS lub Azure. Będąc szczerym, bardziej ciągnie mnie do tego pierwszego, choć chyba popularniejszym wyborem, a przynajmniej w Polsce jest usługa od Microsoftu. Jednakże są to jeszcze plany, ponieważ pod znakiem zapytania stoi kwestia tego, ile będę w stanie poświęcić na to czasu. Nie ukrywam, że obecna praca nie łączy się z tym, co robię w ramach studiów. Brakuje ten samej ilości energii, którą ma się na początku każdego dnia.

Szkielet aplikacji

Nie jestem pewien czy nie jest za wcześnie, żeby o tym pisać, aczkolwiek myślę, że zostanę przy standardowej konstrukcji, jaką znam i jaka mi się podoba. To znaczy, katalog /src jako główny kontener aplikacji, a w nim poszczególne komponenty wyciągnięte do oddzielnych folderów, przykładowo: /users, /profiles itp. Lecz nie jestem pewien co do nazewnictwa, czy lepiej zostawić liczbę mnogą z -s na końcu, czy zmienić na liczbę pojedynczą. Brakuje mi informacji, czy jest to jakaś przyjęta konwencja nazewnictwa, czy wyłącznie zależy od preferencji zespołu bądź osoby tworzącej oprogramowanie. W każdym razie zostanę na razie przy liczbie mnogiej. Natomiast całość prezentuje się w takim formacie:

/api
	/dist
	/migration
	/node_modules
	/src
		/dto
		/interfaces
		app.controller.spec.ts
		app.controller.ts
		app.module.ts
		app.service.ts
		main.ts
	/test
	.env.development
	.env.production
	.eslintrc.js
	.gitignore
	.prettierrc
	nest-cli.json
	ormconfig.json
	package.json
	README.md
	tsconfig.build.json
	tsconfig.json
	yarn.lock

Do końca nie jestem pewien czy katalog /dto będzie mi potrzebny albo, czy miejsce, w którym się znajduje, jest tym właściwym. To, co chciałbym w nim trzymać to struktura danych, jaką dostawałbym od warstwy widoku w przyszłości. Z kolei katalog /interface służyłby mi bardziej do definiowania bardziej rozbudowanych typów, które tyczyłby się wyłącznie struktur. Takim przykładem może być typowanie dla wiadomości zwrotnej, w której chce umieścić status HTTP, wiadomość lub dodatkowe informacje. Swoją drogą oglądając Festiwal React.js i GraphQL nie wiem, czy nie zastosować tego, o czym wspomniał jeden z prelegentów - Michał Miszczyszyn, właściciel Type of Web - i nie zastosować type zamiast interface ale musiałbym bardziej przyjrzeć się temu i ocenić czy ma to jakiś większy wpływ na pisanie aplikacji.

Zdjęcie autorstwa Negative Space z Pexels

Pierwsze kody

W takim razie zacznijmy od zmiennych środowiskowych, co prawda coś o nich wiem, zdaje sobie sprawę, do czego służą, ale nigdy nie uwzględniałem ich w skryptach zadeklarowanych w package.json. To będzie mój pierwszy raz, chyba... Jak widać na strukturze wyżej, posiadam dwa pliki, jeden jako dane pod lokalny development, a drugi jako dane pod produkcje, czyli gdy aplikacja zostanie wysłana na jakiś zewnętrzny serwer. W przypadku tego drugiego jest on jeszcze zupełnie pusty, ponieważ nie widzę sensu, by umieszczać w nim cokolwiek. W pliku .end.development na chwilę obecną trzymam takie dane jak dostęp do bazy danych czy klucz wymagany do generowania JSON Web Tokenu:

DATABASE_HOST=localhost
DATABASE_PORT=5432
DATABASE_NAME=postgres
DATABASE_USER=postgres
DATABASE_PASSWORD=root
JWT_SECRET=...

Poza tym na podstawie tego, jak zachowywał się mój WebStorm, a raczej ESLint zauważyłem, że zadeklarowanie zmiennej środowiskowej w taki sposób DATABASE_HOST = localhost nie jest tym samym co DATABASE_HOST=localhost. Ponieważ w przypadku pierwszej możliwości chcąc wykorzystać tą konkretną wartość musiałem się odwoływać do klucza (DATABASE_HOST) ze spacją na końcu process.env["DATABASE_HOST "], ponieważ edytor wypluwał mi błąd. Zaskoczyło mnie to o tyle, ponieważ we wcześniejszych projektach, które realizowałem w Visual Studio Code takiego problemu nie było, dlatego zgaduje, że mimo wszystko jest to wina ustawień IDE, a nie fakt rzeczywisty związany ze zmiennymi środowiskowymi.

Następnie podążając według dokumentacji NestJS, zostało mi jedynie ustawić połączenie z bazą danych w pliku app.module.ts co oczywiście uczyniłem. Chociaż przyznam się, że na początku zdecydowałem się użyć Sequelize zamiast TypeORM, ale strasznie zniechęciła mnie do dalszego używania składnia i zbyt obszerna dokumentacja.

import { Module } from "@nestjs/common";
import { ConfigModule } from "@nestjs/config";
import { TypeOrmModule } from "@nestjs/typeorm";
import { AppController } from "./app.controller";
import { AppService } from "./app.service";
import { Connection } from "typeorm";

@Module({
    imports: [
        ConfigModule.forRoot({
            envFilePath: [".env.development", ".env.production"],
        }),
        TypeOrmModule.forRoot({
            type: "postgres",
            host: process.env["DATABASE_HOST"],
            port: parseInt(process.env["DATABASE_PORT"]),
            username: process.env["DATABASE_USER"],
            password: process.env["DATABASE_PASSWORD"],
            database: process.env["DATABASE_NAME"],
            entities: [],
            synchronize: false,
        }),
    ],
    controllers: [AppController],
    providers: [AppService],
})
export class AppModule {
    constructor(private connection: Connection) {}
}

Następnie uruchomienie aplikacji w celu sprawdzenia poprawności połączenia i voila konsola w przejrzysty sposób wypluła mi wiadomości zwrotne o powodzeniu całej operacji.

Podsumowanie

Chciałbym zaznaczyć, że wpis ten nie przedstawia realnego stanu aplikacji. W rzeczywistości zostało napisane dużo więcej, jednakże z powodu czasami niewielkiej ilości czasu wolnego, szybciej jest mi coś zakodować niżeli przysiąść do napisania postu. Lecz obiecuje, że w następnym bądź góra w dwóch najbliższych postach, to co przedstawiam na blogu i to, co znajduje się na repozytorium, będzie pokrywało się jeden do jednego. Dopiero wtedy udostępnię obiecane linki, choć z drugiej strony nie trzeba się dużo na gimnastykować, by samemu dogrzebać się repozytorium. W ostatnim czasie zakupiłem również dwie książki, które chciałbym wykorzystać podczas pisania tej pracy zarówno pod kątem teoretycznym, jak i praktycznym. Jedną z nich jest "Bezpieczeństwo Aplikacji Webowych" od Sekurak, natomiast drugą pozycją, którą niestety nie jest jeszcze dane mi widzieć: "TypeScript na poważnie" od wspomnianego już wcześniej w tym wpisie Michała Miszczyszyna.

Mam nadzieje, że z obu pozycji wyciągnę dużo wartościowej wiedzy, a tymczasem do zobaczenia w kolejnym wpisie!