Update README.md to cover database information.

[MatthewSzurkowski]

Hi @ross-spencer

This is a super small PR just wanted to make sure I've clarified the DB 🐘 correctly. If there is anything you'd like to go over, I figured a PR would be a perfect place to leave comments, feedback, etc on these changes (just want the DB to be super clear).

[ross-spencer]

Thanks @MatthewSzurkowski this is exactly the place, thanks for doing this!!

I like the more minimal approach to describing this (Rather than heaps of text!). The detail is all there and self-explanatory.

There are a couple of things in the scope of the PR that i feel are missing.

Essentially, the documentation describes how to use the database when it's already setup, but for a developer environment, we need to be able to set things up locally.

E.g. the current restrictions are having a user named arkly, and a database configured with the endpoint names all initialized to zero.

We can definitely add to the docs here in that regard. So perhaps, it's good to expand the README.md to describe some additional aspects of this?

I also wonder whether there's anything else in the feature we may need?

Some things that I am wondering about:

1. Configuration of database role and database name via .env file/.env setting.. This allows a developer, for example, to run things in psql as their default user without a new role.
   • e.g. ARKLY_ROLE=a_developer
   • e.g. ARKLY_DATABASE=developer_db
2. Expand the code to create a database column that doesn't exist, that way the code can extend the database without the user having to run an alter function. The app can extend itself as new endpoints are added. (I think right now, if we add an endpoint it then has to be added in the middleware, and then created manually in the db?)

I don't know if there is any other helpers that you are using to setup the db initially, but maybe there are other things can be included from your setup that I am not considering?

Before extending the feature, I think I can also see a way where most of this can be satisfied with updating the README.md and including a shell-script to configure the initial database settings. At least when first run. We may need a more complex way to migrate a database when columns are added. The user/roles can be described inline too I am sure even if they can't be dynamically changed.

What do you think? Are there any other ways of tackling the feature changes I described that you might want us to consider instead? Let me know. Also, we can talk more in discord/google or the next dev meeting.