Preparing the new interface for edgeryders

[matthias]

@hugi

Based on how I understand the scope I think it would be important that the front end site can:

• Post content to Discourse through interfacing with a custom API.
• […]

And the custom API and backend, as I understand it, should:

• Post content written on the minisite to Discourse, probably to as a bot account to a new thread in a hidden workspace.
• […]

My five cents is that a modern JavaScript framework like Vue.js fits hand in glove to do the front end and that a Ruby or Python server would be well suited for the back end.

Ok, with that as a starting point, here’s my proposal for a software architecture that I think we can both live with … I even start to like it.

1. The minisite will be a single-page application made with a JavaScript framework of @hugi’s choice, and hosted as a compact, static website on the Edgeryders server.

   Deployment can be done via git, as done on surge.sh. It is done like that on the NGI Forward platform as well, just that we pull automatically from the Github master branch.

2. The inisite collects input from the user and talks directly to Discourse by API.

3. The Discourse API includes some custom API endpoints where necessary, in the same way how we already extended the Discourse API. The same Discourse API key is used to access both the standard Discourse API and our extensions. Extending the API is done with Ruby, directly as part of the Discourse codebase.

4. Our extensions to the Discourse API are packaged and distributed as a Ruby gem. If possible it would rather be a Discourse plugin, but I think extending the API is beyond what plugins are allowed to do in Discourse.

5. The extended Discourse API can also include endpoints with cached responses, if there is a need for that.

That kind architecture means doing it the same way how Discourse itself is made, providing a second frontend for the same Discourse API backend. In that way, that’s quite elegant.

Advantages of adding custom API endpoints as extensions to the Discourse API itself:

• We avoid duplicating parts of the already existing official Discourse API, but instead use that wherever possible.

• We avoid one or two layers of APIs. Every additional layer of API is complexity, and complexity must be avoided at all costs unless it’s better to have it

• We build on the work of an extended Discourse API that we already started, rather than starting another one from scratch.

• The Ruby code implementing the API runs in the Discourse environment, so it can access all Discourse classes and also the database. For future scenarios, database access (via Ruby Active Record of course) can speed up queries for data analysis and visualization, for example, avoiding one use case for cached responses of the standard Discourse API.

@hugi

If we were to write a backend API, we could also have it […] replace the current Participio.api that is serving Culture Squad and Internet of Humans, [and] we would have a pretty powerful beginning on our own Edgeryders API to extend Discourse to other front end applications.

That also applies when extending the Discourse API as outlined above. In fact we have a start of an Edgeryders API that extends Discourse already, so let’s proceed there.

Proposed work distribution:

• @natalia_skoczylas, @hugi and me do the software design together.
• @daniel and I do the Discourse API extensions.
• @hugi and team do the frontend implementation.