Как да пишем красиви API на Node.js, използвайки async / await и базата данни Firebase

Този урок ще обхваща типичните случаи на използване, които ще срещнете, когато пишете крайни точки на RESTful API за четене и запис в екземпляр на база данни Firebase.

Ще се съсредоточи върху красивия асинхронен код, който използва функцията за асинхронизация / изчакване в Node.js (налична в v7.6 и по-горе).

(Чувствайте се свободни да се усмихвате сладко, докато махнете сбогом на обратния разговор )

Предварителни

Предполагам, че вече имате създадено приложение Node.js с SDK за Firebase Admin. Ако не, тогава проверете официалното ръководство за настройка.

Писане на данни

Първо, нека създадем примерна крайна точка POST, която ще запише думи в нашия екземпляр на базата данни на Firebase:

Това е много основна крайна точка, която отнема потребителски идентификатор и стойност на думата, след което запазва дадената дума в колекция от думи. Достатъчно просто.

Но нещо не е наред Липсва ни работа с грешки! В горния пример връщаме код за състояние 201 (което означава, че ресурсът е създаден), дори ако думата не е била запазена правилно в нашия екземпляр на база данни Firebase.

Така че, нека добавим малко обработка на грешки:

Сега, когато крайната точка връща точни кодове на състоянието, клиентът може да покаже подходящо съобщение на потребителя. Например „Думата е успешно запазена.“ Или „Невъзможно е да запазите дума, щракнете тук, за да опитате отново.“

Забележка: ако някои от синтаксиса ES2015 + ви изглежда непознат, проверете ръководството за Babel ES2015.

Четене на данни

Добре, сега, когато написахме някои данни в нашата база данни Firebase, нека се опитаме да четем от нея.

Първо, нека да видим как изглежда крайна точка GET, използвайки оригиналния метод, базиран на обещания:

Отново, достатъчно просто. Сега нека го сравним с асинхронизирана / чакаща версия на същия код:

Обърнете внимание на добавената ключова дума async преди параметрите на функцията (req, res) и чакащата ключова дума, която сега предхожда израза db.ref ().

Методът db.ref () връща обещание, което означава, че можем да използваме изчакващата ключова дума за „пауза“ изпълнение на скрипта. (Ключовата дума в очакване може да се използва с всяко обещание).

Окончателният метод res.send () ще стартира само след изпълнение на обещанието db.ref ().

Това е всичко добре и добре, но истинската красота на асинхронизирането / чакането става очевидна, когато трябва да свържете няколко асинхронни заявки.

Да речем, че трябваше да изпълнявате редица асинхронни функции последователно:

Не е красиво. Това е известно още като „пирамида на обречеността“ (а ние още дори не сме добавили обработващи грешки).

Сега погледнете горния фрагмент, пренаписан, за да използвате async / wait:

Няма повече пирамида на обреченост! Нещо повече, всички изчакващи изявления могат да бъдат увити в един блок за изпробване / хващане, за да се справят с всички грешки:

Паралелни асинхронни / чакащи заявки

Какво ще кажете за случаите, когато трябва да вземете няколко записа от вашата база данни Firebase едновременно?

Лесно. Просто използвайте метода Promise.all (), за да стартирате паралелно заявките на базата данни на Firebase:

Още нещо

Когато създавате крайна точка за връщане на данни, извлечени от екземпляр на база данни Firebase, внимавайте да не върнете просто snapshot.val (). Това може да причини проблем с JSON разбора на клиента.

Например, кажете, че клиентът ви има следния код:

Върнатата от Firebase Snapshot.val () може да бъде или JSON обект, или нулева, ако няма запис. Ако null бъде върнат, response.json () в горния фрагмент ще изведе грешка, тъй като се опитва да анализира тип, който не е обект.

За да се предпазите от това, можете да използвате Object.assign (), за да върнете обект винаги на клиента:

Благодаря за четенето!

Интересувате ли се да видите проект в реалния свят, изграден върху Firebase и Node.js? Вижте Vocabify, създателя на речника, който ви помага да запомните думите, на които попадате.