For example, if I think there is data redundancy, let him streamline it, don't send it all out, and hope that some data can be processed twice. For example, I think there is data redundancy, so let him streamline it, I don't need to send all the data out, but I still want some data to be processed again: this is indeed the simplest and most efficient way for him, I can't see where your odds are ,,,
@ Vczh: The method is invalid because the product dog does not care about the data transmitted by the server, and the requirement changes will only be transmitted to the front-end. Therefore, this programmer's approach is to remain unchanged, he exposes the database directly to you, so unless you need to modify the database, he does not need to modify any code at all, and if you need to modify the database, his modification is also very simple.
In this case, the correct counterargument is to use a massive number of requests to initiate DoS attacks on the server, so that it has to reduce the size of transmitted data and increase the cache to improve performance.
If your DoS does not make the other party lose response, or you do not have such a large amount of traffic, it means that his design is reasonable. This problem is just about the workload distribution of two programmers. You should check it with your superiors.
There must be some reason behind any design principle. architects who leave the scenario principle alone are full of scammers-Ivony. When designing an interface, it is true that there is no need to precisely match the needs of the front-end, so that the interface has a certain degree of universality. If only the fields required by the front-end are returned, the interface must be changed when the front-end display content is added. If the information is formatted as required by the front-end, the interface must be changed when the front-end display mode is changed.
Of course, the minimal interface can save server bandwidth and leave space for scaling and schema changes, which can prevent front-end dependency on internal implementation details.
This is one.
You asked him to minimize the number of interfaces today and change the demand tomorrow. You asked him to increase the number of returned data. How passive are you.
He insisted on returning all the data today. The pressure on the server is too high tomorrow. He asked you to discuss which data can be cut down. How passive he is.
This is the second.
Who works, who has the say, and who is responsible for their decisions. You can fulfill your duty of reminder at most. In the future, he finds that he has made a decision and wants to streamline the interface. You have not increased the workload, and you are basically not even a stakeholder.
Third. Come on, the server programmer is talking.
We need to analyze the specific situation.
1. The server programmer is uncomfortable at work. For example, if it doesn't matter, I will directly SELECT * for you, if there is redundancy or secondary computing, you can do it on the client. This is emotional, and of course it is not Nice enough ~~ But when talking about Nice, isn't someone Nice enough to the server?
2. This API has multiple clients or multiple clients that are called. In order to take care of the versatility, SELECT the API directly to give you the best, and cache the result on the server side so that everyone can call it, the client performs secondary processing. For example, you only need three of the three fields, but others need five fields. How can you choose between them? Of course, I can cache all the results containing five fields. When you call it, I will only return three results for you. However, this will also involve some unpleasant issues (in fact, I really don't think it is necessary, I don't have to worry about emotions )......
I think it is very beautiful to hand over some non-core computing to clients in the hands of the masses ~~ Let the product dog give him a few changes in demand and you will follow his design logic, let him pass the password to the front-end, and then judge whether the login is successful at the front-end. This is not a technical issue at all. If you allow more people to work, they naturally want to resist. It's just an excuse to say anything. If you want to pay overtime for someone else, you can say a little more. Server and client.
Therefore, in my personal experience, finding a superior or looking for a product is meaningless. The key is that you first understand why the other party is doing this. If it was you, would you do that. Both parties are most critical. Don't take the path you think you are right. Useless... People's ideas are undoubtedly correct.
When I am working on the client, I always ask the server to give me the data whenever possible, and then I will analyze it. Unless otherwise difficult, the other party will respond. If you help him, he will help you ..
The so-called development is also dealing with people, unless they are all developed by one person, that is another thing.
The above is relatively false. Let's look at the actual point.
What are the advantages of the majority of evidence?
1. server development is certainly much more convenient, just adding field Subtraction
2. If you don't know, you don't need. Discard unnecessary items. In the future, the server will not need to be moved. You only need to adjust it. Otherwise, the two sides change together. This development cost is not 1 + 1 = 2. It is 1 + 1> 2.
The above said:
Sorry, it's useless. There is no obvious difference between one byte and one byte in DoS. The purpose of DoS is to drag you down without DoS defense. This excuse does not spit anything, so you can get rid of http headers.
Simple and reliable ..
In addition. Mobile client ~~~~ The difference between mobile terminals is very big .. Traffic is money. You can say, "Come on, you don't need to develop it. Let me spell the SQL statement and send it to you"
Haha
--------
Seriously reply:
If there is a place that will affect the program efficiency, there is a service call relationship between you. In this case, if there is data that proves that the server can improve performance and save costs after optimized transmission, it can be refuted-if the boss doesn't think that saving money is more important than getting online quickly, isn't it?
If there is no impact on performance, it can be understood as premature optimization to a certain extent. At this time, the more contradiction lies in the proportional relationship between your workload and salary, I think this problem needs to be solved by superiors.
Then I think it is best to write Chinese for sending a request, such
? "Thank you for your data"
That's it ,,,,,,
