Migrate from Phoenix to Django

[samhstn]

Overall high level plan:

• Consider what rearchitechuring some of the ways we are storing our data in wagtail Rearchitechuring some of the ways we are storing our data #486
• Copy data to new wagtail instance Copying data #487
• Transfer over templates
• Set up non static routes in python
  • Set up google sheets logic in python
  • Set up search logic in python (consider elastic search)
  • Storing likes data in our database
  • Storing all data sent to spreadsheet with python
• Write python tests
• Relocate all js and css files
• Resetup deployment and ci
  (we will add to this list as tasks come up)

[samhstn]

The above will be implemented as a pull request into this repo to retain all of the previous issues and work that has been added to this repo

[samhstn]

Moved to here: mindwaveventures/good-thinking#50

[nelsonic]

@Shouston3 we still need to capture the reason why we are migrating to only using Wagtail/Django/Python instead of Phoenix/Elixir/Erlang.
we need to have a clear decision from the product owner for this work before starting it
otherwise it looks like we are just "making up work" to keep "busy".

[reddog]

@nelsonic Wasn't this fully covered during the call on Thursday? There were a number of relevant comments including your recommendation that based on currently understood project spec (and foreseeable project spec), the Phoenix layer wouldn't add any value to the project and would detract from it (net effect).

[nelsonic]

@reddog we prefer to have decisions precisely recorded rather than made verbally; much easier to send a link to a stakeholder with supporting detail for a decision than to attempt to re-count a telephone conversation. 👍

[reddog]

@nelsonic Thanks for adding that clarity. To help us get to closely recording the advice you gave, would you be able to summarise that and then the product owner could confirm or otherwise? Our listing down your comments would already be second hand.

[Cleop]

I think it would be best if @ellemindwave, as the product owner, first explains why the proposed change in technology was put forward by the MV team. Then @nelsonic can fill in any gaps with his technical perspective as he did when we discussed the proposal on the call.

[reddog]

@Cleop From my recollection of the group meeting, I don't think that the MV team did propose the change in technology. A query was raised to understand better why the current technology architecture is in place and if that is the best way to continue. @nelsonic then replied from a technical architecture perspective - I think that's what we're waiting for a summary of.

[nelsonic]

@reddog there appears to be a misunderstanding / misinterpretation somewhere ... 😕

My "advice" is to listen to the Product Owner who rightly pointed out
that serving CMS pages through Phoenix adds an unnecessary step
to content publishing/updating which is using developer time in-effectively.

I agreed with @sarahwelton that we don't want to have a "bespoke" CMS solution
that ends up requiring a "specialised" team of developers to maintain/update/extend it.

The last thing we (@dwyl) want is our clients/projects being dependent on us,
we want to make the code as accessible/beginner-friendly as possible (so that any team of developers can maintain/extend it) while ensuring that it is robust and reliable.

When I proposed the initial architecture, please see:
https:/LDMW/app/tree/e0c6d43d306071e82afdcec0682d07e49b29e5c6#project-overview
notice how my original diagram shows the content being served from Wagtail (through CloudFlare for speed) ?
The idea was to build the "peer-to-peer" elements of user interaction in Phoenix,
not to serve the CMS content through Phoenix ...

The requirement was for "peer-to-peer" user interaction, i.e. users (suffering with sleep-related mental health issues) would be able to interact with and help each other with some moderation but with the aim of helping each other find ways to overcome their sleep issues.

Our idea was to have "Chat" functionality in the LDMW Web app which would allow users to communicate in real-time. However this was not meant to be built during the "Alpha" phase, rather it was to be re-visited in "Beta".
Phoenix is brilliant for peer-to-peer. It uses the Erlang VM which is what WhatsApp, WeChat and Facebook Messenger all use for low-latency, high reliability chat.

In light of the change in requirements (away from having a "peer-to-peer" application) -
which Kumar confirmed on the call - I agreed with Sarah that Phoenix is not required for running a CMS. The conclusion from the call is that LDMW is going to be a "service" which then directs users to other services, e.g: https://www.bigwhitewall.com

My exact words were: "It breaks my heart, but if we only need a CMS then we should consider removing Phoenix". (i.e. if we don't want peer-to-peer anymore then we probably don't need Phoenix)

I followed up with a question: What will differentiate LDMW from other Content-based Websites?

Why &/or How would someone visit LDMW's website in the first place?
is the content going to be better (more relevant to the target audience)
than any of the existing content on the web? e.g:

• Sleep Foundation https://sleepfoundation.org/insomnia/content/what-causes-insomnia
• WebMD: http://www.webmd.com/sleep-disorders/guide/insomnia-symptoms-and-causes
• Help Guide: https://www.helpguide.org/articles/sleep/insomnia-causes-and-cures.htm

