It is known that almost no mobile application is complete without a backend.

If you are a mobile developer, you probably came across such bearded uncles who melancholically pull the logic on a pearl and always write something in the console. Or maybe it was a slouching anime guy with long hair, sucking php with mother's milk.
Anyway, most of them have never come across mobile development, and some consider themselves to be gurus.

Especially for such cases, I prepared a list of harmful tips on how to ruin the backend of your application.

Enjoy reading.
So, if you are a server developer:

• Do not pay attention to the structure of the application , you absolutely should not be concerned with how the product will look to the user. After all, you are not a hipster to think about such things. If the data for one screen should be received through 10 different requests, these are the problems of the designer who drew the interface without coordinating it with your API. Next time, let them not think about the convenience of the user, after all there are more important things in the project.
• Do not write the documentation . A simple vord file on the dropbox will suffice. In the end, your job is streaming data streams, elegant and high-performance. Let helpless mobile developers often turn to you for clarification. A simple list of requests without the slightest examples and descriptions will be quite enough for them. After all, you can always look at your code and see all the parameters and arguments.
• Do not bother with the names of the fields . It is normal that the same entity in different places is called differently, let the field indicating the number of objects be count in one place, and koli4estvo_kek in another. And so it is clear, do not steam?
  And in the sense comes a different data type? Well, yes, in one case a number, and in another a string. What's wrong?
• Change logic without warning . If you are lit up, then do not hesitate - urgently implement. Do not worry about compatibility, do not rush to discuss, just do it. And be sure to roll out the release, then they themselves will understand. Documentation is also not necessary to update, it's all a surrogate.
  
  
  
  
• Do not write tests or check your own API . Remember, you do not make mistakes, it is in the applications that the screens always go and something crashes. And then, to understand that the problem found is still on the backend - it's a matter of a couple of minutes.
• Do not send explanations for errors . First, they are extremely rare. Everything should go perfect. Secondly, everyone understands why something went wrong. A simple http 400 or 500 (the cherry on the cake) should be enough.
• Give answers in different formats . Let somewhere be json, and in another place xml. After all, nature loves variety.
  Quote wonderful people: "And here, too, in json the answer is needed or something?"
• For authorization, use only cookies . You were so taught at the institute when you made your first online store. After all, Android and iOS are just another browser, no need to exaggerate their complexity.
• Remember: no test data , let the developers manually generate all the content. And do not forget to clean the base every day, it only adds excitement to the work.
• Be a rebel : take the parameters in POST via the URL, because this is the same GET, just different. Unleash your imagination. And ignore any prayers of colleagues to bring everything to a standard form, they simply can not think outside the box.
• Take the maximum amount of logic to the client . The server should be as lightweight as possible. Need to do a scheduled newsletter? On the client, let him turn the timer. Aggregation of data from three different sources? Same way. You do not actually have a background thread that can be loaded with impunity.

When I showed this article to my colleagues, many backend developers also decided to share a couple of important moments:

• Do not read the documentation , it is always easier and faster to ask a colleague. Even if you are fifteen people, he will be happy to explain to everyone again.
  ')
  
  (Maybe they just lonely and no one to talk to?)
  
  
• Asking a colleague to remake something in the API, do not explain the reason . If it is not obvious to him, then it makes no sense to explain, he still will not understand.

Useful recommendations

Laughing together at familiar situations is great, but apart from that, I would like to share more effective practices that we use in ourselves. Even when you have to work with external mobile developers, they always thank us for the extremely convenient API and professionalism.

All further tips relate to the backend, but if you are a mobile developer, then it will also be interesting and useful for you to read this. Indeed, in the first place it is you who are interested in changes.

Documentation

This is an interface for a mobile developer. It should be not just informative, but also easy to read and be nice to the eye. It sounds strange, but the easier the document is perceived, the faster and easier it is to work with it, and the less questions arise for you in the process.

The easiest and most convenient option is to use Swagger. Though its initial appearance leaves much to be desired:



But you can easily improve it using the formatter :

It turns out nice and comfortable. Alternatively, you can use Apiary , but you have to separate the code and documentation, which is undesirable, or bother with rendering.

Uniformity

There is complexity in mobile development - many solutions and frameworks are extremely slow. You can not just take and change the format for any one specific request, or it is extremely difficult. As it is impossible to change the name of a specific field only for a specific case: the poor developer will scream in a voice, trying to stick a crutch under it.

Everything should be complete: the same names everywhere, one interaction format (preferably JSON), and so on.

It is especially good if the names of the parameters in the request and response perfectly match the fields of the corresponding classes in the mobile application. It sounds weird, but it makes the life of the developers so simple that they will drag you the chocolates for it from the store.

In some places, simplification comes to the point of absurdity: for example, saving to Realm (mobile database) can be made almost immediately from json. If it is interesting, I’ll tell you separately how we got rid of middleware in a mobile application.

Sample code for saving any incoming objects on iOS:

One generic method for any record in the database from the server. Cool, right?

The same goes for images. Best of all, when the link immediately comes to the picture, which does not need to 'finish'. And according to the same rule - the name of the link should be the same everywhere.

We had a case when it was necessary to search for images in Google for certain information blocks in a mobile application. As a result, we just made a pseudo-link to the image to which the application is accessing, and inside the server it searches for a suitable image in Google and redirects it. And for the application, it looks like the most common piccha, which just takes a little longer to think.

Adequacy

When you work on a server, it’s usual that everything is in the single scope of the request, where it is enough just to open a transaction for writing and push the data into it consistently. Everything is isolated, predictable and linear.

There is no such thing in the mobile application. Everything is spinning asynchronously, and if you need to maintain the integrity of data from different requests, this results in the most complex manipulations with multithreading, infuriating critical sections and the distribution of priorities, so that there is no hint of brakes. No wonder the question about the synchronization of threads in an interview at a mobile developer is one of the first.

Now you understand why mobile developers are trying to ensure that everything comes in a single request? It depends on it, they will go home today or not)

And of course, if you need to load some data asynchronously, then you don’t need to push them into a common heap, you need to understand this.

In the end, do not be lazy to open the design of the application and see what the screen for which you are creating the API consists of. Check with your mobile colleagues, determine how best to give you data and what future requests will depend on them. Maybe in this particular request you need to give a little more information than it seems sufficient. But it will make the subsequent work more convenient and more pleasant on the client. Helping in such trifles, you will be remembered for a long time. And then they will remember with warmth their entire professional life.

In the same paragraph I want to include debug information. If you made a request for a list of comments, then make sure that these comments were there. For you to accumulate the same type of data is a matter of one minute, and for a partner from the mobile department it is a whole exhalation of relief.

Stability

Just a crucial point to which you want to pay attention separately. Always check your API, and even better - let the tests do it for you. Each bug on the backend is ten on the client. Indeed, between the server and the user there are many levels of abstractions, which must be eliminated before blaming the server.

Each bug spends the time of the user, tester, mobile developer, and only then - you. You are responsible for the greatest responsibility, and your mistakes cost the company the most.

As a bonus, I would like to add that it’s great when there is a pretty print, at least for the duration of development. It happens that you need to figure out what came from the server, without looking into the documentation.

And what's nicer to read is:

Or this:

The difference, it seems to me, on the face.
The main thing, do not forget to turn off Pretty Print on the battle server, because it eats resources like not in itself.

Conclusion

I just want everyone to say that the rule is in fact one and quite simple - do not make colleagues grind their teeth from your work.

The next time I plan to talk about how we moved to Go and got rid of a huge piece of business logic on the client, reducing the application binary by more than a third.