(Or explore whether this is actually useful somewhere.)

There might be cases where we should not only compare timestamps on the new and existing records. For example, whenever a field is set on the record received from the API that is not yet known in the local state, there's no harm in putting that data there. However, whether there's actually situations where this is worth the effort is a different question.

This will take up a bit of space in the current form.

This will need the admin's manual effort at the moment.

Based on browser settings, the web application should try to determine the best initial locale setting for users that are not logged in and do not have a setting cached.

Many API operations return multiple entities from different databases, it might well be more efficient to fetch them in one BatchGetItem operation rather than individual GetItem ones.

One should be able to create a user account and log in and out.

In addition to what they currently do ( #11 ), it would be cool to

• when data is available, check whether it hasn't been updated in a while and auto-refresh on mount if it is too old
• make a more specific distinction between loading states, for example to differentiate between "error occurred while loading data" and "request was successful, but the required data was not available"
• allow custom checks on the data, not just "these props must not be null" but maybe also "this prop must be a non-empty array" or "this field on this prop must be set"

It's always annoying when that doesn't work as expected.

The pool record needs to be extended by a set of special bet definitions, and we need a new sort of bet bucket that stores a pool's participants' bets for these.

Need one "public" page for a match day which shows the matches it contains, and two for a given match day and squad, one with the matrix of bets and one with the match day ranking.

It shouldn't have the SCMPS logo forever.

This is currently an empty placeholder.

Users need to be able to submit their bets for the extra questions and edit their bets later on, as long as the deadline has not yet passed.

When you join two or more pools, you wouldn't want to enter all your bets again, and probably you shouldn't be able to as well.

There should be a message like "Before you can do anything really, please confirm your email" and also a button to send the confirmation email again.

No handlers for that yet, all from the sample state so far. That needs to change obviously.

On the match day bets page, when a user clicks on one of their own cells, a form should open that allows them to enter a new bet or edit the existing one.

When a game is about to begin (say within the next one or two hours) and some people haven't entered their bets for it, they should receive an email notification. Unless they don't want to, of course.

The Lambdas should obviously retrieve their data from a database rather than from hard-coded sample values.

With React Router in place, the URLs of all the sub-pages are generated dynamically. When you copy a URL and want to go back to it later, it normally won't find it because no such files exist in the hierarchy. We need to map all requests to index.html. S3 allows one index page and one error page for the Public Website Hosting mode, so setting index.html for both will make it always show up. However, even though users may not see it if they just type in the URL or click the bookmark, the browser will still receive a 404 response for all sub-pages. Ideally this should not happen, but ideally that better alternative shouldn't cost money either.

Need a way to represent squads, membership of users in squads, and the bets of users in a squad for a given match day.

The API must allow to query extra questions for a pool and submit bets. It also needs to deliver team data which is required for these.

When the user navigates to a valid URL, but the data that is to be expected there is not in the state or hasn't been updated in a long time, query the server and show some kind of activity indicator in the mean time.

For large parts of the data, it should be safe to cache them in the page's local storage to reduce API load. And from some hints on the Redux documentation, it sounded like it was easy to set up as well.

Everyone will want to upload a picture.

It's currently not.

Rather than just numbers, it would be nice to have a speaking identifier to be used in the URLs.

One should be able to switch between different languages for the UI.

To make the update mechanism work, we need to make sure the timestamp is actually increased when something is written to an object in the database.

Would definitely be better if that worked.

When data is cached locally, it may be more or less reasonable to ask the API for a refresh. For example, if a tournament has already begun, it is quite unlikely that the basic data on the Tournament instance itself is going to change. And even more so when it is over. When all matches of a match day are over (or at least the last ones have already begun) it is unlikely that the bets are going to change. An additional "last refresh" field (that is only used on the client side) might be very useful for that too.

Sending binary data through API Gateway seems to be not very well supported, and setting the option doesn't change anything really. So for now, use base64 encoding on the data that is sent.

It's not even complete and I already know it's going to be ugly.

When the deadline looms, it should be clear that the user needs to hurry if they want to enter their answers.

This is currently an empty placeholder.

Given that this application should ideally run with AWS's Free Tier, it does not make sense to store all data in DynamoDB in a normalised kind of way. For example, for most use cases the only information that needs to be retrieved from the users table is the preferred username, but it will require a batch read operation that will consume lots of read capacity each time. These preferred usernames might be stored with the pool and squads records, for example.

These can potentially use up a lot of space on the pool record. They may have to be moved to a table of their own alternatively.

That looks very much hacked together at the moment. Even with Go, there should be room for improvement.

Currently has a wildcard to allow local testing. Probably want to configure this via a build variable and set up a local API for local testing.

This page should contain a link to the squad, the list of squad members that have signed up for this particular pool, and links to the bets pages by match day. Later maybe include a current ranking.

As a user I want to know when the app is currently working in the background, i.e. fetching data from the API, and when that is completed (or has failed).

Cognito stores the basic user data, but pool-related data like squad membership and pool registrations need to be retrieved from the data API.

Blank pages aren't so cool, at least the user should know that it was something they couldn't really help.

We'll need a squad home page which gives you the option to join that squad.