How I did a social network in 2019

In this article I will tell you how I made my project of a social network for the havidea.ru art sphere from idea to release. I’ll tell you about the technical part, about motivation and self-organization, what tools I use in the development process, about the problems in working with the field of art that I encountered almost immediately after launch. The project survived reincarnation, i.e. was the first option that I abandoned and the final, the second , which went into release.

I have been working in the field of web development for a little over three years. The project was raised alone in his spare time from the main work and the main goal was to release the product on time (6 months).

Inspiration, idea, research

As a teenager, I began to get involved in music, painting. A little later he caught fire with 3D graphics and even managed to earn the first penny on 3D models. A couple of years later, I seriously took up photography and video and in the same period met vocal lessons (and this was in my life, yes) with my future wife - an actress. All this prompted to make some kind of project to support the “funny” destinies of creative people. III? Social network? Why not? But this is heytat, they say, social. networks are dying. Someone die, but I can do it, right? And in general, if there is a sound idea and concept, why not translate it into a web page? Googling the list of social accounts, I came across an interesting option - stage32. In my opinion, this is the only serious foreign platform that gathered the community involved in film production. In Russia, at that time (early 2017), I did not find any analogues (was I looking badly?). It is resolved. I will make my service, based on the best images, practices and UX of existing social networks. networks, but with a bias towards the sphere of theater, cinema and art in general.

Project ideology

Non-profit, without advertising, the most useful for the participants themselves. Free, no tracking, no metrics. Protecting user data.

First option (2017)

Any project should begin with posing and answering questions: for whom? For what? What problem does this solve (goal)? What are the alternatives? What benefits can be offered? After clear and concise answers, I make a list of the functionality of the future project. Next, I decide with the skeleton: I remove all Wishlist and fantasies from the general list of functionality and leave only the most necessary - something without which the application will not function. From the minimum functionality I select a stack. I am looking for examples of implementation. At this stage, there is already a big picture: what to do, why and how. I write down the whole process, comments and thoughts in a notebook so as not to repeatedly decide what I had previously refused.

I start designing a UI with a piece of paper and a pencil. Any leaf that is at hand goes into action until the thought runs away. I decide on the pages and conduct the second rough iteration already in electronic form (it’s easier to change something):


Next, I study the sketches in detail. Here, for example, is the very first version of the profile page:


Posts, comments, likes, an album with photos - all in a classic. From the new: an
expanded profile for actors, a search for professions and skills.

For layout layout I used modulargrid.org :


I experimented with 12, 15 column grids, but stopped at 12. I want to note that layout on a modular grid is an ambiguous thing. You will not always be able to enter information into blocks, because interfaces are a graphical representation of data. I proceed from the principles of Data-Driven design, i.e. The main purpose of interfaces is to present data and convenient options for interacting with them. That is why the designer! = Web designer. Returning to the problem of a modular grid, I will say that it only helps in the initial arrangement of the blocks, and the final version should be confirmed with the help of a trained eye. In addition, in any entity there should be a twist or departure from the rules to add liveliness.

A couple of drafts of the main page:



Some solutions do not look very successful and are removed / corrected during layout. At the design stage, you need to give yourself freedom and not bring everything to the ideal.

Login Page:


After sketches of the desktop version, I pay attention to mobile. Is the graphic part ready? Normas. It's time to code.

Frontend first option.

As a background for the main page, I used the Three.js library to work with WebGL. Triangles float freely and “follow” the mouse. Looking ahead, I’ll say that in reincarnation I refused Three.js and did it on css + png, because the library weighs ~ 570kb and it seemed wasteful to use it for one simple effect. In development, I adhere to the settings: minimalism, performance, ease of support. Since social networks use about 3/4 from mobile, priority was given to lightness and speed. How the library of UI components took Bootstrap 4. Without jquery, only css. I tried bootstrap-vue wrapper but somehow it didn't work. Invalid html tags were striking and wanted freedom of customization. As you might have guessed, the Vue framework . I wanted to initially lay good indexing by search engines, so I screwed up Nuxt .

Backend of the first option.

Laravel . For one-man projects, vue + laravel = must have. Development speed, a large community, a bunch of ready-made packages. API-first architecture (backend originally developed as an API).
What API without documentation? Apidocgreat thing that can generate documentation from PHPDoc. Routing customized and rendered routing files from a single api.php, i.e. one file, one route. For convenience and to generate documentation. I took inspiration from Apiato . A good starter kit for the API, stuffed with different design patterns and the original architectural Porto , designed to break the application into modules, but essentially leading to a monolith. Judging by the repository, the project was abandoned more than a year ago. Most likely, due to the active spread of microservice architecture.

