Notes on Moodle Web App and Mobile App; Migrating old PHP sites to REST with Mobile App - ChatGPT

Last updated on 1 Sep. 2025

Sections in post

1. Moodle Mobile + Web App Tech. Stacks
2. Providing REST API in PHP
3. Migrating traditional PHP website (pure SSR, no API) to Modern Mobile + Web + REST API App
4. Expanding on API load/performance issues between SSR web app and API mobile app
5. React and React Native were new/not around yet when Moodle picked AngularJS for its mobile app
6. React vs Angular (2025)
7. Performance comparison between PHP backend and Node Express backend

Section Summaries

1. Moodle Mobile + Web App Tech. Stacks

The Moodle mobile app is built with Cordova. It’s a hybrid Angular/Ionic application that leverages the Cordova framework to render HTML/CSS/JS within a native mobile container. This enables the app to access native device features via plugins while still using web technologies for UI.  Moodle Developer Resources  Moodle Docs

FrameworkUI TechnologyNative Access MechanismResulting App Feel
Ionic + Cordova (Moodle App)HTML + CSS + JS inside WebViewCordova plugins for native featuresHybrid app, feels like a website in an app wrapper
React Native / FlutterReal native UI components (or Skia for Flutter)Native modules/APIs for device featuresTruly native UI and performance

Tech Insights on Moodle App

  • The core is built with Angular and Ionic, leveraging TypeScript.  Moodle Developer Resources
  • It uses Cordova to compile and access native features across platforms.  Moodle Developer Resources  Moodle Docs
  • MoodleHQ even maintains custom forks of Cordova plugins such as cordova-plugin-inappbrowser and cordova-plugin-ionic-webview, confirming its deep integration.  Npm  Git 
-------

Moodle has both PHP and Angular/Ionic in its ecosystem, but for different roles. Let’s clarify:

🔹 1. Moodle’s Core Web App (LMS platform)

  • Written in PHP (with some JS sprinkled in).
  • This is the classic Moodle web interface you access via a browser (teachers, admins, students).
  • Lives on a web server, serving HTML pages generated by PHP.
  • Still the main way most universities/schools use Moodle.

🔹 2. Moodle Mobile App (iOS/Android)

  • Built with Angular + Ionic (TypeScript).
  • Packaged with Cordova (so it runs inside a WebView).
  • Not a clone of the entire Moodle web UI → instead it uses Moodle Web Services (REST APIs) exposed by the PHP backend.
  • So the app talks to the PHP server (via JSON API calls) to fetch data (courses, assignments, messages).

🔹 3. How they fit together

  • PHP = the “backend + web frontend”.
  • Angular/Ionic = mobile client (in Cordova WebView).
  • Mobile app does not run PHP code itself → it consumes web services provided by the Moodle PHP server.

✅ So the reality

  • Moodle web interface → PHP (classic LMS).
  • Moodle mobile app → Angular/Ionic in Cordova (calls PHP backend APIs).
...
Moodle is fundamentally a PHP SSR app, but with a REST API layer grafted on top to support the mobile app and integrations.
...
Moodle didn’t use an external tool/framework like Symfony, Laravel, or Swagger. Instead:
  • They wrote their own minimal web service framework in PHP.
  • Admin UI in Moodle lets you enable/disable protocols, add tokens, and choose which functions are available.
  • Documentation is auto-generated from PHP comments using Moodle’s internal docs system.
So it’s a custom-built solution, not based on a 3rd-party API framework.
-------

2. Providing REST API in PHP

Plain PHP does not natively expose arbitrary functions as web services.

PHP has a built-in SOAP extension (SoapServer, SoapClient) which lets you create a SOAP server that maps WSDL operations to PHP functions.

PHP doesn’t have a native RestServer. But REST is just HTTP + JSON, so you can do it manually.

Modern PHP frameworks (Laravel, Symfony, Slim, Lumen) give you routing, controllers, and JSON serialization out-of-the-box.

Moodle’s framework is essentially a mini version of what Laravel or Symfony would give you, but built in 2010s style, hand-rolled, to fit Moodle’s architecture.
----------

3. Migrating traditional PHP website (pure SSR, no API) to Modern Mobile + Web + REST API App

  1. Start with an existing PHP website with UI and business logic tangled together and no REST API.
  2. Separate UI from business logic so that core functions are in library PHP files which are invoked by UI templates for HTML rendering.
  3. Add a REST/JSON API layer either by using micro-framework like Slim or Lumen giving clean routing, middleware, authentication, JSON out-of-the-box OR write your own dispatcher.
  4. Secure it by adding API tokens / OAuth2 / JWT for authentication. Don’t expose raw PHP functions without access control.
  5. Write the mobile frontend app in React Native and Expo. Use fetch or axios to call the new REST API endpoints. Render data natively (Lists, Views, Forms, etc.)
  6. Bonus: reuse for web too. The same REST APIs can also serve a modern React/Next.js frontend later, if the group wants to replace the old PHP SSR UI.
Thus step by step, you can migrate from a pure PHP site to an API-driven architecture supporting modern mobile and web apps.

The big pitfalls are:
  1. Tangled legacy code → hard to extract APIs.
  2. API load/performance issues: Old PHP apps often do DB queries directly in page scripts → fine for one user, but heavy API usage can overload the DB.
  3. Security & authentication.
  4. Inconsistent rules between UI and API.
  5. API versioning headaches: Once mobile apps are published, you can’t instantly update all clients. If API changes break old apps, users get errors. Solution is to version your APIs (/api/v1/courses, /api/v2/courses).
  6. Skill gap between PHP and mobile devs.

But if done carefully (like Moodle did), the payoff is huge → mobile apps + future-proof API architecture.

----------

4. Expanding on API load/performance issues between SSR web app and API mobile app

Key difference
  • SSR web app → fewer, heavier requests (HTML + CSS).
  • API mobile app → many more, smaller requests (JSON), but potentially orders of magnitude more frequent.
🔹 How real-world systems solve it
  • Use caching (Redis/Memcached, Moodle has MUC cache).
  • Use batching (send all data in one JSON response instead of 10 calls).
  • Use push notifications (instead of constant polling).
  • Use rate limiting (protects backend if clients misbehave).

