alisomay commented 1 year ago

Introduction

Closes

5
4
3
2
1

This PR is meant to bootstrap rust-at-night website project.

It is important to review this PR as a proposition instead of a made decision.

We can discuss under it and improve this PR if necessary to agree on a project structure we all comfortably could work with.

Tech Stack

Choosing a pure Rust tech stack for this project may sound ridiculous or overkill. I'd say it actually is! An accurate example would be using a V8 engine on a small motor bike.

But actually we have reasons for this.

This website (maybe future web app) was born from a Rust telegram group.
It not only serves the purpose of representing the group but also as a playground for learning, experimenting and mentoring.
By mimicking a Rust production frontend and a beckend experienced people in the group will have a project on the table to exchange ideas and learn from each other and people who has little experience can gain experience by contributing to this code base in a friendly and safe environment. No judgemental attitude is welcome. This will be also underlined in the code of conduct later.

Axum is chosen as the backend framework not only because it is a part of the tokio stack but also seems like it holds a good future.

Yew is chosen as the frontend framework because it seems like that it is the most developed one in the rust ecosystem.

Running the project

Please check README.md for instructions for testing and running the project.

Aren't huge PRs bad?

Yes they are. On the other hand this is a bootstrapping PR and we need a lot of files to show the whole picture. For later PRs I think it would be wise to consider a PR which changes 28 files as bad practice.

CI

CI just runs tests, style and linting checks currently. It is yet to be developed.

Project structure

Project is a cargo workspace which has frontend and backend crates. Shared dependencies among them are declared in the workspace. just is used for shell command abstractions. A rustfmt.toml is included for opinionated configuration.

Frontend boilerplate

I haven't worked with yew before but to be complete I have included a boilerplate which I came up with by common sense.

The person who will be mostly working on frontend will most likely improve it.

Ending Notes

There is no deployment or infrastructure related stuff is added currently. I'd encourage you to clone and test this branch. Also take your time to review it.

Please nitpick freely.

The sole purpose of this PR is to find a common ground in project structure even if it is not complete and lay the groundwork for more interesting features to come.

Please review with an architectural and structural eye. e.g. having a posts endpoint is not suggesting that we'll have a posts endpoint. It is suggesting that we'll have an "endpoint" and that "endpoint" will be placed in that part of the code etc. See things as placeholders 🙏

Happy reviewing!

ozankasikci commented 1 year ago

Awesome work, I'm in awe.

Tech stack, initial CI integration, Project structure are all looking great as ground work.

When it comes to the FE, we need to discuss if we're going to use server-side rendering or go with a SPA. Still there is nothing wrong with keeping the PR as is for now, imho.

LGTM!

alisomay commented 1 year ago

Awesome work, I'm in awe.

Tech stack, initial CI integration, Project structure are all looking great as ground work.

When it comes to the FE, we need to discuss if we're going to use server-side rendering or go with a SPA. Still there is nothing wrong with keeping the PR as is for now, imho.

LGTM!

Definitely agreed. We also need a sort of component owner for the frontend. Maybe Orhan will do it or @dvtkrlbs. The boilerplate I've shared is just to have something working. Frontend part is not a suggestion.

te-ori commented 1 year ago

Awesome work, I'm in awe. Tech stack, initial CI integration, Project structure are all looking great as ground work. When it comes to the FE, we need to discuss if we're going to use server-side rendering or go with a SPA. Still there is nothing wrong with keeping the PR as is for now, imho. LGTM!

Definitely agreed. We also need a sort of component owner for the frontend. Maybe Orhan will do it or @dvtkrlbs. The boilerplate I've shared is just to have something working. Frontend part is not a suggestion.

I have developed few spa with vuejs, but not experienced server side rendering. So, it seems more sensible to start as spa and then to do experiments with ssr. But if there are someone who guide us to use ssr, it can be first choise.

rust-at-night / rust-at-night-website

Bootstrap repository #6