Sure. That’s just a rough list to generate ideas. I’d love to be able to get people contributing to MFE-based frontend tasks more easily.
I’ve been having a hard time finding time to prepare for this, but I think I’m somewhat ready now. Anything left out can be reserved for later talks.
Now it comes to scheduling. These used to come with mid-sprint meeting. Should we follow that and keep it with the next social chat? Perhaps 1h after the social chat i.e. reserve 1hr for the social chat and start the tech talk then?
1 Like
@kshitij Yup - though you can probably pick any time you’d like. As long as it’s recorded for everyone to see async, then what counts is that the time works for you, first 
And great that you’ll be doing this - thank you! 
It’s been more than a year now, but I’ve finally found time to prepare for this talk.
Please indicate the best time to have this tech talk at the following link: Calendly - Kshitij Sobti
9 Likes
Most times are too early for me but I’ll definitely watch the recording. 
2 Likes
Oo calendly has a whenisgood-like thing? That’s very good to know!
I’m also happy to watch a recording if my times don’t work for others 
1 Like
Same, those times don’t really work for me but I’ll watch the recording!
Same for me – but also looking forward to watch it async :) Thanks for doing this Kshitij!
Yeah, I just noticed it recently and figured I’ll try it out here. I think it was pretty straightforward.
I’ve booked a meeting for one of the leading times on 23rd. Hope to see anyone who can attend there!
1 Like
Really sorry everyone. I’m facing some tech issues. I had a power outage and now my desktop refuses to start.
If I can’t get it running in another 5 mins. I might need to postpone.
2 Likes
I’m very sorry for needing to postpone this. I’ve got my computer up and running now, but I feel like some kind of explanation is deserved.
Today, I had a longer-than-usual power outage and needed to shut down my desktop, which is something I rarely ever do. The power came back well in time before the meeting, but when I tried to turn on my computer, it just wouldn’t, unfortunately I wasn’t able it get it started on time. I think in my recent attempt to diagnose over-heating, I accidentally loosened the power button and, now it doesn’t work.
In any case, if the same time next Tuesday is suitable to everyone. I will set up a new meeting for then. I could do the same time tomorrow, but I think I’ll need some time to properly fix this issue, and set up my laptop as backup.
1 Like
Same day/time next week works for me Good luck with your hardware! 
I’ve rescheduled it for the same day this week then. i.e. Wednesday, same time.
3 Likes
@kshitij Thank you for the tech talk!
Imho, I think it could’ve been a bit shorter, but otherwise it was very useful. Even though I did some work on the discussions MFE before, I still learned a few new things from the talk.
Can someone please share a link to the recording? :)
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.
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