This idea, and topic to be frank is a very abstract one to say the least. It extends past the topic of game design, and embarks on a topic of semantics, and overall development, and who's perspective it emanates from. Say I make an object that renders 3D objects to the screen. It's a very self-contained object, and reusable in other projects. Now let's say Dave a programmer who writes bank software for whatever reason needs to use my object for whatever reason since he does not know how to perform 3D rendering.

Well in this scenario above I as the author of the 3D rendering Object can refer to my code as the back-end to Daves Bank software 3D functionality. But now Dave authors a few functions that calculate all sorts of monetary taxes, and interest. And Sally comes along. Sally is no accountant, but she is in charge for the GUI of this Bank Software. Sally uses Daves functions/Object for performing all the necessary calculations for an amount in a savings account. Dave could than say that he authored the back-end for the savings account, and Sally is interfacing the front-end of the application with it.

Now say a end-user uses this bank software. Well Sally could say that the end-user is interfacing with the front-end of the application, and that she authored the back-end of the GUI. And due to the intricacies, and dependencies normal everyday software can have, this can be extended a lot further.

Programs are like onions. They have several layers, and each layer can be said to have a front-end, and a back-end. So it's not an argument of is it a good design, but more so an observation that it is a design, and methodology that is present in most, if not all software development, and shoot, even engineering in general.

Marcus Hansen

Then using Blueprints for the stuff that the user can see like animations(aka front end).

It doesn't matter much the cost of using Blueprints is so low now you can make the whole game with it and won't even notice, and in the end you will need to use Blueprints to connect the C++ code to the game.

Also the Blueprints save a huge amount of performance with things like opening doors, often game developers don't want to rotate the door using the in game rotations and export it as a skinned mesh that is a lot slower, blueprints allow you to program it once and then reuse it as much as you want.

So yea, you can do it as you mentioned, however you will be using the Blueprints more than you think.

also feel free to tell me any disadvantages of this.

Online games do the pattern quite often. The game client only renders a view of the data, and is only given enough information to view the game they can see to prevent cheating. For example that means when people are around corners their information isn't sent to the game client, otherwise a transparent wall cheat could see them.

The biggest disadvantage is something you will need to resolve based on the specifics of your game: There is a delay in communications.

The time between when the player triggers an event, the data is encoded and sent across the wire, the server process it, the response is sent back, the client processes it, the client prepares it for display, and the client finally rendering it, that can be a LONG time. It may be as short as four or five graphics frames, or it may be twenty or thirty graphics frames or even longer.

How you deal with that depends on the game you are building. A turn based game like chess this isn't an issue. A real time strategy game or a first person shooter that delay will be a primary issue for all development.