Demo/Tech talk: Open edX MFEs

Was a great talk, @kshitij , thank you for presenting! I’m amazed at how far the MFE work has come, and how much is provided in the shared libraries now. As mentioned, we still have a ways to go to support pluggability and customizations, but what’s there is impressive.

Zoom recording: Demo/Tech Talk: Open edX MFEs

I agree. I think I got bogged down by some unnecessary details at points.

Thanks so much @kshitij , glad you found time to give this talk! It was a very helpful to see how things are currently working.

One comment/plug:

You put some code in useEffect and ran into a rate limit problem, then showed how to solve it… you may be interested in the useSWR hook which is a really nice way to avoid this problem - it automatically provides request throttling, deduplication, updating, error handling, caching, Suspense boundaries, SSR, etc. so you can call the same REST API in many places in the React tree but it will only make one call to the server for all of them - and when the data changes on the server it automatically refreshes all of your components, which feels like magic. I’ve been using it in Neolace and am a huge fan. There’s no need to use Redux or thunks or this sort of boilerplate with useSWR. And similar to what you showed, you can wrap it with your own custom hooks like useCourse, useXBlock, etc.

Having built one large app using Redux and also building one now using SWR with “plain” React, I personally would be happy to never use Redux again :p

Though of course if you do want/need to use Redux, as you mentioned, Providence is a nicer alternative to what I currently see in the frontend apps, and has some additional nice features for things like pagination and forms - though it doesn’t have some nice features of SWR like optimistic commits, automatic refresh, revalidation on focus, etc.

6 Likes

I hadn’t really looked into SWR, but there is also a similar system in Redux called RTK, and I’ve looked into Providence a bit as well. Even running through the demo in rehearsal it was a bit long, so I never went too far looking for improvements or additions.

I was trying to approach this more from the angle of understand the way the code is currently structured. Given that what’s widely used in MFEs right now is Redux, with useEffect, I felt I should at least introduce that approach, so the current codebase is easier to understand. I definitely hope we can improve things a bit and SWR looks like an interesting approach.

1 Like

Actually, though the Patchers, it does have optimistic commits. As for the other items, these wouldn’t be too hard to add-- and I have plans to resolve some of them already. Mostly, there are additional functionalities from Artconomy I’ve not yet to port forward to Providence since Listaflow didn’t (yet) need them. We may do so earlier if we have a project that makes it worth the effort (or Artconomy’s dependencies finally advance enough for me to port forward to Providence from the local state management it’s based on).

The solution I’ve been using on Artconomy’s side to handle this is clever, automated subscriptions to data via websockets. I’ve got a special Django app set up to ‘autosubscribe’ to changes on models, which are then pushed by the server as updates are completed. This keeps data always up to date, but does require a bit more commitment on the backend. So maybe I should consider implementing something more akin to what SWR is doing, so that such a commitment is not needed.

However for my use case I would probably still need that degree of real-time interaction, since I have a few screens where people may be working on the same thing in real time. So, a combination of both should be supported-- with web calls made as a fallback when socket support is not set up or available.

Of course, this kind of functionality might be accelerated if we get more teams using it, so I’d once again like to recommend using it in whatever MFE you’re working on. With as many advantages as it confers (especially regarding forms, live updates, error handling, etc) the savings in time would easily pay for covering the feature gaps, and since we don’t have such guarantees in MFEs at present anyway, you’d not be missing anything :)

1 Like