As more and more companies in China begin to use Vue to develop SPAs, the original front-end and back-end coupled mode where user permissions and other logic were controlled by the back-end has changed. With SPAs, authentication strategies need to be implemented by both front-end and back-end together.

In our business, we often need to develop daemon services, especially with the rise of compiled languages like Golang and Rust. However, they don’t provide process management like C language does. By default, the compiled files can only run in the foreground. So today, let’s learn how to manage these daemon processes through Systemd.

Systemd is a collection of system initialization (init) programs and basic components for Linux, developed by a team led by Lennart Poettering and released as open source under the LGPL 2.1 and later licenses. Currently, Systemd has been incorporated into the software repositories of many Linux distributions.

Previously, we manually SSH’d into remote servers to add configuration files for projects. Some developers, for convenience, committed sensitive configuration information to Git repositories, leading to server information leaks.

When your team doesn’t have an independent document management system, you can use Gitlab’s Pages service to publish project documentation or demonstration pages. You only need to modify some configuration files to enable this feature.

As monolithic applications grow increasingly large, we are compelled to break them down into microservices. But this raises the question - how do we manage these services? Consul was born to solve this problem!

Previously, I found the Seeder provided by Laravel very convenient. This is where Seeder comes in handy, allowing for quick population of essential system data such as menus, permissions, etc.

Are you still using the traditional manual method of SSH into your production server and executing a series of deployment commands? Try Gitlab Runner, it will free your hands, and you only need to focus on writing code.

After setting up a new Gitlab server and creating a test project, I noticed that each commit triggers a job that always fails. This not only looks uncomfortable but also affects certain statistics.

For many teams, internal projects are preferred to be hosted in the company’s internal environment. Based on this requirement, today I’ll share how to quickly set up a Gitlab server using Docker.