✅ So yes, old PHP websites can also overload the DB under high load, but API-based mobile apps amplify the load pattern because they encourage more frequent, granular calls.

---------

5. React and React Native were new/not around yet when Moodle picked AngularJS for its mobile app

🔹 Timeline of frameworks
  • 2009–2010 → Cordova/PhoneGap launched.
  • 2010 → AngularJS (Angular 1.x) released by Google, quickly gained traction.
  • 2011–2012 → Moodle began work on Moodle Mobile app.
  • 2013 → Moodle Mobile 1.0 released (AngularJS + Cordova).
  • 2013 (May) → Facebook publicly released React (for the web).
  • 2015 (March) → Facebook released React Native (for mobile).

So by the time Moodle had their first working mobile app (2013):

  • React for web was brand new, not yet battle-tested.
  • React Native didn’t even exist.
🔹 Why AngularJS felt “safe”

At that time:

  • AngularJS was backed by Google.
  • It was already widely adopted in the web community.
  • It offered an MVC-like structure that PHP/JS developers could quickly learn.
  • It was a better fit than jQuery spaghetti code for building a full app.

So Moodle’s choice was sensible and mainstream in 2012–2013.

✅ Bottom line:
When Moodle chose AngularJS + Cordova, React had just been open-sourced (not widely adopted), and React Native didn’t exist yet. So React wasn’t even on the table.

----------

6. React vs Angular (2025)

AspectReact (2025)Angular (2025)
PopularityVastly more popular, especially in startupsNiche in enterprise and regulated sectors
ArchitectureLibrary — flexible, requires third-party toolsFull framework — built-in features, opinionated
Learning CurveGentle for JS beginnersSteep (TypeScript, RxJS, DI)
PerformanceHighly efficient with modern rendering systemsOptimized for scale (AOT, signals)
EcosystemHuge, varied, community-drivenCohesive, structured, Google-supported
Best Fit (use case)Dynamic UIs, SPAs, mobile-first appsLarge enterprise applications, enforced structure

Final Thoughts

  • React leads the web with unmatched flexibility, widespread use, and a vast ecosystem.
  • Angular continues to thrive, particularly in enterprise-grade applications that benefit from its structure and built-in tooling.
  • Both remain relevant in 2025, but React is the more commonly chosen framework for new, dynamic projects—while Angular shines when stability, structure, and long-term maintainability matter.
----------

7. Performance comparison between PHP backend and Node Express backend

  1. Startup overhead per request

    • PHP (Moodle): Higher → bootstrap on every call.
    • Node.js: Lower → app already initialized.

  2. Concurrency model

    • PHP: Each request handled by separate process/thread (depends on Apache/FPM). Scales OK, but higher memory cost.
    • Node.js: Single-threaded event loop with async IO → handles many requests with lower memory.

  3. Throughput

    • Benchmarks usually show Node.js can handle more requests/sec than raw PHP under load, especially for API-heavy apps.
    • BUT — for apps that are DB-bound (lots of SQL queries, joins, etc.), the database becomes the bottleneck, not PHP vs Node.

  4. Caching

    • Both can use Redis/Memcached to reduce DB load.
    • Node.js makes in-process caching easy, while PHP needs external caching since each request is fresh.
🔹 Why Moodle stayed with PHP backend
  • Moodle is not a “microservice” system → it’s a huge monolithic LMS.
  • Rewriting in Node.js would be massive (decade-long effort).
  • Most Moodle performance issues come from database queries and scaling architecture, not just PHP runtime.
  • With OPcache, Redis caching, HTTP caching, Moodle can scale to millions of users.
🔹 Practical takeaway
  • Yes, a Moodle REST API backend in PHP has more per-request overhead than a modern Node/Express backend.
  • But, in real-world LMS usage:
    • DB is the bottleneck.
    • Caching solves most of the PHP statelessness inefficiency.
    • Universities often run Moodle behind load balancers with horizontal scaling.

So Moodle’s PHP backend is “slower” in theory, but not a blocker in practice, given proper infra.

=========================================================
=========================================================

Details

Copy-paste of latter part of chat (it was a continuation of previous chat session) with ChatGPT (CG), titled, 'React Native for Windows; Web Dev Arch' on or around 30 Aug 2025, with slight editing, are given below covering topics mentioned in Section Summaries above.

Section 1. Moodle Mobile + Web App Tech. Stacks

Me: I believe Moodle's Android app uses Cordova. Am I right?
ChatGPT said:

You’re absolutely right!

Yes — the Moodle mobile app is indeed built with Cordova. It’s a hybrid Angular/Ionic application that leverages the Cordova framework to render HTML/CSS/JS within a native mobile container. This enables the app to access native device features via plugins while still using web technologies for UI.Moodle Developer Resources  Moodle Docs

Why this matters

FrameworkUI TechnologyNative Access MechanismResulting App Feel
Ionic + Cordova (Moodle App)HTML + CSS + JS inside WebViewCordova plugins for native featuresHybrid app, feels like a website in an app wrapper
React Native / FlutterReal native UI components (or Skia for Flutter)Native modules/APIs for device featuresTruly native UI and performance

Tech Insights on Moodle App

  • The core is built with Angular and Ionic, leveraging TypeScript.Moodle Developer Resources

  • It uses Cordova to compile and access native features across platforms.Moodle Developer Resources  Moodle Docs

  • MoodleHQ even maintains custom forks of Cordova plugins such as cordova-plugin-inappbrowser and cordova-plugin-ionic-webview, confirming its deep integration.Npm  Git 

Final Take

You're absolutely spot-on: Moodle’s Android (and iOS) mobile app uses a WebView via Cordova, not truly native controls. It’s essentially a web interface packaged as a mobile app.

Let me know if you'd like to explore how this compares in performance and developer experience to something like React Native or Flutter!

You said:
So Moodle's mobile app may not be comparable in performance to Native/near-Native (e.g. React Native) edu apps but Moodle's mobile app development work would be very limited as it is a sort of packaging of web app within Cordova. Am I right?
ChatGPT said:

Yes ✅ — that’s a very fair assessment. Let me break it down:

