We are trying to write a project alone. Introduction
After working for several years in backend development, which, in fact, is the conversion of SQL to JSON and vice versa, documentation, writing tests and other chores, I began to feel burnout (and this is about 20). Fortunately, the situation was such that in the current work I had to tinker with the front-end, which delayed me and I started the next project on Angular 2.
The tale did not last long, plunging into the world of the 2017-year development frontend, I wilted my head even more with all of these reactors, RN, vue, sass, webpack and other redaks . After completing a few more projects with less and less motivation, although on interesting technologies (Node.JS, GraphQL, Docker) I realized that I can’t psychologically linger on the current place of work and changed it.
Unfortunately (or fortunately), I didn’t grow together in a new place (even despite a good salary level and a team of professionals) and I didn’t linger for a long time. After the dismissal he took a couple of months to rest, think.
For some time I had the opportunity to live abroad, and there often used a popular service for “mitaps”, but it always seemed like “heavy”, I wanted something simpler - like Tinder, but for everyday activities. So I began to slowly think about writing the project itself.
There were the following conditions:
At first glance, my imaginary project was ideally suited for these restrictions. No work with money was required, the data should have been at a minimum and a bonus - I was free to choose technologies. Take it and do it.
Being a realist (and on the spectrum an optimist-pessimist is more likely to be the second), I sensibly estimated (th) the chances of “projecting” the project financially and always considered start-ups as a kind of gambling. God forbid one shoot out of a hundred, i.e. will give its creator financial independence for N years.
With the same success, you can put a two-month salary (it will take about so much time to write a simple MVP) to zero at the roulette table and with a 2.7% chance to forget about working for 6 years (at the same expenses). In fact, I'm not sure that even a single startup of hundreds shoots, which makes roulette not such a bad alternative. (this is of course a joke)
On the other hand, even if the project does not take off, you can drank it apart, put it in open source, write a couple of articles on Habr, and the practical experience will not go anywhere - in the end, your hourly rate will increase and you will get more money than your colleagues sitting quietly in the office.
Do not forget that the work on your project flies much nicer than the routine closure of tasks in JIRA or Redmine.
Well, finally, the most interesting. A typical modern web project consists of the following parts:
Mobile . Here, for a solo developer, the choice is small, the immediate disappears immediately, there remain cross-platform solutions. Having already had experience with RN, I made a choice on Flutter, it is still damp, but so far (and if) I will go to the product ... In general, the choice has been made, the technology is fresh, interesting.
Web . Then I decided to cut corners and provide a simple landing page with links to stor, where you can download applications.
Container orchestration, cluster, fault tolerance, monitoring, logging. No options Kubernetes (along with Prometheus, etc.).
Docker Swarm is dead, and k8s has a huge community, easy-to-read source code, lots of tools. Working with a cluster, at least for a small project, is a pleasure. Not the last role was played by the report of D. Stolyarov on k8s .
Back-end . The name for the experience of the spring, using it. In addition, some separate high-performance services (such as chat), I want to write on Go. All this will be tightly integrated with native components of k8s (LB, service discovery).
Gitlab CI was chosen as the CI / CD tool - there is everything from tickets and milestones to integration with k8s and local docker repository. This will be a key tool throughout the development.
Despite the presence of only one person on the project, it is not excluded that, for example, a freelancer can connect, so an easy entry should be provided for the “beginner”
Tasks are scattered on milestones, progress is updated, there is necessary information in the task. All for an adult. Yes, and very nice, you can see both WIP (work in progress) and completed tasks.
This post, of course, is not the only and not the last. The following entries will describe the difficulties that I have already encountered in the course of implementation - the material has accumulated for several posts - and with what else it will have to.
It is worth adding that I deliberately do not give information either on the specifics of the application or on the business tasks that it solves. The main purpose of the series of posts is to answer the question - is it possible to write a modern 3-tier application with a streamlined ci / cd by a single mediocre [backend] programmer.
The closer the series comes to an end, the more specificity will be given on the application, and in the final post of the series (if there is enough “fuel” to finish everything) - links, screenshots and results.
In the next posts - we will analyze the great and terrible Kubernetes, as well as partially Gitlab CI.
The tale did not last long, plunging into the world of the 2017-year development frontend, I wilted my head even more with all of these reactors, RN, vue, sass, webpack and other redaks . After completing a few more projects with less and less motivation, although on interesting technologies (Node.JS, GraphQL, Docker) I realized that I can’t psychologically linger on the current place of work and changed it.
Unfortunately (or fortunately), I didn’t grow together in a new place (even despite a good salary level and a team of professionals) and I didn’t linger for a long time. After the dismissal he took a couple of months to rest, think.
Reflections
For some time I had the opportunity to live abroad, and there often used a popular service for “mitaps”, but it always seemed like “heavy”, I wanted something simpler - like Tinder, but for everyday activities. So I began to slowly think about writing the project itself.
There were the following conditions:
- no sensitive data
- no work with payment systems
- minimum hosting costs
- that the project “self-cleaning” and live its life with minimal intervention from me
At first glance, my imaginary project was ideally suited for these restrictions. No work with money was required, the data should have been at a minimum and a bonus - I was free to choose technologies. Take it and do it.
Being a realist (and on the spectrum an optimist-pessimist is more likely to be the second), I sensibly estimated (th) the chances of “projecting” the project financially and always considered start-ups as a kind of gambling. God forbid one shoot out of a hundred, i.e. will give its creator financial independence for N years.
With the same success, you can put a two-month salary (it will take about so much time to write a simple MVP) to zero at the roulette table and with a 2.7% chance to forget about working for 6 years (at the same expenses). In fact, I'm not sure that even a single startup of hundreds shoots, which makes roulette not such a bad alternative. (this is of course a joke)
On the other hand, even if the project does not take off, you can drank it apart, put it in open source, write a couple of articles on Habr, and the practical experience will not go anywhere - in the end, your hourly rate will increase and you will get more money than your colleagues sitting quietly in the office.
Do not forget that the work on your project flies much nicer than the routine closure of tasks in JIRA or Redmine.
Go to the implementation
Well, finally, the most interesting. A typical modern web project consists of the following parts:
Mobile . Here, for a solo developer, the choice is small, the immediate disappears immediately, there remain cross-platform solutions. Having already had experience with RN, I made a choice on Flutter, it is still damp, but so far (and if) I will go to the product ... In general, the choice has been made, the technology is fresh, interesting.
Web . Then I decided to cut corners and provide a simple landing page with links to stor, where you can download applications.
Container orchestration, cluster, fault tolerance, monitoring, logging. No options Kubernetes (along with Prometheus, etc.).
Docker Swarm is dead, and k8s has a huge community, easy-to-read source code, lots of tools. Working with a cluster, at least for a small project, is a pleasure. Not the last role was played by the report of D. Stolyarov on k8s .
Back-end . The name for the experience of the spring, using it. In addition, some separate high-performance services (such as chat), I want to write on Go. All this will be tightly integrated with native components of k8s (LB, service discovery).
Gitlab CI was chosen as the CI / CD tool - there is everything from tickets and milestones to integration with k8s and local docker repository. This will be a key tool throughout the development.
Despite the presence of only one person on the project, it is not excluded that, for example, a freelancer can connect, so an easy entry should be provided for the “beginner”
Tasks are scattered on milestones, progress is updated, there is necessary information in the task. All for an adult. Yes, and very nice, you can see both WIP (work in progress) and completed tasks.
Future
This post, of course, is not the only and not the last. The following entries will describe the difficulties that I have already encountered in the course of implementation - the material has accumulated for several posts - and with what else it will have to.
It is worth adding that I deliberately do not give information either on the specifics of the application or on the business tasks that it solves. The main purpose of the series of posts is to answer the question - is it possible to write a modern 3-tier application with a streamlined ci / cd by a single mediocre [backend] programmer.
The closer the series comes to an end, the more specificity will be given on the application, and in the final post of the series (if there is enough “fuel” to finish everything) - links, screenshots and results.
In the next posts - we will analyze the great and terrible Kubernetes, as well as partially Gitlab CI.
Source: https://habr.com/ru/post/439820/