What is the USP that will give people a reason to visit LDMW over another website/service?
(I thought "peer-to-peer" was the USP...)

If we use an existing CMS and simply add content, how long will it take to have enough original content to start ranking for the specific keywords in order to get organic traffic to the site?

To be clear, I'm not against removing Phoenix (especially if it's causing a "bottleneck" in content creation/publishing; that was never the intention)
I just want it to be recorded that it's not my decision to remove Phoenix;
I still think that the original idea of having "peer-to-peer" mental health support is a "great feature" and for that Phoenix is perfect! (nobody builds chat in Python/Django, it would be like digging a swimming pool with a teaspoon...)
I merely provided a "high-level estimate" for how long it would take to remove Phoenix from the current LDMW setup, and asked for the decision to be recorded in an issue.

[nelsonic]

@reddog there appears to be a misunderstanding / misinterpretation somewhere ... 😕

My "advice" is to listen to the Product Owner who rightly pointed out
that serving CMS pages through Phoenix adds an unnecessary step
to content publishing/updating which is using developer time in-effectively.

I agreed with @sarahwelton that we don't want to have a "bespoke" CMS solution (with Phoenix "in front" of Wagtail) that ends up requiring a "specialised" team of developers
to maintain/update/extend it.
The last thing we (@dwyl) want is our clients/projects being dependent on us,
that's why we document (and test) our work as much as possible and make the code accessible/beginner-friendly so that any team of developers can maintain/extend it.

When I proposed the initial architecture, please see:
https:/LDMW/app/tree/e0c6d43d306071e82afdcec0682d07e49b29e5c6#project-overview
notice how my original diagram shows the content being served from Wagtail (through CloudFlare for speed) ?
The idea was to build the "peer-to-peer" elements of user interaction in Phoenix,
not to serve the CMS content through Phoenix ...

The requirement was for "peer-to-peer" user interaction, i.e. users (suffering with sleep-related mental health issues) would be able to interact with and help each other (with some supervision/moderation) with the aim of helping each other find ways to overcome their sleep issues. User-Generated Content is way more scalable (and thus successful) than single-source content.

Our idea was to have "Chat" functionality in the LDMW Web app which would allow users to communicate in real-time. However this was not meant to be built during the "Alpha" phase, rather it was to be re-visited in "Beta".
Phoenix is brilliant for peer-to-peer. It uses the Erlang VM which is what WhatsApp, WeChat and Facebook Messenger all use for low-latency, high reliability chat.

In light of the change in requirements (away from having a "peer-to-peer" application) -
which Kumar confirmed on the call - I agreed with Sarah that Phoenix is not required for running a CMS. The conclusion from the call is that LDMW is going to be a "service" which then directs users to other services, e.g: https://www.bigwhitewall.com

My exact words were: "It breaks my heart, but if we only need a CMS then we should consider removing Phoenix". (i.e. if we don't want peer-to-peer anymore then we probably don't need Phoenix)

I followed up with a question: What will differentiate LDMW from other Content-based Websites?

Why &/or How would someone visit LDMW's website in the first place?
is the content going to be better (more relevant to the target audience)
than any of the existing content on the web? e.g:

• Sleep Foundation https://sleepfoundation.org/insomnia/content/what-causes-insomnia
• WebMD: http://www.webmd.com/sleep-disorders/guide/insomnia-symptoms-and-causes
• Help Guide: https://www.helpguide.org/articles/sleep/insomnia-causes-and-cures.htm

What is the USP that will give people a reason to visit LDMW over another website/service?
(I thought "peer-to-peer" was the USP...)

If we use an existing CMS and simply add content, how long will it take to have enough original content to start ranking for the specific keywords in order to get organic traffic to the site?

To be clear, I'm not against removing Phoenix (especially if it's causing a "bottleneck" in content creation/publishing; that was never the intention)
I just want it to be recorded that it's not my decision to remove Phoenix;
I still think that the original idea of having "peer-to-peer" mental health support is a "great feature" and for that Phoenix is perfect! (nobody builds chat in Python/Django, it would be like digging a swimming pool with a teaspoon...)
I merely provided a "high-level estimate" for how long it would take to remove Phoenix from the current LDMW setup, and asked for the decision to be recorded in an issue.
If the decision is to move away from "peer-to-peer" (made by the NHS stakeholders)
then we probably don't need to have Phoenix.

[reddog]

@nelsonic Misunderstanding or not (I'll try harder on that front), thanks very much for your replies - I'm certain I wouldn't have captured your input quite as precisely as that.

[samhstn]

We will from now on be working from issues on the cms repository: https:/LDMW/cms

Closing this issue in favour of mindwaveventures/good-thinking#50 to avoid duplicate issues