Last week you started work on a meaningful webapp that consumes an external source. This week you will learn how to store and serve data from an external source to your own clients. We'll also provide extra challenges, it's up to you if you want to add fancy features or make the app more secure. Just be sure to check your features against the rubric and to always properly test with multiple users.
You probably want to persist data in a database (tunnel event, initial load, etc.) so set up some of way of storing the data. If you want to start out simple, store the data in-memory first (like an array of data items) and move it to a database later.
Describe the chosen database system in your README.md. Make sure you only store the data you actually need for your application. This almost always involves cleaning and restructuring the data. For instance, if the external API you chose returns a complex object with confusing property names, use the functional programming trinity: map, filter and reduce to change the data to your own format.
Databases: levelup, mongo, redis, postgres
Cleaning data: array, string, object
Make sure that by Friday, your app works with at least three people connected (preferably more) at the same time. They will probably need different parts of your database so you will need to set up some server-side functionality that serves a specific part of your database depending on the type or request a clients sends. These types of requests like “getLatestData” or “sendMessage” form the basis of the API of your server. think about which methods/ events your server will have/ allow and describe them in your README.md. It’s okay if not all methods work yet but try to plan ahead, after all, we’re practicing RDD right?!
You’ve probably heard something about building robust interfaces without ignoring the UI stack. Try to address all states (blank, loading, partial, error, ideal) in your meaningful realtime webapp but take them on one state at a time. Use the scenario’s below to test if your app informs and helps the user to stay in control, even if his internet connection fails..
Build adequate user feedback for the following scenario's:
- The client can't reach the server. What does the user see? Can they still generate content which is served to the server when the connection resumes? Think about the tunnel event and how socket.io handles this out of the box. Should that behaviour change for your app? Think about queueing (real world) messages bot client and server side.
- The server can't reach the client. Should it do anything with its data model? Should other users be notified?
- The server can't reach the external source. Can the app still work? What should the end users see?