A little bit of a conversational post. But I can't continue without it. And in the end little practice working with gitlab

TL; DR

Front, back - two separate projects

bandheart.com
|-- front
|   |-- app #core(gate) app
|   |-- service1
|   |-- serviceN
|   |-- infrustructure
|       |-- some_docker_image_1
|       |-- some_docker_image_N
|       |-- some_ansible_playbook
|       ..... 
|   |-- third-party
|       |-- some_package_1
|       |-- some_package_N
|-- back
|   |-- app # core (gate) app
|   |-- service1
|   |-- serviceN
|   |-- infrustructure
|       |-- some_docker_image_1
|       |-- some_docker_image_N
|       |-- some_ansible_playbook
|       ..... 
|   |-- third-party
|       |-- some_package_1
|       |-- some_package_N

First commit - clean framework, without changes.

main - default branch. That's good. And in general - be correct in the code

No one, newer "push" to main branch. We block this possibility!

A monolith with the ability to extract functional in to service - choice for this project. Not necessarily for you

Front and Back - two separate projects

Back separately. Front separately. There are two main reasons:

1. It allows hiring and working separately with back-end developers and front-end developers. Full stack developers are expensive and not always available, especially for your technologies stack.
2. Secondly, it will teach you and your team to think in terms of client-server concepts. Web front-end - client. Android - client, iOS - client. Project widget on another website is a client, user of your public API also client. It is important. Because many developers do not understand why exist versioning in an API routing. They put v1 as a mantra, and it's cool if they do.

Of course, this approach has its problems. Laravel sells everything in a box for a reason. And the same goes for WordPress, he became popular for a reason. Communication between frontend and backend (and vice versa) is a very complex process, and you must live with this understanding. This can be faster if you got perfect planning by a technical manager who knows everything or by hiring full stack developers.

Fullstack is not option if we make some native applications, for example.

Another problem is deployment. Deploy back front, mobile is not an easy task. But there are solutions.

Monolith or Microservices?

Short answer, for this specific project - "Monolith BUT".

The long answer: Microservices make sense if you understand why they are in the project, for example, if you know the workload, you have a large team, and it makes sense to isolate everyone by services, etc.

Why is this important? Microservices have a good marketer. There was a time in outsourcing when employer didn't even talk to you if you didn't have experience in microservices.

It got to the point of madness, a hypothetical project about selling sausages in the local market of Portugal (fake story, based on real life), had a dozen microservices that physically couldn't be handled by those developers. The microservice of the product list called the cart microservice, which called the order microservice, which required a service of emails, etc. And I understand why development team do this, they gained good experience and grew as professionals. The question is what it gave the owner? Business doesn't need it. He paid an overpriced for the development to then pay an overpriced for the support. And have huge hiring problems for the rest of the project's life

But let's get back to the monolith. I add "BUT" to it, which means being ready to extract some functionality into a separate service. For do this, modularity and clear interaction scheme between modules is necessary. Even in this case, the process of separation into a service will not be simple. But possible. For now, keep in mind that in case of necessity, we will be able to extract separate functionality into a separate service within a reasonable time.

Also, modern projects, contains many solutions that are already in services, we'll talk a little about this in the video about dockerization.

About micro frontends. Firstly, I have no experience, and secondly, I don't believe that it's possible to manage a zoo of frontends with adequate resources. And in my case, it will not benefit the project or the users.

For the record. I consider such ideas promising, but with the support of browser developers. Which is currently not realistic

Gitlab and Project Structure

I use gitlab in my projects, and I recommend it to you. It has a very cool infrastructure, constantly evolving, and can be self-hosted. The DevOps functionality is incredible.

In gitlab, a lot of functionality is built on project groups. This is really important. So,

1. Create a group with the project name. Everything is simple here, name and private, nothing unnecessary.
2. Create a subgroup for back (the same will be for front). Here is a subgroup, not a project. Because there will be a lot of everything inside, from infrastructure stuff like docker images, to local forks of open source libs, with necessary edits. The same group will be for the front end. This will help to easily manage team access to projects, configure CI CD, add global variables, etc. It's not obvious at first, but believe me, you'll thank for such a structure.
3. Create a project, name it simply "App". Here will be our laravel (or Nuxt) project. Remove the checkboxes for initial Readme and static security tests.

First Commit. Master or Main

Next, follow the instructions in gitlab itself.

Here, please make attention points:

1. Please add information about yourself to git. Solo developers often forget about this, and after them, there's a mess in history.

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

2. The main branch is now "main" not "master". Accept it and use it. It may offend someone, someone who might be your investor. And one more advice here. There shouldn't be anything offensive in git and code, no jokes, no jargon. Commit messages, function names, variables, all of this will eventually be available. Remember how CD Projekt RED labeled everything related to China, or developer's commits on Twich. These are all scandals that waste resources. In general, respect everyone who defends their rights. Even for the branch name. Because those who don't defend them come into my country and die.
3. First commit - clean framework, without edits. Everything else is code, code requires review, project team should be familiar with the code.

And personal advice. You make the first commit personally. I know you really want to delegate this, because it's a 30-second job, but believe me, the average junior without question will dive into the code, because something didn't work on his Windows 98, make some changes, and make the initial commit. And you'll find out about it in a year, cursing the framework, documentation, programming language, and yourself because you chose all of this.

No One Pushes into Main

Setting -> Repository -> Protected branches - Allowed to push and merge set No One

Nobody ever pushes into the main branch (and into stage) without a merge request. Even YOU! Even me. Your team has the right make review, even after the hotfix merge!

Gitlab Secure Feature

Documentation

Gitlab has ready-made presets (templates) with static code analyzers, vulnerability scanners, etc. And it suggested enabling them when creating a project. They're cool, they do a lot of useful things for you. Of course, plug it in. BUT if you have the Ultimate version. For regular users, they are not practically useful or require serious modifications. If you have no Ultimate version, most (if not all) of these features can be implemented manually. In future videos, I will set up some of them.