paulscherrerinstitute / alphafold-on-fire

GNU General Public License v3.0
1 stars 3 forks source link

Tech stack decisions #2

Open pozsa opened 2 years ago

pozsa commented 2 years ago

This issue is meant to document our decision regarding the initial tech stack we intend to use for the application.

Backend:

Frontend:

pozsa commented 2 years ago

So for the backend, I believe we are all in agreement that we want to use python. I propose that we use fastapi. https://fastapi.tiangolo.com/

Any objections or other proposals?

pozsa commented 2 years ago

When it comes to frontend, all of us have limited xp. We'll definitely need HTML, CSS, and JS... no real questions or things to discuss when it comes to html or css. JavaScript is a different animal though.

So let's see some data: https://2020.stateofjs.com/en-US/

sbliven commented 2 years ago

I agree with FastAPI. 👍

For front end I would avoid a heavy frameworks like react & angular. I prefer using a toolchain that preserves a more-or-less 1:1 relationship between the code you write and the html/js delivered to the client. For the minimal viable product this could be literally static HTML and JS code.

A step up from this would be a build tool like webpack/gulp (I guess snowpack is the new hotness?). This makes it possible to use npm libraries and do basic minification. I use webpack in SciCatEditor but it's a bit clunky. Maybe worth trying snowpack or esbuild?

In terms of languages, I think HTML preprocessors (e.g. pug or slim are nice if you don't mind spending some time setting them up (configuring the build tool usually takes me at least a day). However I'm not sure we have a complex enough frontend for this to pay off. Likewise, TypeScript is a huge improvement over pure JS, but takes time to configure the build process so it might be a wash. I used it in a personal project a few years ago.

pozsa commented 2 years ago

I believe that for the proposed MVP we don't need any JS framework, heck we don't really need any JS for that. We could also just go for server-side rendering without compromising the UX. Thinking about the possible additional features though, I am not sure going without a JS framework is the right choice.

sbliven commented 2 years ago

On the backend I expect the authentication to be the most complex part of the app. Would something like appwrite be able to support our auth workflow? If we're going to have to write a lot of code I'd prefer python over node.

pozsa commented 2 years ago

With appwrite we would use "serverless" functions if we need custom logic. https://appwrite.io/docs/functions

The supported runtimes: (includes python) https://appwrite.io/docs/functions#supportedRuntimes

About the original question though.. can we make the auth work with appwrite? I don't actually know.

pozsa commented 2 years ago

How about using flutter for the frontend? If I understand correctly it's a single app and you get a native app feel on mobile (both iOS and android) + a web app.

minottic commented 2 years ago

I would use a framework for the frontend, as if we end up needing to write more fe code, I'd rather have something standard. The main concern against flutter I can find online is that it is not completely stable yet, but for what we need to do we might just try it out and see how it turns out? People say it's easier than angular e.g.

pozsa commented 2 years ago

Even though appwrite is an interesting idea, I still think we are better to go with our original plan. For the frontend, flutter seems very enticing, but I fear the more complex 3d visualization elements in the planned future. JS framework choices to consider are react, angular, vue, and svelte. angular has nothing going for it, so we should drop it as an option, IMO. react is the most used ==> easiest to find future devs for if needed vue is supposed to be an easier learning curve than react svelte the new kid on the block, very positive early adopter feedback

pozsa commented 2 years ago

For emails.. does PSI have its own service? Do we need to use that? Is it any good? or should we use SendGrid?

pozsa commented 2 years ago

For db.. sql vs nosql? If sql... mysql or postgresql?

minottic commented 2 years ago

It doesn't look like we need a nosql db for now, unless I am mistaken. Between MySQL and PostgreSQL, I don't see much difference in what we have to do, so I would go for PostgreSQL as it has more features and similar performances.

sbliven commented 2 years ago

Let's just do simple html for the front-end initially. We can add a framework later if needed, but I'd rather get something going quickly instead of spending a lot of time learning react or whatever. I'm not convinced we will ever need it.

sbliven commented 2 years ago

For emails.. does PSI have its own service? Do we need to use that? Is it any good? or should we use SendGrid?

PSI has a mail service. I know that PSI machines need to get whitelisted by IP, so I'm not sure whether it works outside. Normal SMTP is accessible from the internet, so I guess it should be technically feasible.