1
6 Comments

Performance and coding questions for you all…

Performance and coding questions for you all…

Do you try to minimize the number of requests sent to your backend and the amount of data therein in order to minimize user load times, server load, and data storage costs? Do you come up with complex front-end caching strategies because of it? Is the cost and load-time difference in such a lean model worth the trouble? What would you say is a typical number of requests and size of data sent therein per user for a minute of using your application?

on February 22, 2019
  1. 1

    With HTTP 2 the number of requests is less important than it was in the past. I would say it comes down to your backend. If you have an large overhead for each request in the backend (for example when using PHP and complex bootstrapping is required), you should think about the number of requests.

    Regarding the amount of data, I'm normally sensitive, but do not put much effort in optimizing it in the beginning. Optimization can be done later as soon as it is necessary. However, early optimization might be worth the effort if your users primarily use their smartphones to use your application or are in countries where just slow Internet is available.

    A normal number of requests and size of data is hard to define without knowing your type of application.

  2. 1

    Do you try to minimize the number of requests sent to your backend and the amount of data therein in order to minimize user load times, server load, and data storage costs?

    There are way too many variables at play to give you an accurate answer without knowing the specifics of your setup.

    However, in general, keeping the user facing application lightweight allows faster render/download speeds for both mobile and front-end web applications. Note that the vast majority of new projects aren't running on custom hardware. Instead, they are utilizing GCP/AWS/Azure and the like, which normally come setup by default with auto scaling instances.

    Do you come up with complex front-end caching strategies because of it?
    Depending on the application, caching data in some way on the front-end is common practice. For example, an email application might cache previously received emails and perform a diff upon the user refreshing, only rendering and caching any messages not already received.

    Be careful not to sink too much time into premature optimization.

  3. 1

    PostgreSGL can handle enough traffic.

    1. 1

      oh i am actually asking people what their experience is. Do you have metrics on the average number of requests and size of data sent therein per user for a minute of using your application?

  4. 1

    Architecture and concurrent users should be stated to answer this question.

    1. 1

      Oh I edited the question to say per user; thanks! The architecture I have in mind is just a RESTful API with a postgresql db.