🔹 1. Performance difference

  • Cordova/Ionic (Moodle app)

    • Entire UI = WebView rendering (HTML/CSS/JS).

    • Performance is limited by the browser engine embedded in the app.

    • Animations, large data sets, complex UI → can feel sluggish compared to native.

    • “App feel” is often like a responsive website in a wrapper.

  • React Native / Flutter (near-native frameworks)

    • UI = real native controls (RN) or a high-performance graphics engine (Flutter’s Skia).

    • Much smoother animations, better integration with device APIs, more “native” feel.

    • Performance gap vs. fully native (C#/Java/Swift) is often negligible for most apps.

🔹 2. Development effort

  • Cordova/Ionic (Moodle’s case)

    • Much less dev work → they reuse the same Angular/Ionic codebase for web and mobile.

    • Cordova just packages it into Android/iOS apps and provides plugins for native APIs (camera, file system, notifications).

    • Development is mostly web development, with minimal mobile-specific coding.

  • React Native / Flutter

    • Requires more investment → you maintain a shared cross-platform codebase, but you still need platform-specific tweaks.

    • Bigger upfront effort, but pays off with better UX and long-term scalability.

🔹 3. So your statement is correct

  • ✅ Moodle’s mobile app won’t match the performance/UX of a native or near-native educational app (like a React Native or Flutter app).

  • ✅ But the dev cost is lower, since it’s basically their web app wrapped with Cordova.

  • ✅ This trade-off made sense for Moodle → it’s open-source, multi-platform, maintained by a global volunteer/dev community → easier to sustain with web tech than building full native apps.

👉 So Moodle chose reach & maintainability over native performance polish.

Do you want me to also give you an example of an edu app built with React Native (like Duolingo) so you can see the contrast with Moodle’s Cordova approach?

You said:
But I thought Moodle also used PHP. So does it have a PHP web interface and/or an Angular web interface?
ChatGPT said:

Great observation 👌 — Moodle indeed has both PHP and Angular/Ionic in its ecosystem, but for different roles. Let’s clarify:

🔹 1. Moodle’s Core Web App (LMS platform)

  • Written in PHP (with some JS sprinkled in).

  • This is the classic Moodle web interface you access via a browser (teachers, admins, students).

  • Lives on a web server, serving HTML pages generated by PHP.

  • Still the main way most universities/schools use Moodle.

🔹 2. Moodle Mobile App (iOS/Android)

  • Built with Angular + Ionic (TypeScript).

  • Packaged with Cordova (so it runs inside a WebView).

  • Not a clone of the entire Moodle web UI → instead it uses Moodle Web Services (REST APIs) exposed by the PHP backend.

  • So the app talks to the PHP server (via JSON API calls) to fetch data (courses, assignments, messages).

🔹 3. How they fit together

  • PHP = the “backend + web frontend”.

  • Angular/Ionic = mobile client (in Cordova WebView).

  • Mobile app does not run PHP code itself → it consumes web services provided by the Moodle PHP server.

✅ So the reality

  • Moodle web interface → PHP (classic LMS).

  • Moodle mobile app → Angular/Ionic in Cordova (calls PHP backend APIs).

That’s why Moodle feels a bit “old-school” on the web (PHP templating), but more “modern JS” on mobile (Angular/Ionic).

Would you like me to also show you how Moodle’s PHP side exposes APIs (e.g., through the mobile.php service layer) that the Ionic/Cordova app consumes? That might connect the dots more clearly.

You said:
Oh! So Moodle's PHP must be a pure SSR app like 2000s ASP.Net. If so, how exactly is that exposes as REST APIs?
ChatGPT said:

Excellent question 👌 — and you’re right:

  • Moodle’s main web interface (the one you see in a browser) is indeed classic PHP server-side rendering (SSR) — like 2000s ASP.NET or early PHP apps.

    • The PHP scripts generate full HTML pages (with CSS + JS) and send them to the browser.

    • That’s why Moodle’s browser interface feels like an “old-school” web app.

But… Moodle also has a web services layer built on top of PHP that exposes REST APIs. Here’s how it works:

🔹 1. Moodle as SSR app

Example: when you visit

https://moodle.example.com/course/view.php?id=123

  • PHP runs on the server.

  • It fetches the course data from MySQL/Postgres.

  • It generates a full HTML page (course page with assignments, sections, etc.).

  • Browser renders the HTML.

This is traditional SSR.

🔹 2. Moodle as API server

Moodle added a web services framework around 2012+ (to support the mobile app).

  • Admins can enable “web services” in Moodle settings.

  • When enabled, Moodle exposes endpoints like:

https://moodle.example.com/webservice/rest/server.php?wstoken=YOUR_TOKEN&wsfunction=core_course_get_courses&moodlewsrestformat=json

  • wstoken = authentication (API token for the logged-in user).

  • wsfunction = which PHP function to call (e.g., core_course_get_courses).

  • moodlewsrestformat=json → response in JSON (instead of XML).

Example JSON response:

[
  {
    "id": 123,
    "fullname": "Physics 101",
    "shortname": "PHYS101",
    "summary": "Introductory physics",
    "startdate": 1724895600
  }
]

🔹 3. How Moodle exposes REST APIs technically

  • Each API maps to an existing PHP function (e.g., core_course_get_courses() in Moodle’s PHP codebase).

  • Moodle’s web service layer acts as a router/dispatcher:

    • Validates the token.

    • Calls the PHP function.

    • Encodes the return value as JSON.

  • So it’s still PHP executing on the backend, just returning JSON instead of HTML.

🔹 4. Why this matters

  • Browser users → get PHP SSR HTML pages.

  • Mobile app (Ionic/Cordova) → calls PHP REST APIs, gets JSON, renders it in Angular UI inside WebView.

✅ So yes — Moodle is fundamentally a PHP SSR app, but with a REST API layer grafted on top to support the mobile app and integrations.

Would you like me to also compare Moodle’s model here to how modern apps (like Next.js + Node) tend to unify SSR + API endpoints under one framework, whereas Moodle had to bolt on APIs later? That contrast really shows how web dev has evolved.

You said:
Tell me more about Moodle's web services framework. What is it programmed in? Is there some tool they used to help do the web services framework?
ChatGPT said:

Great deep-dive question 👌 — Moodle’s web services framework is actually a home-grown layer built entirely in PHP, sitting on top of its core LMS code.

Let me break it down:

🔹 1. Tech stack

  • Language → PHP (same as the rest of Moodle core).

  • DB → Same backend (MySQL/Postgres/others).

  • Transport → Supports REST, SOAP, XML-RPC, and even AMF (Flash remoting, legacy).

  • Format → JSON, XML (depending on protocol).

  • Security → Token-based (each user or system gets a wstoken).

🔹 2. How it works

  • Moodle has a /webservice/ directory in its codebase.

  • When you enable web services (via admin settings), Moodle loads this framework.

  • You configure:

    • Which protocols are enabled (REST, SOAP, etc.).

    • Which functions (PHP functions in Moodle core) are exposed.

  • For each function, Moodle generates a wrapper that:

    1. Validates the token.

    2. Maps the API call (like core_course_get_courses) to the underlying PHP function.

    3. Serializes the PHP return value into JSON or XML.

So Moodle’s web services framework is essentially a dispatcher/router implemented in PHP.

🔹 3. Example flow

Request:

https://moodle.example.com/webservice/rest/server.php
  ?wstoken=abc123
  &wsfunction=core_user_get_users_by_field
  &field=username
  &values[0]=john
  &moodlewsrestformat=json

  1. Moodle receives this in /webservice/rest/server.php.

  2. Finds the core_user_get_users_by_field() function.

  3. Calls it in PHP.

  4. Takes its output (PHP array/object).

  5. Serializes it as JSON.

  6. Sends JSON back.

🔹 4. Tools used?

Moodle didn’t use an external tool/framework like Symfony, Laravel, or Swagger.
Instead:

  • They wrote their own minimal web service framework in PHP.

  • Admin UI in Moodle lets you enable/disable protocols, add tokens, and choose which functions are available.

  • Documentation is auto-generated from PHP comments using Moodle’s internal docs system.

So it’s a custom-built solution, not based on a 3rd-party API framework.
(Which makes sense — Moodle started in 2002, long before REST became the default standard!)

🔹 5. Why this approach

  • Needed backward compatibility with SOAP/XML-RPC since many institutions still use legacy systems.

  • Needed flexibility so admins could choose which API functions are exposed (important in universities with strict policies).

  • The Moodle team chose not to adopt a big external PHP framework → they stuck to their own core PHP architecture.

✅ In short: Moodle’s web services framework is custom PHP code inside Moodle core, acting as a dispatcher layer. It wasn’t generated by Swagger/OpenAPI/etc., it’s hand-rolled but configurable via Moodle’s admin panel.

Would you like me to pull up and show you the actual PHP code skeleton (like how /webservice/rest/server.php routes calls to PHP functions)? That might make it super concrete.

--------------

Section 2. Providing REST API in PHP

You said:
Hmm. Does PHP provide a way to expose any PHP function as a webservice accesible via SOAP and/or REST API?
ChatGPT said:

Excellent 👌 — this is the key nuance.

🔹 Raw PHP itself

  • No, plain PHP does not natively expose arbitrary functions as web services.

  • PHP is a general-purpose scripting language: you write scripts (.php files) that process HTTP requests and return HTML/JSON/XML.

  • If you want SOAP or REST APIs, you must either:

    • Write the routing + serialization logic yourself, or

    • Use a library/framework.

🔹 SOAP in PHP

PHP has a built-in SOAP extension (SoapServer, SoapClient).

  • Lets you create a SOAP server that maps WSDL operations to PHP functions.

  • Example:

function add($a, $b) {
  return $a + $b;
}

$server = new SoapServer(null, ['uri' => "http://localhost/soap"]);
$server->addFunction("add");
$server->handle();

That would expose add() as a SOAP function.

But:

  • Requires enabling the SOAP extension in PHP.

  • Very “2000s enterprise-y”, not modern REST JSON style.

🔹 REST in PHP

  • PHP doesn’t have a native RestServer.

  • But REST is just HTTP + JSON, so you can do it manually:

if ($_SERVER['REQUEST_METHOD'] === 'GET' && $_GET['action'] === 'sum') {
  $a = intval($_GET['a']);
  $b = intval($_GET['b']);
  echo json_encode(['result' => $a + $b]);
}

This returns JSON directly.
Modern PHP frameworks (Laravel, Symfony, Slim, Lumen) give you routing, controllers, and JSON serialization out-of-the-box.

🔹 Moodle’s case

  • Moodle did not rely on PHP’s SoapServer or an external REST framework.

  • Instead, Moodle wrote its own dispatcher layer in PHP (inside /webservice/).

  • That layer:

    • Parses incoming params.

    • Looks up the corresponding Moodle PHP function (e.g., core_user_get_users).

    • Executes it.

    • Serializes the result (JSON, XML, SOAP response).

So Moodle’s framework is essentially a mini version of what Laravel or Symfony would give you, but built in 2010s style, hand-rolled, to fit Moodle’s architecture.

✅ So to answer directly:

  • PHP doesn’t auto-expose functions as SOAP/REST web services.

  • For SOAP → PHP has SoapServer.

  • For REST → you build your own dispatcher (or use a framework).

  • Moodle → built its own dispatcher in PHP, not using external frameworks.

Do you want me to pull apart one of Moodle’s actual web service endpoints (like core_course_get_courses) and show step-by-step how the PHP framework wraps and exposes it? That would show you the mechanics in action.

You said:
Got how Moodle did it. Quite interesting! It breathes API life into a pure SSR PHP website though there would be a need to have separation of UI and functions in the PHP front-end. Am I right?
ChatGPT said:

💯 Exactly — you’ve got the essence!

Moodle’s web services layer really did breathe “API life” into what was originally a pure SSR PHP monolith.

🔹 Why separation is needed

In a classic PHP SSR app (2000s style):

  • UI logic (HTML templates) and business logic (functions to fetch users, courses, etc.) often got mixed together inside PHP scripts.

  • Example: view.php might both query the DB and print out <table> HTML directly.

That works fine for browser rendering — but if you suddenly want JSON APIs… 🛑 problem! You don’t want HTML mixed in with JSON.

🔹 Moodle’s solution

  • Moodle team split out “core functions” (e.g., core_course_get_courses, core_user_get_users).

  • These functions live in Moodle’s PHP libraries, separate from the UI templating code.

  • The SSR PHP pages (view.php, index.php) call those functions and render HTML.

  • The web services framework also calls the same functions — but instead of HTML, it serializes the return value to JSON/XML/SOAP.

So the same business logic gets reused in both:

  • Web UI (SSR HTML).

  • Mobile app/API clients (JSON).

🔹 Why this was clever

  • Moodle didn’t have to rewrite its core in Node.js or Laravel.

  • Universities could keep using the familiar PHP system.

  • Mobile apps & integrations could consume the same data as JSON APIs.

  • It future-proofed Moodle without discarding the old PHP SSR model.

✅ So you’re absolutely right:

  • Yes → It required separation of UI (templates) from business functions in PHP.

  • Yes → That separation is what made APIs possible.

  • Yes → This gave a second life to Moodle as a platform in the mobile/API era.

Would you like me to sketch a concrete example showing how the same PHP function is used in both a view.php SSR page and in a server.php webservice API? That would make the separation super clear.

---------------

Section 3. Migrating traditional PHP website (pure SSR, no API) to Modern Mobile + Web + REST API App

[In the 2000s, most PHP websites mixed HTML and database calls in server-side scripts, rendering complete pages for every request with little or no API support. This section explores how such legacy apps can be modernized into API-driven systems that power both mobile and web clients.]
You said:
Fascinating! Now if some group has some PHP website for which they need a mobile app, they could first do the UI and functions separation on the PHP server side code. Then they could bring in some of the tools you mentioned earlier that will enable exposing these PHP functions as REST APIs. Then if they next write a React Native front-end that works with these REST APIs, they will have Android and iOS mobile apps for their PHP website/web app. Am I on right track?
ChatGPT said:

👏 Spot on — you’ve pieced it together exactly right. Let’s map it out step by step in the way a dev team would approach it:

🔹 1. Start with an existing PHP website

  • Old-school SSR app (like early Moodle, WordPress plugins, or custom PHP site).

  • UI (HTML templates) and business logic (DB queries, processing) may be tangled together.

  • Works fine in browsers, but no clean JSON/REST interface.

🔹 2. Separate UI from business logic

  • Extract core functions (e.g., getUserCourses($userId)) into library PHP files.

  • Keep UI templates (view.php, etc.) only responsible for HTML rendering.

  • This way, the business logic can serve both HTML and JSON clients.

🔹 3. Add a REST API layer

Options:

  1. Roll your own dispatcher (like Moodle did).

    • A single api.php entry point.

    • Route incoming requests to the right PHP function.

    • Serialize the result into JSON.

    if ($_GET['action'] === 'courses') {
    $userId = $_GET['userid'];
    $data = getUserCourses($userId);
    echo json_encode($data);
}

  2. Use a micro-framework like Slim or Lumen.

    • Cleaner routing, middleware, authentication, JSON out-of-the-box.

    $app->get('/courses/{userid}', function ($req, $res, $args) {
    $data = getUserCourses($args['userid']);
    return $res->withJson($data);
});

  3. Expose via SOAP (PHP SoapServer), but in 2025 → REST/JSON is the standard.

🔹 4. Secure it

  • Add API tokens / OAuth2 / JWT for authentication.

  • Don’t expose raw PHP functions without access control.

🔹 5. Write the mobile frontend

  • Build an app in React Native (or Expo).

  • Use fetch or axios to call the new REST API endpoints.

  • Render data natively (Lists, Views, Forms, etc.).

Example in React Native:

const [courses, setCourses] = useState([]);

useEffect(() => {
  fetch("https://example.com/api/courses?userid=42&token=abc123")
    .then(res => res.json())
    .then(setCourses);
}, []);

Now your mobile app shows live data from your PHP backend 🎉

🔹 6. Bonus: reuse for web too

  • The same REST APIs can also serve a modern React/Next.js frontend later, if the group wants to replace the old PHP SSR UI.

  • So step by step, they can migrate from a pure PHP site to an API-driven architecture.

✅ So your summary is 100% correct:

  1. Separate UI and logic in PHP.

  2. Add an API layer (REST).

  3. Build a React Native app against those APIs.

  4. Boom → Android & iOS apps for the old PHP site.

Do you want me to also point out some pitfalls groups usually hit when they try this transition (like performance, security, and consistency between old UI and new API)? That would give you a realistic view of the effort.

You said:
Yes please
ChatGPT said:

Perfect 👍 — here are the main pitfalls groups run into when evolving an old PHP site into a mobile+API-based architecture:

🔹 1. UI/Logic Separation Is Messy

  • In old PHP apps, business logic is often tangled with HTML.
    Example:

    while ($row = $db->fetch()) {
   echo "<tr><td>{$row['name']}</td></tr>";
}

  • Pulling this out into a clean getUsers() function can require major refactoring.

  • Teams underestimate how time-consuming untangling PHP spaghetti is.

👉 Fix: Start with the most important features (e.g., “courses list”), refactor step by step. Don’t try to API-ify everything at once.

🔹 2. Performance Issues

  • Old PHP apps often do DB queries directly in page scripts → fine for one user, but heavy API usage can overload the DB.

  • Example: Mobile app calls /api/courses 50 times per minute across 1,000 students → DB melts.

👉 Fix:

  • Add caching (Redis, Memcached).

  • Batch queries (send all needed data in one API response).

  • Rate-limit APIs.

🔹 3. Authentication & Security

  • Exposing raw PHP functions is dangerous:

    • Without tokens, anyone could call /api/deleteUser?id=42.

    • Session cookies may not work well with mobile clients.

👉 Fix:

  • Use API tokens, JWT, or OAuth2.

  • Separate mobile app authentication from web session cookies.

  • Never expose DB IDs blindly — check permissions server-side.

🔹 4. Consistency Between Old UI and API

  • Old PHP UI might have business rules (e.g., “don’t show hidden courses”), but the new API may skip those checks.

  • Result: mobile app shows different data than website.

👉 Fix:

  • APIs should call the same business logic functions used by the PHP UI (like Moodle does).

  • Don’t duplicate rules in two places — centralize them in library functions.

🔹 5. Versioning & Backward Compatibility

  • Once mobile apps are published, you can’t instantly update all clients.

  • If API changes break old apps, users get errors.

👉 Fix:

  • Version your APIs (/api/v1/courses, /api/v2/courses).

  • Keep old versions alive until apps are updated.

🔹 6. Developer Skills Gap

  • PHP-only devs may not know React Native.

  • React devs may not know PHP.

  • Coordination can slow projects down.

👉 Fix:

  • Define a clear API contract (OpenAPI/Swagger docs).

  • Backend and frontend teams can then work in parallel.

✅ Summary

The big pitfalls are:

  1. Tangled legacy code → hard to extract APIs.

  2. API load/performance issues.

  3. Security & authentication.

  4. Inconsistent rules between UI and API.

  5. API versioning headaches.

  6. Skill gap between PHP and mobile devs.

But if done carefully (like Moodle did), the payoff is huge → mobile apps + future-proof API architecture.

👉 Would you like me to show you a minimal working example of turning an old-school PHP “course list” page into both:

  • an HTML SSR page (courses.php) and

  • a REST API endpoint (api.php returning JSON)?

That would make the separation + API layer very concrete.

---------------------

Section 4. Expanding on API load/performance issues between SSR web app and API mobile app

You said:
Old PHP apps often do DB queries directly in page scripts → fine for one user, but heavy API usage can overload the DB. Example: Mobile app calls /api/courses 50 times per minute across 1,000 students → DB melts. ------------------ But 1000 students accessing the old PHP website per minute could have similar performance issue too, isn't it?
ChatGPT said:

👏 Excellent catch — you’re right to compare the two. Let’s tease it apart carefully:

🔹 Old PHP website (SSR model)

  • Each student visiting /courses.php →

    • PHP runs.

    • Queries DB.

    • Builds HTML.

    • Sends it.

So if 1,000 students load the page in the same minute → you get ~1,000 DB queries.
👉 Yes, the DB can “melt” if queries are heavy or not cached.

But… in practice:

  • Students don’t usually refresh constantly.

  • HTML pages are “heavier” but accessed less frequently.

  • Web admins can enable page caching (e.g., Moodle has “Course cache” and “Theme cache”).

  • HTTP reverse proxies (Varnish, Nginx) can cache the rendered HTML for non-logged-in pages.

🔹 New API-based model

  • Mobile apps tend to poll more frequently.

  • Example:

    • Every time a student navigates in the app → new API call.

    • Some apps refresh every 30 seconds (“check for new messages, new grades, etc.”).

  • So while the website might hit /courses.php once per session, the mobile app might hit /api/courses dozens of times per session.

So same 1,000 students, but instead of 1,000 calls/minute, you can suddenly have 50,000 calls/minute.
👉 That’s why DB stress shows up much faster with APIs.

🔹 Key difference

  • SSR web app → fewer, heavier requests (HTML + CSS).

  • API mobile app → many more, smaller requests (JSON), but potentially orders of magnitude more frequent.

🔹 How real-world systems solve it

  • Use caching (Redis/Memcached, Moodle has MUC cache).

  • Use batching (send all data in one JSON response instead of 10 calls).

  • Use push notifications (instead of constant polling).

  • Use rate limiting (protects backend if clients misbehave).

✅ So yes, old PHP websites can also overload the DB under high load, but API-based mobile apps amplify the load pattern because they encourage more frequent, granular calls.

Would you like me to sketch an example of how Moodle (or a similar system) solves this with server-side caching of API results, so that repeated /api/courses calls don’t always hit the DB?

-----------------

Section 5. React and React Native were new/not around yet when Moodle picked AngularJS for its mobile app

You said:
why did Moodle go for Angular web app (which is not used as a web app) and then package that in Cordova to get a mobile app? Was it that they felt Angular web app programming is easier than going for a native mobile app? Or was it that Angular + Cordova gave them both Android and iOS apps like React native does but React native was not so mature then (or even around then)?
ChatGPT said:

Great question 👌 — you’ve zeroed in on a very interesting historical decision by Moodle. Let me unpack the why behind their choice of Angular + Cordova for the Moodle Mobile app.

🔹 Timeline & Context

  • Moodle core → written in PHP since 2002.

  • First Moodle Mobile app → around 2011–2013.

  • At that time:

    • React Native → didn’t exist yet (launched 2015).

    • Flutter → didn’t exist yet (launched ~2017).

    • Cordova/PhoneGap → very popular for cross-platform apps (2010s).

    • AngularJS (Angular 1.x) → widely used, especially for building rich JS SPAs.

So Moodle picked the mainstream cross-platform stack available at that time:
👉 AngularJS frontend + Cordova wrapper.

🔹 Why Angular + Cordova?

  1. Write Once, Run Anywhere

    • Moodle wanted one codebase for iOS + Android.

    • Cordova provided that, wrapping a web app in a WebView.

    • Angular made it easier to structure a large client-side app (compared to jQuery).

  2. Developer familiarity

    • Moodle already had lots of web developers (PHP + JS), but not native mobile devs (Java/Kotlin for Android, Obj-C/Swift for iOS).

    • Training web devs to use AngularJS + Cordova was much easier than hiring separate mobile teams.

  3. API-first approach

    • Moodle had just added its web services API framework (2010–2012).

    • AngularJS could consume those APIs directly and render data in the app.

    • Cordova made it possible to access device features (notifications, offline storage) via plugins.

  4. Cross-platform reach

    • With Cordova, Moodle instantly got:

      • iOS app

      • Android app

      • Potentially a web app too (though in practice, the Moodle Mobile app was positioned mainly for mobile).

🔹 Why not native apps?

  • Building two separate native apps (Java for Android + Obj-C/Swift for iOS) was:

    • Expensive.

    • Hard to maintain.

    • Out of alignment with Moodle’s open-source, community-driven model (contributors were mainly web devs, not native mobile devs).

So native was never really an option.

🔹 Why not React Native?

  • React Native simply didn’t exist yet when Moodle Mobile began.

  • By the time RN became stable (2016–2017), Moodle already had:

    • A working Angular+Cordova app.

    • A development team skilled in Angular.

    • Hundreds of institutions relying on it.

Switching would’ve required a full rewrite, so they stuck with Angular.

🔹 Downsides of Angular + Cordova (acknowledged later)

  • Performance: Running in WebView, not native UI, so slower compared to React Native or Flutter.

  • Look & feel: Feels “webby”, not 100% native.

  • Maintenance: AngularJS eventually became outdated, requiring migration to newer Angular.

But in 2012–2014, it was the most pragmatic and future-proof choice available.

✅ So your instincts are right:

  • They didn’t pick Angular because “Angular was better than native,” but because Angular + Cordova was the best way (at that time) to get a single codebase → both Android + iOS apps.

  • React Native wasn’t mature (or even around yet).

  • It was about developer skills, cost, and community alignment.

Would you like me to also compare how Moodle’s app would look today if they were starting fresh in 2025 (Angular+Cordova vs React Native vs Flutter vs PWA)? That could be fun.

You said:
Hmm. Interesting! BTW was React around then (when Moodle chose AngularJS)?
ChatGPT said:

Nice follow-up 👍 — the short answer is:

👉 No — React wasn’t around yet when Moodle picked AngularJS for its mobile app.

🔹 Timeline of frameworks

  • 2009–2010 → Cordova/PhoneGap launched.

  • 2010 → AngularJS (Angular 1.x) released by Google, quickly gained traction.

  • 2011–2012 → Moodle began work on Moodle Mobile app.

  • 2013 → Moodle Mobile 1.0 released (AngularJS + Cordova).

  • 2013 (May) → Facebook publicly released React (for the web).

  • 2015 (March) → Facebook released React Native (for mobile).

So by the time Moodle had their first working mobile app (2013):

  • React for web was brand new, not yet battle-tested.

  • React Native didn’t even exist.

🔹 Why AngularJS felt “safe”

At that time:

  • AngularJS was backed by Google.

  • It was already widely adopted in the web community.

  • It offered an MVC-like structure that PHP/JS developers could quickly learn.

  • It was a better fit than jQuery spaghetti code for building a full app.

So Moodle’s choice was sensible and mainstream in 2012–2013.

✅ Bottom line:
When Moodle chose AngularJS + Cordova, React had just been open-sourced (not widely adopted), and React Native didn’t exist yet. So React wasn’t even on the table.

Do you want me to sketch a little alternate history — like “If Moodle had started their mobile app in 2016 instead of 2012, what would they likely have chosen”?

-------------------

Section 6. React vs Angular (2025)

You said:
Fascinating! Angular is from Google. I did not know that. In a React project that I worked, the lead was familiar with Angular but new to React. ... How does Angular compare with React now in 2025?
ChatGPT said:

Here’s a refreshed comparison between React and Angular in 2025:

React vs Angular — 2025 Overview

1. Popularity & Market Demand

  • React continues to dominate—used by approximately 40–52% of developers, with 210K+ GitHub stars and over 15 million weekly npm downloads.

  • Angular lags behind albeit with respectable adoption (~11–22% of developers), 85K–95K stars, and 2.5–3.6 million weekly downloads.Kryptoninc  Taction Software

  • In search trends and job postings, React vastly outpaces Angular.Kryptoninc  Taction Software

  • React is especially favored in startups and dynamic web/mobile projects, while Angular is preferred in enterprise-grade systems, government, and legacy corporate platforms.Taction Software  CodeWebStack

2. Framework vs Library

  • Angular is a fully-fledged framework:

    • Built-in features like routing, dependency injection, form handling, and state management

    • TypeScript by default

    • Structured, opinionated architectureWikipedia  Medium

  • React is a library focusing on UI with JavaScript/JSX; you assemble the rest via third-party tools (React Router, Redux, etc.)ButterCMS  The Frontend Company

3. Learning Curve & Developer Experience

4. Performance & Architecture

  • Both frameworks are performant, but Angular’s features—like Ahead-of-Time (AOT) compilation and signals—offer optimizations for large-scale apps.WEQ Technologies  Wikipedia

  • React’s virtual DOM and recent advances like concurrent rendering and React 19’s enhancements (Server Components) deliver excellent dynamic UI performance.Wikipedia

5. Ecosystem & Support

  • React's ecosystem is massive and diverse—countless libraries, tooling, and community resources.

  • Angular provides a more contained ecosystem with cohesive built-in features and strong Google-backed support, often preferred for enterprise stability.The Frontend Company  ButterCMS  CodeWebStack

6. Real-world Sentiment & Outlook

From Reddit discussions and developer experiences:

“React is far bigger internationally, but Angular provides structure that lets developers jump into projects faster when well defined.”Reddit

Developers shared renewed enthusiasm: “Built a SaaS with Angular 19.1 — it was a dream. Standalone components and signals remove boilerplate.”Reddit

Summary Table

AspectReact (2025)Angular (2025)
PopularityVastly more popular, especially in startupsNiche in enterprise and regulated sectors
ArchitectureLibrary — flexible, requires third-party toolsFull framework — built-in features, opinionated
Learning CurveGentle for JS beginnersSteep (TypeScript, RxJS, DI)
PerformanceHighly efficient with modern rendering systemsOptimized for scale (AOT, signals)
EcosystemHuge, varied, community-drivenCohesive, structured, Google-supported
Best Fit (use case)Dynamic UIs, SPAs, mobile-first appsLarge enterprise applications, enforced structure

Final Thoughts

  • React leads the web with unmatched flexibility, widespread use, and a vast ecosystem.

  • Angular continues to thrive, particularly in enterprise-grade applications that benefit from its structure and built-in tooling.

  • Both remain relevant in 2025, but React is the more commonly chosen framework for new, dynamic projects—while Angular shines when stability, structure, and long-term maintainability matter.

Would you like me to create a little visual diagram or roadmap showing how developers typically decide between React and Angular based on project type or team expertise?

----------------

Section 7. Performance comparison between PHP backend and Node Express backend

You said:
Would Moodle PHP server acting as REST API backend be having performance issues as compared to later technology Node Express server?
ChatGPT said:

Excellent question 👍 — this gets to the heart of why people sometimes worry about PHP backends vs Node.js backends. Let’s break it down in the Moodle (PHP) vs Node/Express (JS) context.

🔹 How PHP (Moodle) REST backend works

  • Moodle = classic Apache + PHP + MySQL/Postgres stack.

  • Each API request (e.g., /webservice/rest/server.php?wsfunction=core_course_get_courses) →

    1. Apache spawns a PHP worker.

    2. PHP initializes Moodle bootstrap code (quite heavy).

    3. Executes the requested function (DB queries, business logic).

    4. Serializes output as JSON.

    5. Ends process.

👉 Every request is stateless. Each call re-loads Moodle core libraries and re-connects to DB.

🔹 How Node/Express REST backend works

  • Node.js uses a long-running event loop.

  • When server starts:

    • Express app initializes once.

    • Routes and middleware stay in memory.

  • Each incoming request is handled by the event loop → non-blocking IO → same Node process continues running.

👉 Much less overhead per request, and reusing in-memory objects/cache is easy.

🔹 Performance comparison

  1. Startup overhead per request

    • PHP (Moodle): Higher → bootstrap on every call.

    • Node.js: Lower → app already initialized.

  2. Concurrency model

    • PHP: Each request handled by separate process/thread (depends on Apache/FPM). Scales OK, but higher memory cost.

    • Node.js: Single-threaded event loop with async IO → handles many requests with lower memory.

  3. Throughput

    • Benchmarks usually show Node.js can handle more requests/sec than raw PHP under load, especially for API-heavy apps.

    • BUT — for apps that are DB-bound (lots of SQL queries, joins, etc.), the database becomes the bottleneck, not PHP vs Node.

  4. Caching

    • Both can use Redis/Memcached to reduce DB load.

    • Node.js makes in-process caching easy, while PHP needs external caching since each request is fresh.

🔹 Why Moodle stayed with PHP backend

  • Moodle is not a “microservice” system → it’s a huge monolithic LMS.

  • Rewriting in Node.js would be massive (decade-long effort).

  • Most Moodle performance issues come from database queries and scaling architecture, not just PHP runtime.

  • With OPcache, Redis caching, HTTP caching, Moodle can scale to millions of users.

🔹 Practical takeaway

  • Yes, a Moodle REST API backend in PHP has more per-request overhead than a modern Node/Express backend.

  • But, in real-world LMS usage:

    • DB is the bottleneck.

    • Caching solves most of the PHP statelessness inefficiency.

    • Universities often run Moodle behind load balancers with horizontal scaling.

So Moodle’s PHP backend is “slower” in theory, but not a blocker in practice, given proper infra.

✅ Answer in short:

  • Moodle’s PHP REST backend does have more overhead per request than Node/Express.

  • But for real-world workloads, DB and caching dominate performance — so with tuning, Moodle scales fine.

  • Node.js would win on raw efficiency, but not enough to justify rewriting Moodle.

Would you like me to show you a concrete performance comparison — e.g., same API (/courses) implemented in PHP vs Node.js, highlighting where the bottlenecks shift?

You said:
Great chat. Thanks.
ChatGPT said:

You’re most welcome 🙏 — I really enjoyed this deep dive with you too! You asked very thoughtful questions, spanning old-school PHP, React/Next.js, Expo, WebView, Moodle, Angular, Node.js — it was like walking through the evolution of web and app dev across two decades 🚀.

Glad I could help clarify things and also sync up where newer stuff (like Expo’s 'use dom') wasn’t in my training memory.

Would you like me to keep a short summary timeline of your learnings from this chat (like a reference note you can look back on later), or do you prefer to just move on to the next exploration when it comes?

You said:
summary timeline would be good
ChatGPT said:

Perfect 👍 — here’s a summary timeline of the key concepts we explored in this chat, arranged roughly in historical/tech-evolution order.

🧭 Summary Timeline of Our Chat

1990s–2000s

  • Windows apps (VC++, VB, C#, .NET) → fully native, compiled, directly using Win32 APIs.

  • Early web (ASP.NET, PHP) → pure SSR (server-side rendering). Each request → server runs code, queries DB, outputs full HTML page → browser renders once.

  • Minimal JS (form validation, small effects). No SPAs.

2010s

  • PHP SSR → APIs: Frameworks like Moodle extended PHP with web services → REST/SOAP APIs on top of PHP functions, making mobile/web clients possible.

  • Cordova/PhoneGap (2010+) → wrap web app in WebView, package as mobile app. Cross-platform but “webby” performance.

  • AngularJS (2010) → Google’s SPA framework. Structured, MVC-like, better than jQuery spaghetti.

  • Moodle Mobile (2013) → AngularJS + Cordova, since React wasn’t stable and RN didn’t exist yet.

  • React (2013) → Facebook open-sourced for web.

  • React Native (2015) → brought near-native performance for iOS/Android with one JS codebase.

2020s

  • SPA vs SSR:

    • Pure React SPA → SEO issues (Googlebot may miss content if JS too slow).

    • Next.js → hybrid model: SSG, SSR, prefetch, streaming → fast first paint + good SEO.

    • Hydration = React runtime attaches interactivity to pre-rendered HTML.

  • React-snap (for CRA) → prerender HTML for SEO, but limited compared to Next.js.

  • Expo & React Native Web → lets you run RN code in browser, but weaker SEO/perf than Next.js.

  • WebView in RN/Expo → OS-provided component to render arbitrary HTML/CSS/JS inside native apps. Expo’s 'use dom' directive = auto-WebView injection for rich HTML rendering.

  • React Native for Windows → true native Windows app option (not Chromium-based).

2025 (now)

  • React vs Angular:

    • React dominates popularity, flexibility, and ecosystem.

    • Angular remains strong in enterprise, structured, Google-backed.

  • Backend performance:

    • Moodle PHP APIs = heavier per-request overhead than Node/Express.

    • Node.js event loop model more efficient.

    • But DB + caching dominate real performance → Moodle scales fine.

  • Cross-platform strategy today:

    • Large apps often use React Native for mobile + Next.js for web.

    • Cordova still exists but mostly legacy.

    • PWAs fill lightweight needs.

✅ Big Picture:

  • We’ve gone from server-heavy SSR (2000s) → client-heavy SPAs (2010s) → hybrid SSR/CSR (Next.js, 2020s).

  • For mobile, we’ve gone from wrapping web (Cordova) → true cross-platform native (React Native, Flutter).

  • Moodle’s path mirrors this history: PHP SSR → APIs → Angular+Cordova app → still evolving today.

Comments

Post a Comment