Implement solution for standalone ooth, api, next.js

[nickredmark]

The current next.js solution uses ooth, api and next.js server all in one. This means that only one cookie-session is needed. But if ooth and api are separate, 3 cookie-sessions are needed, + the server needs to be able to communicate with ooth and api (on the server side probably JWTs are better). Both ooth and the next.js implementation need to be extended to support that.

[chase-moskal]

of course, it would be ideal if an ooth standalone was dockerized, obviously related to pr #26

[nickredmark]

Hey @chase-moskal I think the most complex part of this (and the main reason why I haven't implemented this) is configuration. How do you configure your own version of ooth with your own plugins with their own configs, but pack it in a standardized docker image? I don't really know a good strategy to do this.

[chase-moskal]

@nmaro — i think it's a really interesting topic.. bear with me as i'm not highly experienced with docker but i think i grasp the principal — here's some of my thinking about it

• i believe we could create an ooth-standalone base docker image

• devs could then make their own my-ooth-app docker image, which extends the ooth-standalone base image

• my-ooth-app can then copy in various configurations and plugins

  COPY ooth-config.json /ooth/           # copy in project ooth config
  COPY ooth-plugins/ /ooth/ooth-plugins/ # copy in project ooth plugins
  CMD ["ooth-standalone"]                # start running the ooth app

• i'm imagining that there'd be a standard ooth-standalone docker-compose file which lays out the other containers which are networked together with the ooth-standalone container, such as a mongodb container for the database, etc

  • i'm guessing the dev would copy this docker-compose file and modify it, to use my-ooth-app as the docker image in place of ooth-standalone — then they are free to replace other images like the one for mongodb or add other ones that work with their plugins, etc

for those who are not using docker

• ooth-standalone could also be distributed as an npm package which acts as a cli tool, allowing the user to pass a config file and plugins directory
  • ooth-standalone --config="ooth-config.json" --plugins="ooth-plugins/"

[chase-moskal]

reading up on #26 some more, i'm seeing that the conversation about mounting the config directory is probably a more proper way to bring configuration into the ooth-standalone image — i think users will be able to simply mount the config directory, which can include plugins

it's kind of looking like #26 is great, and does most of what we're talking about already

[nickredmark]

Hey @chase-moskal I finally pushed dockerized examples:

https://github.com/nmaro/ooth/tree/master/examples/standalone https://github.com/nmaro/ooth/tree/master/examples/integrated

For now there are no published standard images (the builds are all local), but it's a start. To a certain degree it could be argued that a standard ooth image is not needed because it's basically just about importing the library and configuring it. If you have ideas for where to go from there create a new issue, since this is about next.js.