Hello all,
So, I think we are completely ready to depart from MS Teams, and we probably won’t have to lookback.
There are three key components that have been in my mind.
- High Availabililty (HA) of server
- Mathjax compatibility everywhere we use
- LMS (Moodle) - ERP/Chat (ERPNext) - Website (Drupal) integration.
Let me lay it out one by one.
1.High Availability of our servers
I have already set up replica options for all our applications. For below services, at least two server machines are behind the proxy server.
- Contents: Drupal (going to be main), WordPress (backup)
- LMS: Moodle for GIAI LMS and SIAI LMS
- Frappe/ERPNext with Kanban dashboard, Drive, Chat, and student information
- MediaWiki
- Discourse (by docker replica)
- Big Blue Button (by docker replica - and BBB’s proxy configuration Cluster Proxy Configuration | BigBlueButton)
- Jitsi Meet: For in-house meetings, will be added to Frappe’s chat app
Was going to use docker everywhere, but we’ve got too many standing dev issues that come in #2 and #3, so I will stick to hard machine installations for most of them.
All systems are at least double installed w/ Nginx load balancer and/or rsync (and lsyncd) is running at the back to create instant replica. For DB, MariaDB is running with Galera cluster and PostgreSQL is with HA cluster. Images are now relying on Min.io, a S3 compatible local CDN option that handles replication and load balancing. I also use Cloudflare’s load balancer (and Algo routing) to redirect all traffic to the backup IP in case main server goes down. In short, as long as either primary or backup is running, we are still connected.
2. Mathjax compatiblity everywhere we use
As @davidoneill mentioned earlier, this was our initial motivation that we decide to pay days and months of time to ditch MS Teams. It is fully operational on most of platforms in #1 or soon be supported without much trouble. Open source solutions indeed open the door for us to customize (nearly) everything.
Except Jitsi Meet, we will have full Mathjax support by the end of this year.
3. LMS - ERP - Website integration
This has been a major hurdle together with #1, and I can only tell you that we have a plan that likely takes over a year path.
LMS to ERP integration is mostly done, at least ones in our item list. What’s next is how we can enforce students interactively use both Moodle and ERP’s chat. I suspect major actions will take place on Moodle, but without chat support, students likely will feel less integration to school. The ERP solution’s app feature can fill the gap. But as raised by @catherinemaguire, it may not be wise to rely too much on chat. This is a topic that might require years of experience, or YMMV. I was a bit concerned about grading integration, but both Moodle and ERPNext read 3rd party database’s components by hook. We can choose either one platform for studen’s course fee payments. I prefer ERPNext, but will take the team’s opinion on this. In the end, students have to come to the ERP website for their transcripts, academic records, as well as a host of other school related informations like regulations.
LMS to Drupal integration is straight forward. Going forward, all calendar items for education, be it for SIAI or MDSA (supported by GIAI or not), will be initially added to Moodle, and then pulled to Drupal websites by RSS. There actually are plugins for this. ( Calendar | Drupal.org) Course contents can also be pulled by RSS from Moodle. Essentially Moodle is a well-thought application that has done all heavy lifting already. Except highly custom requests, I don’t think we will strain much on this.
ERP - Website integration requires long way to go. For documents, I prefer to use ERPNext’s wiki docs where we can easily set who can read and write. It is not WYSIWYG editor, but Markdown format does have some benefits. I initially thought of Drupal’s dedicated content types for internal / external docs, but given the nature of our institution, there are certain advantages with Markdown format and dev doc style design. It is the team’s joint call.
Push notifications require a gateway, and I will test local installation for the next a few weeks.
For images, I am going to use following options.
- Sharepoint to Frappe Drive: Internal solution is way faster and more accessible, and this is somewhat Dropbox style that we can have students use for collaboration
- Min.io with Nginx based custom CNAME CDN
By hook, the ERP’s kanban dashboard and chat can be configured to Drupal node’s update. So, when a new article is created, the dashboard item can be turned to complete or go to next stage of editing, which can also be noti pushed to the chat window. I can also add OpenAI integration to chat so that writers can customize writing within it’s own chat, and when it is done, load the contents on Drupal’s node editing page by Drupal - OpenAI module. Later, when we are done with our own LLM, let’s replace OpenAI dependency.
Full editing integration probably needs some more intense dev work. At least I am not aware of plug and play solution for Gutenberg.js on any Python Frameworks…Once this is done, as @ethanmcgowan said, writers (and even us) don’t have to go to Drupal website anymore. It’s probably only the design team whenever we have major updates.
Pending items are Drupal headless, MediaWiki to Drupal and Moodle (and Disoourse) for keyword/taxonomy integation, and application pages for SIAI (and GIAI) through the ERP’s LMS solution, but these tasks probably require more dev works. We probably have to hire an experienced dev for each function, unless one of you are ready to spend months without sleep.
There still are minor hiccups here and there, but this is pretty much what has been and will have to be done from dev side. Once we are done migration from WordPress in mid Nov, we probably won’t have to check Google’s page speed again. Most solutions give us near 100 without much optimization.
I think it is safe to say that we are ready to move on and focus on operation and teaching.