Decide on the stack

[wtl420]

What technologies are we planning on using for this? We need to come up with a list of what makes sense. It doesn't have to be an absolute list, we can pull in new things as needed and even transition away from established technology if it no longer suits our needs, but we should have a base level of what we want to work with.

[wtl420]

Some things I'm thinking about with the back-end:

• go vs rust for backend, I think both are pretty viable these days and worth considering. Go has really nice concurrency out of the box but rust's memory management is pretty amazing.
• postgresql for the database
• graphql for APIs? need to look into how this works exactly for our use case- might be more complicated than necessary; we could always stick to good ol' rest
• https://internetobject.org/ this instead of JSON/XML would be interesting
• s3 support for uploads? I think we don't need uploads to launch but it'd be a good idea to do something like that if we go with them. Linode has an s3-compatible storage system as well, so I think s3 might be more-or-less universal. There are some dedicated image providers that do some cool stuff too such as https://cloudinary.com/ but might not be worth our time. Discord has a cool library for handling images as well https://github.com/discordapp/lilliput
• kubernetes for infrastructure- this should make it possible to easily build up different environments as needed. Will have to look into what kind of cost comes with that though.

I haven't given much thought about the front-end, would love to see @keithpickering take the reigns there.

[keithpickering]

GraphQL I can offer a tiny bit of insight on this because we used it for awhile before switching to a rest api. The more senior software engineer on our team said that GQL basically had "no use case", but really the issue was that our iOS app had to go through some middleman library (Apollo I think it was called?) which was slow as shit. In general I thought GQL was fun but I do have to admit that I can't really see the point of it compared to rest.

Internet Object This thing is still so cool, idk if the bandwidth savings would amount to anything with our limited traffic, but if there's a simple way to use it I'm down.

S3/AWS I was wondering if we wanted to take advantage of any AWS services. S3 is definitely a good one if we're going to support user uploads. We can look into stuff like cloudfront for content delivery, codepipeline for automatic deploys, etc. The costs are pretty low but then again I'm sure we can set all this stuff up on our own server if we wanted

Frontend Probably just going to use react since I've gained so much experience with it. I'm open to suggestions for state management though because redux is sort of a chore to work with. As for UI I'm going to look into some newer SASS frameworks to lighten the workload a little bit. Bootstrap is a classic but it's kind of boring. Maybe bulma or something BEM-based

[wtl420]

GraphQL

I think GraphQL would be harder to implement on the back-end side of things but that's what makes it interesting to me; I feel like the front-end would have more flexibility to do things without needing specific endpoints and we could potentially reduce data sent over since you'd only query for the data you need. That being said I don't have any issue with REST at all, it's straightforward and should work fine for what we want. See below for gRPC though, which I believe would affect our choice here.

Internet Object / Data Transfer Format

Discussed with rtsmarty about Internet Object over Slack; looks like it's still not well defined and there's no clear release date on it. There's a repo for an implementation in JS that makes it very clear its not ready though it does seem to be in active development. I don't think it's worth waiting on.

Another thing we could look into is gRPC https://grpc.io/ - https://github.com/grpc/grpc-web exists so we could use that on the front-end.

S3 / AWS

I don't think we need to worry too much about other Amazon products, but I do feel like we'd need a solution for uploads. I don't think we need to support uploads for our MVP but we still need somewhere to store assets - I definitely don't want to store binaries in the code if we can avoid it.

React / Front-End Stack

React sounds like a good choice, @keithpickering - I'm not too familiar with it and it'd be a good opportunity for me to learn more. I am familiar with Angular, which would be a good pick IMO as it's an all-in-one MVC framework for the front-end. The documentation isn't the best though so there's some pain points there. React is definitely more of a "some assembly required" depending on what we want to do with it, but it is the leader in these things so I don't think we'd run into any issues putting it together. I assume Vue is off the table, though I think with Vue at least you don't need Redox for state management.

Definitely want to try something other than bootstrap. Bulma is pretty solid, I've used it in the past. I really like what these guys have to offer https://semantic-ui.com/ - There's a solid list of different ones we can evaluate here: https://www.keycdn.com/blog/front-end-frameworks I'd like to work with an established framework as a base so we don't have to re-invent the wheel.

[wtl420]

I'm kind of interested in emberjs for the front-end https://emberjs.com/ - apparently its alive and well and a more mature front-end framework would be cool rather than the trendy ones.

[wtl420]

I think I'll scale back the big ambitions with the back-end. I still want to be API focused and not view templates in the PHP code so the Front-End will still live in its own separate repo.

Here's the plan:

• S3 / AWS compatible image store for image uploads. I still think this is the way to go here. Ideally keep all images and binary files out of the repo.
• Ansible script for setting up the server and a docker image for development. This makes it so we can all work in the same environment and it's easy to spin up a server when needed (for deployment, for example). Pulling Kubernetes out of here because I don't have a complete grasp on it just yet and there's a lot of moving parts there that we shouldn't have to worry about- we can always change into that kind of infrastructure later if we want to. (I will be learning more about it anyway, independently of this).
• PHP Symfony back-end. It's not as cool or exciting as Go or Rust but it gives us a solid foundation. Modern PHP isn't too bad and Symfony has fantastic documention and solves everything we'd run into for this project.
• PostgreSQL for the database. I've been wanting to work on a PostgreSQL project for some time now.
• REST APIs- I want to be API focused and I think sticking with REST for API interactions is the way to go. We can experiment with some GraphQL endpoints if we want but I believe REST will cover most of our usecases.

This is a bit more safe but I have more experience with the tools here so I think it'll be easier to hit the ground running and not let this project get stuck in a wishlist kind of stage.

[wtl420]

Need to split this out into multiple issues for the tasks related to deploying different pieces, will mark as complete once all issues have been created.