golang-friends / slack-clone Goto Github PK

Acceptance

• Given a brand new user
• When creating a new account
• Then an account should be created in the repository

Let's rename AuthService to authservice or simply auth (lowercase) to be consistent?

AuthService/cmd/authservice/authservice.go -> auth/cmd/authservice/authservice.go

Not all file systems are case sensitive by default.

I propose to start with web (no hybrid like ionic, no native like flutter, react-native) for the sake of simplicity. And, I propose Angular as it's already pretty opinionated on how to structure the code as well as how to maintain the states although other frameworks may be much simpler to begin with (but everyone will have different opinion on how to structure). Also, I assume we agree on using TypeScript at least.

There are mainly 3 pages.

Signing into your workspace

Instead of workspace your-workspace.slack.com, we will simply call your-workspace

This is purely done in client side. So, any outgoing requests will have this workspace ID.

Login & Signup

We will have slightly different behaviors here. Instead of email signin/signup, we simply use email & password signup/signin.
Also, the user exists per workspace. But, I believe our current implementation is global like discord. We probably need to fix this first or the spec needs to change (slack clone -> discord clone)

Workspace

And, we simply want to focus on chat functionality initially. So, let's not touch the thread part.

This step was necessary to cache the dependency though.
Without it, everytime a code changes, everything has to be re downloaded and built.

For reference, https://medium.com/@petomalina/using-go-mod-download-to-speed-up-golang-docker-builds-707591336888

For example, the proto fields should be lower case (https://developers.google.com/protocol-buffers/docs/style). The generator will convert the names to match the go style guide (PascalCase)

Looking for suggestions here. I am most familiar with Mongodb, Redis, and MySQL.

how it structured is monolithic because of having root internal and root pkg. Each service will freely import each other causing tight coupling.

Do you have a suggestion or expectation on how the project should be structured?

This is going to be a monorepo

Each service should be a go module as its own without root go.mod

/auth
  /internal
  /...
  go.mod
/chat
  /internal
  /...
  go.mod