search

nusmodifications / nusmods

🏫 Official course planning platform for National University of Singapore.
https://nusmods.com
MIT License
581 stars 316 forks source link

Plans going forward #1046

Open li-kai opened 6 years ago

li-kai commented 6 years ago

Currently at nusmods we are facing a few issues that are not code related (mostly):

General

Server

Accounts

Are we going for this? If we do the following options are

  1. Our own using Django pros: not dependent on services shutting down cons: maintenance, graphql plans
  2. Firebase pros: fast (e-liang already has a branch) & low maintenance cons: code weight (firebase is super heavy)
  3. AWS using appsync & cognito pros: fast & fits with our graphql + offline plans sample cons: cost (around $4 a month)

GraphQL

Splitting up server and the scraper completely would be really useful. But I don't have a preferred way to do this right now. If we do go with Django for accounts, the integration with graphql is unfortunately not as good. Also what database do we go with? We already have a mysql one.

Opinions?

Let me know what you guys think, and which ones we should tackle first.

li-kai commented 6 years ago

General

We do need to lower our bus number. Onboarding is easy to solve with more docs. I'll give a talk at Friday Hacks to recruit more people 😆 and start being more transparent about issues on telegram.

Server

I think most of these can be solved with Docker and Docker-Compose. A script that simply pulls git and run docker-compose restart will solve most of our problems. Before we can do that we need to sort out how we want to do development, do we want to depend on Docker-Compose too? That's doable, but node_modules and our tooling become harder to manage and use.

Accounts

I think the AWS route is good. It fits in with a lot of our use cases and app sync isn't bloated. I cloned the sample project and built it. 270kb for appsync + apollo + react is very reasonable. Their endpoint is at tokyo though, but I don't think that's a big concern.

ZhangYiJiang commented 6 years ago

I'm skeptical of the value of Docker relative to its complexity, but if you can do a MVP I can take a look.

I'm not sure if 270kb is reasonable, given that all of NUSMods JavaScript is less than that. Perhaps if we split auth out to be loaded asynchronously, but that makes building features depending on it awkward.

taneliang commented 6 years ago

I sent an email to Auth0 yesterday to enquire about their open source program. If they'll let us use it for free I think it's a decent solution. We'll have to implement our own account UI because their auth0-lock package is gigantic. Alternatively, we could use their hosted login pages and we won't need to build any auth UI into the main app.

One (pretty bad) backup idea for auth I have is to use a bare Rails app with the Devise gem just for auth. GraphQL support in Rails is also pretty bad - it's exactly the same as trying to build a GraphQL API in JS from scratch - but we may be able to use it just to generate non-JWT session tokens. We could even use Devise's built-in auth UI to offload even more work.

I'm not sure if we can easily expose an API for third parties if we use Firebase, which is its biggest con for me.

We may be able to try Prisma, paired with Auth0/Firebase for auth. Was reading up on Prisma yesterday - their docs have been updated a lot over the past few months. I think it's promising. As we basically need an authenticated, real-time CRUD system, Prisma can handle a lot of the work for us. Django might not be well suited for this - I really doubt it'll be easy to build GraphQL subscriptions with it. The only thing that may not work OOB on a Prisma-based system is conflict resolution.

li-kai commented 6 years ago

I totally get the push against docker. Wondering if you or e-liang have other suggestions. I’m not sure what kind of difficulties we’ll encounter but I’m sure there will be some. I tried it here and it was pretty convenient once it was all up and running: https://github.com/li-kai/givingchy

yangshun commented 6 years ago

We do need to lower our bus number

I think we need to increase and not lower it...

I'm not sure if 270kb is reasonable, given that all of NUSMods JavaScript is less than that.

It can be loaded once and cached then on using Service Workers right?

One (pretty bad) backup idea for auth I have is to use a bare Rails app with the Devise gem just for auth.

Agree that it's not viable. A microservices architecture here is not necessary.

Regarding auth, why don't we use FB/Google login directly? Almost everyone has a FB/Google account. You no longer need to build login/forget password UIs using FB/Google login. I'm not very convinced of the benefits of using Auth0 vs raw FB/Google login for a relatively small app.

I think we might be overthinking and over-architecting this. We all agree on using GraphQL. Now we just need to finalize on the backend framework and database (have we finalized them?). We could try out one solution, if it doesn't work, switch to a new one. Prisma seems good based on the positive reviews I read and after spending a while trying it out. But check the price first.