[Daviey]

Took a quick look at the code, and it looks great!

  - Nice to see that you've split the frontend and API/Backend.
  - Backend is written in Python using fastapi.
  - Frontend is Typescript.
  - State is stored in MongoDB
  - Good documentation to bring up local env, with docker instructions (would be nice if the frontend code was easy to put in a docker image as well).

[jasfi]

If the frontend is in Typescript, why not write the backend in Typescript too? Less context switching when developing.

I also don't get why anyone would use MongoDB instead of PostgreSQL, but I can understand that its personal preference.

That said, Moodle could do with some competition.

[sweave]

We love Python for multiple reasons but one of the reasons we chose to stick with the language is fastapi & its ecosystem, it's really a joy to work with.

When I started the project I chose MongoDB for simplicity but a PostgreSQL rewrite is on the roadmap ;)

[digi59404]

Are you planning on moving to Postgres from Mongo because you and the team have experienced pain with Mongo? Or is it because of Postgres’s popularity?

I’m not judging or anything; I’m just curious the decision making process for the switchover.

[jasfi]

OK, I was just wondering.

It sounds like you're not using an ORM if a rewrite is required?

[kdmccormick]

I work on a certain other open source LMS that stores some of its data in Mongo but has been gradually moving it all into a relational db.

It is true that the (home-baked) ORM we use on top of Mongo provides an abstraction layer which makes parts of the migration easier, but truly finishing the migration has and will feel like a long, gradual rewrite.

That's because Mongo and its "no-SQL" patterns permeated our original architecture. JSON everywhere, layers of caches to handle the inefficiency of complex Mongo queries, stringly-typed fail-quietly semantics, all that sort of fast-and-loose stuff. Truly moving to relational data (Django models, in our case) means replacing all those old patterns with, you know, thoughtfully designed data models and efficient SQL queries. Otherwise, the LMS would just be a Mongo app awkwardly grafted onto a SQL database.

[sweave]

Yes we'll use an ORM in the future so users can use their preferred database (sqlite for example), SQL Model by tiangolo & SQL Alchemy are great candidates!

[xenophonf]

I adopted SQLAlchemy ORM, Marshmallow-SQLAlchemy, and Alembic for a personal project and couldn't be happier with the results:

https://github.com/irtnog/lethbridge

[aerhardt]

I code my front-ends in TypeScript and I like JS/TS but I’d rather code my backends in just about anything else than the wild west that is JS/TS in the server. It’s 2023 and there is no equivalent of Rails, Django or .Net in the JS world. Even setting up a thin Express server to run with TypeScript can take a lot of fiddling with tooling. Bun is trying to solve this but it’s just come out… I've never used FastAPI but I’m pretty sure I could make it work in an hour. I’d rather take the context switching to about any language in the server than having to deal with JS tooling there… Besides, “your scripts/ML models/high-performance code” runs in a non-TypeScript language, why not run that everywhere?

[jasfi]

What about Next.js? There are others too.

Prisma for the ORM, although again there are others to choose from.

[iterateoften]

I use nextjs and it is not comparable to Django’s vast ecosystem for making large scale SaaS backends.

[sweave]

Thanks a lot Daviey! We're working on improving the dev experience to make it even better