Rest, leveling skills

It was 2018. In the first version, I managed to implement registration, authentication, profile page with editing, settings page. There was not much time in the evenings. Then I just started the vue path, and ssr on nuxt was naughty. As a result, after 4-5 months it was blown away. It was an ambitious project and there wasn’t enough skill to lift it, without falling yourself. For 2018, I pulled myself up as a full stack developer, mastered docker and at the beginning of 2019 started from scratch. Well, almost from scratch.

Second option (2019), release

Frontend of the second option.

I refused nuxt ssr - the layer from node.js requires additional attention, and I did not see the need for it specifically on this project. Bootstrap replaced Quasar - a full-fledged vue UI (and not only) framework (why I took it I will tell below). Interfaces completely redone, left the vk-style concept. Now insta-style. Added the ability to create three types of publications: photo, video and text. In the layout I used 24 column grid. Now the service looks like this:


Yes, you can make the top menu transparent. But you need to know how to say "no." I eventually drew the main page again. Therefore, you should not go into details before the full picture. Sooner or later you will want to change everything and it doesn’t matter how wonderful the decision was. Of course, the site is fully adapted:


About TypeScript. I tried to implement it, but later cut it out, because strict typing requires more time for arranging types and interfaces. I came to the conclusion that TS without strict mode does not make sense. It is true - why typing without specifying types. In strict mode, you have to describe absolutely everything and this is at least + 30% of the development period. And if you have not approved the scheme for exchanging data with the backend, you will have to constantly be distracted by minor edits. In some places you will need to ignore compiler errors by adding the @ ts-ignore comment to the code just because you are not responsible for third-party code that does not fully support TS. In addition, all the benefits of TS are revealed in complex logical calculations, i.e. typing .vue files is somewhat redundant. I would be glad to hear comments on this topic.

When the front was 90% ready, I wrapped Browserstack and tested the application on Safari. I do not regret the money spent, because I managed to fix a couple of simple but critical bugs. Minute bomboleilo. Safari, when will you start thinking about users and developers? Do not fix bugs for years. Especially sticky scroll in modal. I did not find a 100% working way on how to get Safari to correctly scroll content in a modal window. I would be glad if anyone came across and tell me a solution.

In addition to the main application, I also made a simple admin panel with my api:


There is nothing remarkable in the admin panel. Just a UI coverage for some features, because of which it is too lazy to go into the database and edit data by hand.

Backend of the second option.

Laravel . Mandatory validation of all incoming data, cors headers, additional secure-headers security headers , following RESTful specifications (I’ll try JSON-RPC somehow), Fractal to transform the returned data to the front. Try-catch everything so that the user does not press the mouse, but gets a clear reason for the error. Automatic dumps of both databases using db-dumper . I did not write any automated testing, because it is limited in time. Got to pump up and try TDD, it may turn out not to significantly increase the development time or even reduce it.

Separately, I want to say that I avoid the use of abstractions in the initial stages of design, if now you can do without them . Their premature use complicates the application module, which can never be used. Solve problems as they become available. Yes, striking a balance between architecture and timing is not easy and it comes only with experience, but it is better to spend time thinking through the database, and you can rewrite the application code at any time. The most important resource we have is time. It is better to release a non-ideal product and be the first than then to catch up with competitors. And they will be.

Problem, stagnation

The launch took place at the end of May. I started advertising and almost immediately came across a similar service. Yes, they essentially implemented the same idea. 2 years earlier. It was better to research the market and constantly monitor it for new services. But the problem is not even that. In the process of discussion, reflection and just life experience, I came to the conclusion that the problem of the employment of people of art is much deeper and, perhaps, a specialized social network cannot help. This is a market problem of job shortages. In which direction to develop the product I do not know exactly. Now the project is experiencing stagnation.

Under the hood

Total

Despite the current situation with my ideas about the peculiarities of the art market, I do not regret a few hundred hours spent. The process was fascinating, gave a lot of experience and not only programmer. I made the service as I intended and proud of the final implementation. I was driven by the belief that I could help creative people. This was the main motivation. Maybe the initial non-profit approach put the project in a difficult position? There is a (controversial) opinion that one needs to start a business or nothing. It is sad, but sometimes it’s better to stop in time than to do what you do not believe in. If a new understanding comes in which direction to move, then I will continue to develop. I will be flattered by your opinions.