TIL that there can be a client repo and server repo
Posted by milonolan@reddit | learnprogramming | View on Reddit | 9 comments
Second year computer engineering student. We've used quite a lot of git version control etc, and I've always been able to perform API fetches. But today I was working with one of our startUp repo that apparently is a "client" repo.
How do you make a repo client or server? It is related more to what's in the package.json?
Or is it something you set in your code?
Is it different from GitHub repo?
How does it work?
Is it common to do this?
HolyPommeDeTerre@reddit
I am not sure I get your question. So I am going to clarify a few things, maybe not needed but just to be sure.
A repository is a place to put files. You can put images, videos, pdf, text... Whatever. The repository contains the files and you can "version" them git.
Now, it's very efficient to put code in a repository for a lot of reasons. But the first is, the diff between the changes are easy and consistent. So it's easier to manage this kind of files. Where managing images can be trickier.
So the repository acts like a "enhanced folder". A set of files that goes together.
So there is no client/server repository. There is the concept you put in your repository "client app" or "server app". As you know what's inside, you know how to work with it.
You can have a monorepo. Which is a repository with multiple apps inside it.
milonolan@reddit (OP)
Yea I think I was a bit confused because I was trying perform an API call on a repo that only had mostly react component, hence the "client repo" and that I needed a "server repo" to perform the fetch. I didn't know you need a server file to perform calls while having mono repo. I've always used firebase and supabase server so there was never the need to use a "server"
HolyPommeDeTerre@reddit
Ok so there are a few things we can review to help you understand better.
Since you seem to be in web (react) with a client / server. We can clarify why you need 2 apps. I don't know the specifics of your applications so I am going for the most generic style we have. The most common one.
In web, you offer an UI to the user. The user uses this app to do things. Depending your application you may (most certainly) need a server. It's not mandatory, you can do it all in the browser of the user. Only a client app, that can do it all. But most of the time you need a server. An HTTP one. Because the browser allows for communication over HTTP.
The server is an application that will listen to HTTP request to process it. It starts and waits on the server that a user does something through the client app. The client will send a request to the server, the server will answer. The client will display the result.
There is far more to the HTTP protocol and how to build a website. This architecture isn't all there. But it's what we have most this era.
comment_finder_bot@reddit
I'd assume that the client repo contains the client code?
milonolan@reddit (OP)
Yes, the UI component mostly
EliSka93@reddit
Well, while it's not necessary to do it that way, it's a good way to keep your code separate and know what pertains to what.
iOSCaleb@reddit
You’re overthinking this. A client repo is a repo that contains client code. A server repo contains server code. If you’re working on a game, you might refer to the repository in which you keep the code as the “game repo.” The descriptors here are just used to differentiate one repo from another.
tb5841@reddit
Most web apps separate their code into a backend repository (for code that links with the database, and runs on the sever) and a frontend repository (code which will run on the client's browser). The two connect by the frontend making API requests to the backend.
Ordinary-Juice1934@reddit
code repository is like a folder on your PC, and you can put everything there. You can create it in GitHub, GitLab, Bitbucket, etc.. but the main idea is to share your work and collaborate with more people. Depending on the project, you can structure it however you want. On repo can be for the client/frontend app, one for the backend, one for the mobile app..