Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tech stack decisions #2

Open
pozsa opened this issue Nov 9, 2021 · 14 comments
Open

Tech stack decisions #2

pozsa opened this issue Nov 9, 2021 · 14 comments
Assignees
Labels
question Further information is requested

Comments

@pozsa
Copy link
Member

pozsa commented Nov 9, 2021

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

Backend:

  • fastapi in python
  • packaged as a docker container
  • db: postgresql
  • email service: ?

Frontend:

  • sveltekit
@pozsa
Copy link
Member Author

pozsa commented Nov 10, 2021

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
Copy link
Member Author

pozsa commented Nov 10, 2021

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
Copy link
Member

sbliven commented Nov 10, 2021

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
Copy link
Member Author

pozsa commented Nov 11, 2021

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
Copy link
Member

sbliven commented Nov 11, 2021

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
Copy link
Member Author

pozsa commented Nov 11, 2021

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
Copy link
Member Author

pozsa commented Nov 11, 2021

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
Copy link
Collaborator

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
Copy link
Member Author

pozsa commented Nov 15, 2021

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 pozsa added the question Further information is requested label Nov 15, 2021
@pozsa
Copy link
Member Author

pozsa commented Nov 15, 2021

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

@pozsa
Copy link
Member Author

pozsa commented Nov 15, 2021

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

@minottic
Copy link
Collaborator

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
Copy link
Member

sbliven commented Nov 16, 2021

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
Copy link
Member

sbliven commented Nov 16, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants