Basically if API is requested without searchQuery there is JS error on the server instead of returning an empty array of results.
Problem 2:
- I start MongoDB
- I start server
- Query server to get tweets and see results
- I stop MongoDB
- Query server to get tweets and see 503 Database is not responding
- I start MongoDB
- Query server to get tweets and see results
Stop server and stop MongoDB
- I start server (MongoDB was not started yet)
- Query server to get tweets and see 503 Database is not responding
- I start MongoDB
- Query server to get tweets and see 503 Database is not responding
(expected - Query server to get tweets and see results)
Improvement 3:
I think we could do a bit better with server code to make it cleaner. We can create a folder server/store folder and put all DB related files there (such as db.js and models/ folder). This structure is more friendly if tomorrow we wish to swap to MySQL or CSV files or any other DB we just need to replace contents of server/store folder.
Improvement 4:
To go well with #3 point we should also create tweetsStore.js file with some get method (like getTweets or get) which pulls tweets from the MongoDB and returns back a promise.
Then routes/tweets.js will be using this method to return data back. This way we decouple DB from the routes. So if tomorrow we change guts of the store functionality we keep routes untouched. Since routes do not need to know about DB operations.
I hope it makes sense but feel free to ask me questions. I can also create multiple issues if this one is too big.
So I was writing Postman files which you can import to Postman extension and test API. And I found few problems:
Problem 1:
Basically if API is requested without searchQuery there is JS error on the server instead of returning an empty array of results.
Problem 2:
Stop server and stop MongoDB
Improvement 3: I think we could do a bit better with server code to make it cleaner. We can create a folder
server/store
folder and put all DB related files there (such asdb.js
andmodels/
folder). This structure is more friendly if tomorrow we wish to swap to MySQL or CSV files or any other DB we just need to replace contents ofserver/store
folder.Improvement 4: To go well with #3 point we should also create tweetsStore.js file with some get method (like getTweets or get) which pulls tweets from the MongoDB and returns back a promise. Then
routes/tweets.js
will be using this method to return data back. This way we decouple DB from the routes. So if tomorrow we change guts of the store functionality we keep routes untouched. Since routes do not need to know about DB operations.I hope it makes sense but feel free to ask me questions. I can also create multiple issues if this one is too big.