the idea that an app can be completely "client-side" creates more trouble, as it's often a marketing point of a lot of services around the Web (you can find a lot of services that claim to be "serverless"). This is... not completely true.
When you connect to a website, there is always a server that sends you the html page that you will load. When a service claims to be "serverless", it typically means that all the details of this server (that always exists) are completely abstracted from you, and all you have to do is to copy some files in a remote directory, and those files will be served for you.
I hope this is clearer now
Gomix provides you full control on both the "server" and the "client" side. Now an additional bit of clearness: in the Gomix editor you see your files split in "back-end" and "front-end". But there is no magic going on, actually: all those files are in the server. The split just tells you: if you put a file there, what you probably want to do with it will be executed on the client (the browser). So the split doesn't tell you where the files are (since they're all in the server), but where the files will be executed.
On the other hand, the files that you see in the "back-end" section will only be executed in the server, the client will never get them and execute them.
Let's take an example:
views/index.html. That files lives in the Gomix server, at
/app/views/index.html. See? It's in the server. But you see it in the "front-end" section. Why? Because it will be executed by your browser: the Node server that lives in
server.js will send the content of that file to your browser.
On the other hand, let's look at what
server.js contains. It is a very simple Node module which is executed on the server (back-end), and what does it do? It creates an HTTP server using the express library.
How do you decide what to execute in the client and what to execute in the server? Well, simply respond to these questions:
1) which information should be saved after the user closes the browser? Anything that you run client-side is bound to that particular view, and with some tricks, to that specific browser and computer. For example: login information cannot be kept in the client-side, since if the user switches computer, all her details get lost!
2) is this information "secret"? If you don't want to share some information with the user, you cannot send it to the browser! So it has to stay on the server side (e.g.: the password to access the database of your web application...)
3) what is faster, to compute something on the server, or on the user's computer? Modern browsers can compute a lot of things very fast, but this doesn't mean that you have to do all of the heavy lifting on your user's computers! Some computation can be done on the server (see, again: server-side just means "this file is executed on the server", not "this file stays on the server), and then the result can be sent to the user.
I hope I didn't make things more complicated To summarize, the concept is very simple:
server-less is a lie. You will always have a server. All the files you see in the Gomix editor are on... a server.
back-end files are executed on the server. E.g.: a database, an http server...
front-end files are executed on the browser. E.g.:
public/client.js. These files are on the server, they are sent to the browser and executed there.
The minimum thing that should be on the server is an http server, that is responsible of sending files to the browser to be executed. See
server.js on a base Gomix project.
The minimum thing that should be on the "client-side" is an html page, that the browser will load to execute further stuff (mostly JS scripts).
Additional things on the server-side: a database, advanced computations, secrets.