Witam, dziś kolejna część przygód dzielnego frontend developera. Przypomnę w skrócie co się wydarzyło do tej pory. Otóż stanąłem przed misją postawienia serwera na node.js. Są już nawet pierwsze efekty, serwer stoi i działa a do tego napisany jest w typsciprcie. Dokonałem także małego odkrycia: mój serwer nie potrzebuje webpacka (tak wiem, mogło to być oczywiste, ale jakoś tak z rozpędu ….. itd). Wystarczy dobrze skonfigurowany typescript i wszystko pięknie się kompiluje. Więc usunąłem webpacka z projektu jak również wszystkie jego zależności loadery i typ podobne. Ogólnie jest pięknie 🙂
W poprzednim wpisie wspominałem, że w następnym kroku (czyli dziś) chcę dodać routing po stronie serwera. Ale jak to bywa w IT-owym życiu trzeba być agile i dostosować się do zmian. Zmiany te zachodzą głównie w mojej głowie. Bo w sumie, na ten moment routing mam napisany po stronie aplikacji i działa bardzo fajnie, więc temat ten na razie zostawię a skupię się na czymś innym. Zagadnienie które wziąłem na warsztat jest API oraz Firebase. Połączenie tych dwóch abstrakcji pozwoli mojemu serwerowi czytać dane z bazy (do tej pory robiła to sama aplikacja). Aplikacja będzie za pomocą API odpytywać o dane
a serwer będzie zwracał selektywnie wybrane najważniejsze dane. Normlanie security +10.
Ok to czas zacząć. Na początek dodanie Firebase SDK do projektu:
npm install firebase-admin --save
potem w pliku app.js dodaje
import admin from "firebase-admin";
na stronach Firebase jest bardzo fajnie opisane sposób instalacji i dodawania dostępów. Tam naprawde jest wszystko opisane i przedewszystkim aktualne, więc nie ma sensu abym tutaj kopiował opisy stamtąd, po prostu jeżeli ktoś chce się dowiedzieć więcej to link jest >tutaj<
W rezultacie mam na moim serwerze działający pakiet Admin Firebase, można więc tworzyć endpointy. Pierwszy endpoint będzie ustawiał rezerwacje na książkę. Koncepcja jest taka, że jak aplikacja zrobi requesta pod adres /api/book/send to nastąpi rezerwacja książki na bazie. Ok, na początek dodałem do serwera routing obsługi requesta
import bookRouter from "./routes/book";
app.use('/api/user', bookRouter);sam router na tem moment ma dodaną jedna ścieżką:
import {Router} from 'express';
import {reservation} from "../controllers/reservation";
const router = Router();
router.post('/send',reservation)
export default router;czyli mam wszystko przygotowane, pozostaje tylko napisać funkcję która realnie obsłuży request. Ponieważ pisze w typescript to wszelkie funkcje itp muszą mieć zdefiniowane typy, powiem szczerze, że na początku sprawiło mi to trochę problemów, co z czym połączyć i jakim typem. Lecz po chwili to wszystko ułożyło mi się w głowie i mogłem swobodnie dalej pisać kod. W requeście wykorzystuje dane przekazane z aplikacji, więc dodałem body-parser oraz typy do niego, aby łatwiej było odczytywać informacje oraz budować odpowiedzi serwera.
npm install --save body-parser npm i @types/body-parser
W następnym kroku utworzyłem funkcję “reservation”. Funkcja ta wyszukuje książkę o podanym id w bazie i dodaje ją do rezerwacji użytkownika. Tak to wygląda w teorii, a w praktyce? Utworzyłem interface książki dla danych przychodzących z bazy:
export interface Book{
title:string,
author:string,
type:string,
bookID:string,
pages:number,
issn:string
}następnie odpytałem bazę o książki, a w szczególności o tą jedną która mnie interesuje. Firebase nie wspiera zapytań “where” więc serwer odpytuje bazę o wszystkie książki a następnie stara się znaleźć tą właściwą (będę musiał to zoptymalizować jeszcze). Chciałem aby apka poczekała na rezultat tej operacji dlatego użyłem await / async. Moja funkcja pomocnicza zwraca Promise typu bookType który został utworzony na podstawie typu interface’u “Book”
import {Book} from '../model/book;
type bookType = Book | undefined;
export const getBookById = async (id: string):Promise<bookType> => {
const db = admin.database();
let book: bookType ;
await db.ref("/book").once("value", function (snapshot) {
const allBook: Book[] = []
snapshot.forEach(childSnapshot => {
allUsers.push({
id: childSnapshot.key,
...childSnapshot.val()
});
});
book = allBook.find(item => { return item.bookID === id; });
})
return book;
}jeżeli książka istnieje to jest dodana do użytkownika za pomocą kolejnej funkcji pomocniczej, ta funkcja jest typu Promise<void> bo defacto nie zwraca żadnych danych.
export const addReservationToUser = async (userID:string,bookID:string):Promise<void> => {
const db = admin.database();
await db.ref(`users/${userID}/reservations/${bookID}`)
.set(status)
.then(() => {
return true;
})
.catch(error => {
throw new Error("Can't set reservation");
});
};Teraz to wszystko trzeba ze sobą połączyć. @types/express zapewnia nam typowanie requestów. tj “RequestHandler”, co niezwykle usprawnia pracę:
type bookType = Book | undefined;
export const reservation:RequestHandler = async (req, res, next) => {
const bookID = (req.body as {bookID:string}).bookID;
const userID = (req.body as {userID:string}).userID;
const book:bookType = await getBookById(bookID)
if(book){
await addReservationToUser(book.bookID,userID)
}
res.json({status:200, msg:'Done'})
}Szybkie testy za pomocą Postman pokazują, że rozwiązanie działa 🙂 No to pozostało mi tylko z aplikacji “strzelić” do mojego serwera. Za pomocą Axiosa stworzyłem zapytanie do serwera, odpaliłem serwer oraz aplikacje lokalnie. Kliknąłem magiczny guzik na interfejsie aby zobaczyć moje rozwiązanie w praktyce i ….. bang!!!! cors origin policy error!! Aaaaa, normalnie trochę mi ciśnienie skoczyło, biorąc pod uwagę, że był już środek nocy (a nawet już długo po środku nocy ) a ja chciałem tym testem zakończyć pracę na ten dzień, nie był to komunikat który chciałem zobaczyć 🙂
Na szczęście na stronie express znalazłem szybkie rozwiązanie, które pozwoliło mi przeskoczyć to issue. Wiem, że w późniejszym czasie będę musiał się bardziej pochylić na CORS’em, ale na ten moment to wystarczy.
app.use(function(req, res, next) {
res.header("Access-Control-Allow-Origin", "http://localhost:8080");
res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
next();
});Więc jeszcze raz odpaliłem serwer, na apce kliknąłem guzik i …. ta da!!! działa 🙂 zapytania wykonują się poprawnie, na bazie zachodzą przewidywane zmiany, ogólnie jest super 🙂
To był pierwszy z endpointów na tym serwerze, następne kilka dni poświęcę na optymalizację ich pod moją aplikację, ale globalny kontekst jest poprawny. Odkryłem też jedną jeszcze rzecz, zmiany w kodzie na serwerze wymagają za każdym razem restartu serwera, robiąc to ręcznie można szału dostać, dlatego polecam “nodemon” jest to paczka która “nasłuchuje” zmian w kodzie i automatycznie restartuje serwer za nas, bardzo pomocne 🙂
npm install nodemon --save-dev
wystarczy dodać jeden wpis w konfiguracji:
"start-dev": "nodemon ./dist/app.js"
teraz za pomocą npm run start-dev uruchamiamy nasz serwer w developerskim trybie automatycznego restartu, naprawdę super sprawa.
To tyle treści na dziś. Mam nadzieję, że komuś to kiedyś pomoże zawalczyć w własnym serwerem w node.js. W najbliższym czasie skupię się na optymalizujących w istniejącym kodzie, oraz na rozszerzeniu API. Za jakiś czas wrócę z wpisem o jeszcze paru funkcjonalnościach na serwerze a potem z wpisem o finalnym produkcie którego dotyczy ten serwer. Jeżeli podobała Ci się ta seria, lub chcesz dać mi jakiś feedback, to napisz komentarz pod wpisem, lub na linkedin lub w prywatnej wiadomości. Ja tymczasem udaję się na urlop 🙂
Cześć!