You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: assets/articles/0054-medusa-resources-overlimit-in-realtime-notification/medusa-resources-overlimit-in-realtime-notification.adoc
-42Lines changed: 0 additions & 42 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -100,45 +100,3 @@ image::image3.jpeg[]
100
100
That’s it. We have integrated SSE into the System, it works great and this is a base to develop that further.
101
101
102
102
Now we can notify a user if something is happening under the hood and the user should be aware of it. Great!
103
-
104
-
https://t2674704.p.clickup-attachments.com/t2674704/186d6f2b-3b58-49c4-8e93-7db736b0ab5e/medusa_sse.mp4?view=open[WATCH THIS VIDEO, window=_blank]
105
-
106
-
=== Video Plan:
107
-
108
-
*1. Who we are and what we are doing? What do we need now? What is the issue? What are we going to do and how are we going to resolve this?*
109
-
110
-
We are Valor Software, an international company, created by the Developer for Developers. +
111
-
We are fans and sponsors of NestJS and NativeScript and do a lot of awesome things by ourselves, like ngx-bootstrap, and a current one called Medusa.
112
-
113
-
Medusa is a kind of Dashboard and management system for https://github.com/module-federation[Module Federation, window=_blank]. With Medusa, you can finally have visibility into your Module Federation-powered applications. See what versions are deployed, their underlying dependencies and relationships, and which teams are committing to them. That’s in general about Medusa evolving all the time, development moving further and further.
114
-
115
-
Today we have to resolve the following thing:
116
-
117
-
When a user is building his connected application on his own, *medusa-plugin* makes an API call to Medusa Dashboard with the request to update application builds inside Medusa Dashboard, it does some logic and creates a few records in the database so then you can manage and use those builds in the Dashboard then.
118
-
119
-
At the current moment, we don’t have any restrictions for builds' amount and usage according to the Price Plan so users can easily get a quote over the limit, like for using 130 builds with 100 builds limit in the Plan.
120
-
121
-
The task sounds like *_"Restrict overlimit usage of Medusa Resources according to Quota"_*. Sounds like a five-minute task, just insert a checker before business logic. If the check is positive – go further, if negative – stop action.
122
-
123
-
*2. Add a checker* +
124
-
*3. Add Stripe data to the checker to check the user payment method* +
125
-
*4. Add a checker for quotas* +
126
-
*5. Make it reusable* +
127
-
Okay, it’s done. Even works. But there’s another issue – it will look for the User like a bug. No… like a *BUG*. As all things, described above, are under-the-hood processes, the user cannot know at that moment that he got overlimit, so we have to notify the user somehow in some way.
128
-
129
-
*6. Add SSE Service, tell that it should be a Singleton as it’s important and nobody tells that*
130
-
We don’t have any real-time solutions implemented inside yet, so it seems that, easy from first sight, the task becomes a task of implementing real-time technology. Okay, what do we know about it? Web Sockets – cool, but they are unidirectional, we do not need them. In addition, we might have an issue if the load balancer doesn’t support WebSockets (like a basic AWS Load Balancer).
131
-
132
-
*What else?*
133
-
134
-
SSE – Server-Sent-Events. Technology, which might cover a lot of cases where people use WebSockets. In addition, it brings less headache with integration as it uses HTTP protocol only.
135
-
136
-
https://medium.com/system-design-blog/long-polling-vs-websockets-vs-server-sent-events-c43ba96df7c1[Some words of difference between WebSockets and SSE, window=_blank]
137
-
138
-
On the Back End side, we use NestJS, Front End is NextJS (for a non-native speaker, it’s quite difficult and funny to try to pronounce them instantly one by one :) ).
139
-
140
-
Let’s start. NestJS documentation has some words about https://docs.nestjs.com/techniques/server-sent-events[the implementation of SSE, window=_blank]. So it looks easy to do, and it has simple examples.
141
-
142
-
*7. Say that the EventSource listener should be fully FE and as we use NextJS – should be in useEffect.* +
143
-
*8. Check that it works, and set the channel based on UserId* +
144
-
*9. Check that it works for app builds and on login, remove redundant code.*
0 commit comments