Problems we try to solve
- need a better foodsharing desktop website (for full features of site)

    - able to do bug fixes and maintaince

- create a mobile app to enable people to do important things that have time conditions

    - real time chat (ideally push notifications)

    - pickup handling (seeing what you need to do, reminder, see who you are doing it with and their phone numbers etc)


Currently there is:
    - desktop website

     - hard to understand and maintain and develop further

     - does not work  on mobile very well

    - server-side html rendering mixed with jQuery stuff

    - api is mix of data/html/javascript - not very logical for building anything new on top of



How to serve up requests to new vs old site:
    - do it in nginx via path prefix (e.g. /api/v2...)

        - what about /?

    - do it inside new symfony app, and make it pass off selected routes to existing code

    - pro: because existing code would now be running in symfony context, can make use of parts of it

    - con: symfony has too much overhead? (need to find out a bit? maybe?)


What should we do with existing code, do we need to do anything with it?

    - could leave it as it is and try and migrate step by step into new structure

    - could try and modernize existing code step by step (^ isn't that the same thing?)


Should we do an SPA or still server-rendered HTML?

    - seems perfect use case for an SPA (very dynamic, focus on logged in content, not SEO-able)

    - could choose 1 page at a time to implement as an SPA app, and go from there

    - ... then either generate a js file for each page

    (complex js build setup - webpack hell probably..., but might end up with better file sizes)

    - ... or have one BIG js file that can attach itself to each page as needed

    (simpler js build setup, js file would be cached, slower initial load)

    - how would it work?

    - server would have a list of pages that are SPA

    - for those it would serve up standard spa html file

    - the client app would decide how to initialize itself based on current path (and hopefully handle links that are also spa pages properly)

    - server-rendered html approach for migration would allow incremental changes from current deployed site

    - change just one component on a server rendered page, can attach to the page when <special-element> used


How to handle style/ui component look and feel

    - if using a fancy modern vue/etc framework (e.g. quasar) then it would look very different to existing ui

    - makes it harder to do incremental changes

    -BUT maybe it's possible to just slightly style/theme a ui framework so it looks compatible enough...

    - OR could write components that produce identical html to existing site, and so use same style

    - then don't need to be a ui/ux designer to do this work

    - BUT it might be nice to use it as a chance to improve the site


How to consider the mobile application/website and the existing site

    - is it a good approach to build a new/fresh website (that can be run in cordova, mobile web, and desktop) and incrementally add more and more features from the desktop website until the desktop website is no longer required?

    - alternatively just see it as a minimal thing focused on solving things that need to be done in in a time constrained way. it then works like a companion app to the desktop website (think facebook messenger vs the full website/app).

    - from there it might be possible to bring over parts of it into the existing desktop website

    - OR then decide it is possible to implement more-and-more of the desktop features, but not to decide up front what the plan would be

    - very limited developer time really...


How to actually roll it out regularly etc...

    - have another url with master (or close) deployed to e.g. next.foodsharing.de with new frontend/backend stuff all there.


Features for a mobile version (ordered by importance):
    - chat
    - list / notification of next pickup
    - store list
    - store details
    - store wall
    - pickups / list of people who pickup (contact details)
    - list of people in a store
    - sign out of a store
    - event handling (see/manage invites/manage wall)


    small orga aruff for warmup

        - move repo to github

    - create github organisation

    - developer page hosted by github? => foodsharing.github.io

    - nicks jeckyll blog is compatible fancy github feture

    - use the github wiki?


Changes in session/chat handling (to be done hopefully before deployment):
    - use sorted set to store user id -> session ids
    - loop over that set in nodejs server when there is something to send
    - optionally switch to pubsub instead of http request on the server side (as little overhead)
    - careful: Deployed nodejs server is a real strange version!

Changes that really need to be done for it to work:
    - fs_conversation has broken foreign keys to last_message being 0 instead of NULL (at least in dev, check in prod!)

    API:
        - getConversations: Recent conversations, ordered, participants (shortly), last message
        - getConversation: Recent N messages, no further info
        - getNextPickups: