Sync with a backend

[pepf]

Allow all data to be saved to a backend, preferably in a "realtime" database so remote collaboration becomes possible.

Dependent on implementation of a proper state manager (Vuex for example). There exist plugins that can easily sync a state manager with an arbitrary backend solution.

Currently thinking of firebase as a possible solution.

[paul-hammant]

I'm interested. This would be my first Vue experience though - I'm more used to Angular1 (48 AngularJS blog entries since 2009 - http://paulhammant.com/tags.html#Angular1)

[pepf]

Cool!
I have been looking into firebase as a possible storage solution, since it will not introduce a specific server or backend technology as a dependency to this (frontend) repository. We could even make this optional by providing a toggle for saving data on the server .

Another reason I looked into firebase is because there's already a library providing the connection between vue and firebase, namely vuefire.

If you have anything else in mind i'd like to hear it.

The way the project is currenlty structured though (just a bunch of javascript and a html file containing all templates), it is probably better to work on #5 first. This would make it a lot easier to see the structure of the project and it's components.

spoiler alert: it's not that elaborate

[paul-hammant]

What if Retrospectify just did a GET/PUT of resources to the same origin, and maintained a list of retrospectives in index.json?

Retrospectify when it loaded into the browser, if it found an ./index.json it would disable the save_to_browser_local_storage functionality and save via PUT instead. Perhaps instead of my_retrospective_for_april_19_2018.json it just saves as 2018/04/19.json or 2018-04-19.json.

Of course PUT isn't directly supported in local_web_server - lwsjs/local-web-server#83 yet.

[pepf]

Yeah that sounds alright! It sounds like a good starting point to work on this and it doesn't break the current functionality :)

So basically, we can make some config.js or .env file which contains optional configuration for a backend type. If it's there, the frontend will just send requests according to to how this backend type would expect it. Additional types could then be added by anyone who'd like to save their data some place else (within reasonable limits that is..)

Do you have suggestions on what endpoints you'd like to start with?

[paul-hammant]

How about just three:

1. ./index.json list of retros in the current directory
2. ./ccyy-mm-dd.json (GET)
3. ./ccyy-mm-dd.json (PUT)

Imperfect, but a great start. Thoughts?

[pepf]

Yes let's keep it simple indeed!
For the GET and PUT requests, using the the date format as a unique identifier might not work for everyone. For example, in some companies multiple retrospectives are done on the same day because they work in different teams. If this is something you really want we can always make those endpoints on top of a 'uid' based system.

We could use JSON API as a standard (guideline) since it already offers a lot of integrations with popular languages.

Basic requests could look like so:
Get all retros

GET /retrospectives HTTP/1.1
Accept: application/vnd.api+json

Get one retro with id '1'

GET /retrospectives/1 HTTP/1.1
Accept: application/vnd.api+json

Update retro with id '1'

PATCH /retrospectives/1 HTTP/1.1
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json

{
  "data": {
    "type": "retrospectives",
    "id": "1",
    "attributes": {
       "title": "my retro",
       "created": 1524503833311,
       "notes": []
    }
  }
}

[paul-hammant]

Sure, if you'd prefer to go that way :)