I don't believe there is a formal definition for those terms, and as you noted there is overlap in some cases.
front-end
and client-side
overlap.
server-side
and back-end
also overlap.
If I were to split hairs, I would offer these rough boundaries:
client-side
is an application that runs at the users' computer. It could be a stand-alone application (more often) or it could refer to a web browser based interface (less likely).
front-end
also faces the end-user and generally runs in a web browser based interface. I haven't heard of thick clients being referred to as a front-end
.
back-end
refers to processes and services that are running either on another server or in the background of the users' computer. More often than not, it refers to processes that are not on the end users' computer. But the key, as you mentioned, is that the end user is not necessarily aware of the processes running.
server-side
is an extension of back-end
but explicitly reinforces the fact that the processes are running somewhere else and not on the end users' computers.
By way of example, and to highlight the confusion between the terms, I'll use Minecraft as an example.
Minecraft has a
client-side
application when you run the jar files locally with your own JVM.
front-end
if you choose to run the client application in your web browser
back-end
process that can be running locally on your machine if you are in stand-alone mode
server-side
process if you choose to log into a server hosting the Minecraft server application.
If you dig into some of Minecraft's statistics, you'll see that they simply designate a client
and server
component to the game; they don't necessarily care where those components are run.
To directly answer your questions:
Is the term 'Front-End' synonymous with 'Client-Side'?
Sort of, but not really. There's a nuance between the terms if you are discussing things outside of the web based world. If you're strictly within the web based world, then yes, they are functionally synonymous.
If so, is this always the case?
In the web world, I would say yes. In other realms, I would say no as explained in the rough definitions I offered.
Decoupling components from the database / getting away from direct database connections is a common pattern. Moving access into middleware / a component that front-ends the database can help improve security and modularity, and provide a place to implement data validation and interpretation that would otherwise "fall into" SQL, stored procedures, and client-side database code. Against this you have to weigh the development, runtime, and possibly economic cost of that middleware / data mangement front-end. But at many project scale-points, data front-ends are often considered a good choice.
If you control the backend design and components, using a RESTful API--especially in its common format, e.g. served by HTTP and encoded with JSON--is notably inefficient compared to other alternatives (e.g. direct library linking, Protocol Buffers, Thrift, various kinds of ESB, other RPC mechanisms, ...) that do not go through a serialize-to-text, serve, deserialize-from-text cycle for every API call. REST is also semantically better as an arms-length interaction mechanism, given that some constructs (e.g. multi-step transactions, streaming, large binary objects, raising exceptions, guaranteed delivery, ...) are more simply, cleanly, or directly handled with other forms of interaction.
Some reasons you still might want to use a RESTful backend: simplicity, consistency (every client, local or remote, goes through just one API), and time-to-market (e.g. not needing to learn another API/interaction style). These assume that you are exposing your database, relatively directly, through the RESTful API. If it is strictly for the use of components under your control, REST is probably not the best choice (for either semantic richness or efficiency).
Best Answer
Short answer:
I don't have enough information about your environment and goals to give a simple and helpful short answer. See my long answer below.
Long answer:
This is a really hard question to answer. There are a lot of specific things to your team and your project that lead to deciding on a best architecture for your system. To answer it well, there needs to be more detail around the goals and requirements for this web app. For example:
My opinion on the "practical" vs. "perfect" question is, make it more practical. If it doesn't ship, the project doesn't matter outside what you learn.
The answers for questions 1, 2 and 3 lead to how big and complex the system needs to be. (If a lot of traffic is expected and page load time is not that important, more layers and more systems could be introduced. If there are areas of data that can be cached, then that can offset other places where it is slower to get data.)
On authentication and account creation. This is a surprisingly complex topic that takes time to really understand. Whether using OAuth (assuming OAuth 2.0) against your own API, regular password authentication, or OAuth authentication against a third-party (facebook, google, etc.), you'll still need a way to create user accounts within your system.
On OAuth: the most common use for OAuth is for allowing a third-party system/service to access data in your system that is owned by one of your users. It does have the flexibility, however, to allow password-based login. This means that, once a user has created an account on your system, you can use the "Resource Owner Password Credentials" grant type in OAuth 2.0 to authenticate that user. Check out the full rfc if you have not yet done so.
Here are a couple common ways to architect web applications (this is not comprehensive and there are tons of variations):
I would follow #1, #3 or #4:
I would follow a combination of (#2 and (#1, #3 or #4)) (parenthesis for clarity of operational order):
If I had a product that was publicly available and would be indexed by search engines, I would not do #1 nor #4.
My team matters a lot to me. Their preferences, experience and desire to learn would affect what I choose architecturally between #1/#4 and #3.