I noticed that in Bens tutorial he split the graphql-server and the client in two projects
what are the reasons doing that?
#why split server and client?
scenic anchor
pearl aurora
did you imagine it working any other way ?
the server code runs on the server and has access to the database, the client code runs on the browser and sends requests to the server code to gather data for it
scenic anchor
what I meant is why creating two different projects
you can tell your web server to communicate to the database, be an API and server SSR pages, but some people split client and server and then have to start both
pearl aurora
I'm not sure what tutorial you're talking about, but if your front end uses something that does SSR and requires an active server, there isn't a different way to do this
for example my last project had a rails API and a Nuxt front end, there is no other way but to start a rails server and a node server
scenic anchor
in Next.js you can write your API and your front-end-SSR code in one single server
Next.js will make an API accessible and you can use the same server to deliver SSR pages
even if you have a simple express server, you can offer both with one single server, have a REST/GraphQL server and a server that delivers SSR pages with the template-language of your choice
what I noticed is that some devs split their REST/GraphQL server and their SSR page server
I would like to know why it is done?
to have two different threads versus a single server that have to do everything?
to have make code easier to understand and reason about?
@pearl aurora hope the question make now sense 😄
scenic anchor
makes sense, but my gut is saying that it is done because of performance 🤔
pearl aurora
we don't use guts for performance, you'd need to benchmark to make any claims
pine monolith
- Scalability: By dividing the program into a client and a server, it is possible to scale the program more easily. For example, if the program is a website and the server is a remote computer, then it is easy to add more servers to handle the increased traffic.
- Security: By keeping the server separate from the client, it is possible to better secure the program. For example, if the server is responsible for storing sensitive data, then it can be kept on a secure server that is not accessible to the public.
- Reusability: By dividing the program into a client and a server, it is possible to reuse the server on different clients. For example, an api can be used as part of a website but can also be used on a native app.
- Maintainability: Dividing the program into a client and a server makes it easier to maintain the program. For example, if a bug is found in the server, then it is easier to fix the bug on the server without having to update the client.
Although there are some cases where it may be useful to combine the client and server into a single program.
- Simplicity: If the client and server are small and do not need to be scaled or secured in any special way, then it may be simpler to combine them into a single program. This can make the program easier to understand and maintain.
- Performance: In some cases, combining the client and server into a single program can improve performance. For example, if the client and server communicate using inter-process communication (IPC), then this can be faster than using a network connection.
- Offline functionality: If the program needs to be able to function without an internet connection, then it may be necessary to combine the client and server into a single program. This allows the program to continue functioning even if the server is not available.
However, it is important to note that, in general, the benefits of separating the client and server tend to outweigh the benefits of combining them. As a result, most modern programs are designed to be distributed, with the client and server running on separate computers.
hope that answers your question
scenic anchor
thanks
silk orchid
honestly why would you put it in the same project