Centralization of PSDTools Applications

[ParkerH27]

Let's make many apps into one app.¹

I am planning to start development on a website(later a PWA) that wraps our tools into one. I think we should continue separate repositories for the time being but later everything should be merged into a centralized app
My thoughts about the app are that it should be dashboard-like where you can select what you want to use.
I am also planning on asking around the student and staff base to see if there are any ideas for helpful tools we can bundle into this app. I do not like the idea of 2 different apps (one for teachers and one for students) so it would be cool if this centralized app communicated with it's service worker to only cache the tools that a particular role would need. This would enable easy management of the app as you dont have to separately build two apps.

Footnotes

1. App refers to a website that in the future will be PWA packaged for offline use and local installation. ↩

[ParkerH27]

I also noticed that the way the PWA Manifest is set up, it installs the app from the https://psdtools.github.io/ url. So technically any website as long as it is set up to cache(in the service worker file) and is a repository on our gh org should work.

If this is the case, all of our apps can stay in separate repositories(will help with managing and updating them without messing up other things) and we can have one central repository that holds the PWA package and central dashboard

[lishaduck]

I just want it to be around still when I graduate.
Also, the monorepo model has many benefits. Merging them is beneficial in the long run, as code can be shared much easier, and there are fewer duplicate dependency updates.

[lishaduck]

Also, workbox (which is what powers the vite plugin we use for pwa-ing) wouldn't like having stuff outside of its control to cache.

[PetalCat]

I just want it to be around still when I graduate. Also, the monorepo model has many benefits. Merging them is beneficial in the long run, as code can be shared much easier, and there are fewer duplicate dependency updates.

I think you have me hooked on the monorepo we just need to figure out the way we can build the pre-made tools into flutter then make the repo very clearly organized accordingly

[lishaduck]

I just want it to be around still when I graduate. Also, the monorepo model has many benefits. Merging them is beneficial in the long run, as code can be shared much easier, and there are fewer duplicate dependency updates.

I think you have me hooked on the monorepo we just need to figure out the way we can build the pre-made tools into flutter then make the repo very clearly organized accordingly

If we have the JS code, it should be trivial to switch it to Flutter, because Dart syntax is based on JS. Hopefully. It depends on how powerful the Standard Library is, and how Flutter architectures stuff. Calculating a GPA, though, shouldn't be difficult.

[lishaduck]

I think you have me hooked on the monorepo we just need to figure out the way we can build the pre-made tools into flutter then make the repo very clearly organized accordingly

Good, because looking back, I realized that I already said it was a monorepo in the repo description. Though, it really is seeing as the server and UI are in the same repo rather than being distributed.

[lishaduck]

I think that a central app is a good idea. One backend, two frontends—one Flutter, one JS(or, if you're like me, Elm). The backend could be set up in Azure, as it's basically just a proxy, so the free plan would probably work. The wallet backend is just an intensive plugin, due to the modular extensibility of the backend.

[lishaduck]

Flutter supports a feature called flavors, which could be used to minimize the differences between teachers and students and remove maintenance burden, although it probably won't give us the fine-grained level of control we need, as it requires multiple apps, instead of bundling them as one. I, for one, don't like the Canvas setup with multiple duplicate apps.

[PetalCat]

Flutter supports a feature called flavors, which could be used to minimize the differences between teachers and students and remove maintenance burden, although it probably won't give us the fine-grained level of control we need, as it requires multiple apps, instead of bundling them as one. I, for one, don't like the Canvas setup with multiple duplicate apps.

Yess that is what I envision when I see this app... One app that can just decide hey! I want to be a teacher(aka teacher logs in) or hey! I'm a student now!(when a student email logs in)

[PetalCat]

I think that a central app is a good idea. One backend, two frontends—one Flutter, one JS(or, if you're like me, Elm). The backend could be set up in Azure, as it's basically just a proxy, so the free plan would probably work. The wallet backend is just an intensive plugin, due to the modular extensibility of the backend.

I'm pretty sure we discussed this at lunch and now it would just be one flutter frontend that (since it is flutter) can be a website or a pwa or honestly anything it can dream up and when the server goes down the rest of the tools built in still work

[lishaduck]

I think that a central app is a good idea. One backend, two frontends—one Flutter, one JS(or, if you're like me, Elm). The backend could be set up in Azure, as it's basically just a proxy, so the free plan would probably work. The wallet backend is just an intensive plugin, due to the modular extensibility of the backend.

I'm pretty sure we discussed this at lunch and now it would just be one flutter frontend that (since it is flutter) can be a website or a pwa or honestly anything it can dream up and when the server goes down the rest of the tools built in still work

Correct

[lishaduck]

• https://pub.dev/packages/flutter_tailwindcss
• https://pub.dev/packages/tailwind_cli