Frudy
5k
2020-10-13 19:33:04 작성 2020-10-13 19:35:26 수정됨
44
3550

이 경우 api콜은 몇번을 하는게 합리적일까요?



예시가 되어줄 관리자 페이지에요. 


조건은 이렇습니다.


* 페이지이름 : 회원관리 페이지

* 기능

1. 회원목록 출력

2. 최근 30일간 회원 누적 접속자 같은거 볼수있는 차트형식의 아무거나.


페이지 하나에 2가지 종류의 데이터가 필요해요. 

회원리스트와, 30일간 차트를 뿌리기위해 필요한 리스트 데이터요.


문제)

해당 페이지가 로딩됬을 때,


방법1.

회원리스트, 차트데이터리스트 2개를 한번의 api call로 받아온다.


방법2.

회원리스트 한번, 차트데이터리스트 한번, 총 2번의 api call로 받아온다.


저는, 방법1이 합리적이라고 판단했고,

저희회사 팀장님은 방법2가 합리적이라고 판단했습니다.


저의 근거는,

http요청수는 최대한 줄이는게 맞다. 에요.


심지어 저 경우에는 DB 커넥션 두번해야해요.

회원리스트 한번 조회하고,

차트데이터리스트 때문에 한번 또 조회해야해요.


팀장님의 근거는,

저걸 두개의 api로 분리하지않고 합쳐놓으면

회원목록만 필요한 경우에 api 또 새로 만들어야하고,

차트데이터리스트만 필요한경우에 api를 또 새로 만들어야 한다 에요.


양측 다 나름대로의 근거가 있습니다.


실제로 회원목록 보여주는기능에서 회원이름이나 회원 이메일로 검색하는 api도 필요하거든요.

응답값은 검색된 회원목록이죠.


이걸 두 api를 분리하지않을경우,

회원목록 api하나, 회원목록 + 차트데이터리스트 api 하나, 차트 리스트 데이터 api 하나 총 3개가 필요하거든요.



저는 여기서 한가지 더 근거가 있습니다.

제 방법 : api 3개필요 (회원하나, 차트하나, 회원+차트 하나 총 3개)

팀장님방법 : api 2개필요 (회원하나, 차트하나)


api가 하나 더 늘어나면, 유지보수해야하는게 하나 더 늘어나는건 맞습니다만,


"유지보수 해야하는 게 늘어나는 것 보다 중요한 것"이 있다고 생각해요.

바로 성능이에요.


제 방법은, http 요청수가 줄어들고, DB 커넥션 횟수가 줄어들잖아요.


하지만 저는 초보이기때문에... 제 판단 과정중 잘못된 부분이 있다면 짚어주시어요.

어제 https://okky.kr/article/794258

이런 글도 보기도 했고.. 마침 저도 겪어서.. 이거 정말 궁금한 의문이에요.


양측 다 맞는 이유를 몇개 제시 못했는데,

서로 장단점을 좀 더 알려주시면 감사합니다. 

(저는 생각나는게 저거뿐이였어요...ㅜㅜ)

4
  • 댓글 44

  • 송자바TV
    99
    2020-10-13 19:47:42
    글쓴이분이 생각하신 의견에 한표드려요,

    한화면유 출력하는데 
    Api요청은 왠만하면 한번에 가져오는게 속도가 좋아요
    필요한 파라메터와 응답값만 정해서.
    서비스에서 db호출할때도 최소한의 커넥션으로 데이터를 가공하고 뽑아내는게 좋습니다.

    기존 개발코드 서비스 레벨에 각각 분리해개발해놓았다면,
    나중에 분리가 필요하다면
    Api 컨트롤러에 url과 메소드만 추가하면되요.

    상황에 따라 예외도있지만 최소한의 커넥션으로 하는게 좋다고 봐요
  • Frudy
    5k
    2020-10-13 19:58:49

    한가지 더 여쭤볼게 있어요.


    분명히 개발자들이라면,

    제 방법에 대한 단점이 있기 때문에,

    이 단점을 또 해결한 개선된 방법이 분명 있을거같은데,


    이에대해 아시는거 있으세요?


    이런 단점을 아무도 해결하지못했을리가없는데...

  • 히히히하하하
    70
    2020-10-13 19:59:00 작성 2020-10-13 20:01:27 수정됨

    저는 주니어이지만.. 팀장님의 의견에 한표드려요!

    함수를 만들 때 최대한 작게 만들고 하나의 일만 해야한다는 원칙처럼 API도 그렇게 작성해야한다고 생

    각해요.

    물론 한번에 모든 데이터를 가져오면 좋지만 그 API는 이제 그 화면에 종속된 API(그 화면에만 쓸수 있는

    API)가 될겁니다. 그리고 관리자 페이지에서는 성능보단 유지보수가 더 중요하다고 생각합니다. 꼬꼬마

    주니어 개발자 의견이니 틀릴수도 있습니다^^,,,

  • ISA
    2k
    2020-10-13 20:08:34 작성 2020-10-13 20:09:11 수정됨

    2번, 데이터 요청수가 줄어든다 한들 패킷 량은 동일하고 오히려 비동기로 동시에 받아와서 사용자 입장에선 더 빠를 수 있습니다.

    Db 커넥션 관련한 이슈는 dbms마다 다르고 트랜잭션 문제가 아니며 mysql 쓰신다면 고려할 가치가 없습니다 mysql은 커넥션 관리가 매우 잘되는 특징을 가지고 있기에 오히려 커넥션 수를 늘려서 설계해 성능을 끌어올리는 경우가 있을 정도로 특이한 개성을 가집니다.

    그 외 여러 이점이 있으나 지금 상황에서는 모르셔도 될거 같군요.

  • Frudy
    5k
    2020-10-13 20:08:59

    아니에요 사실 누가 맞는지는 딱히 중요하지않아요.

    장단점에 대해 서로 논하면서 해당 문제에 대해 좀더 깊이 생각해볼 수 있는 기회죠.


    관리자 페이지에서는 성능보단 유지보수가 더 중요하다고 생각합니다.

    //

    이부분은 저도 솔깃하네요.


    "유지보수 해야할게 늘어나는 것"

    >

    성능

    >

    관리자 페이지는 딱히 성능안중요


    답변자님 말만 들었을 때는, 경우에따라 답변자님 말이 더 합리적이네요.


    성능이 더 중요하지만 관리자 페이지는

    성능보다 유지보수할거 줄이고 좀더 빨리 개발하는게 중요한 경우도 있을지두 모르겠네요.


    의견 감사합니다. 그부분은 생각하지못했어요.

  • Frudy
    5k
    2020-10-13 20:11:51 작성 2020-10-13 20:13:00 수정됨

    ISA


    오히려 비동기로 동시에 받아와서 사용자 입장에선 더 빠를 수 있습니다.

    //

    아..네 맞네요 그렇네요?

    이부분은 프론트앤드 개발자로써 꼭 알아야했었네요. 감사합니다.


    나머지 답변은 백엔드 개발 공부할 때 필요하겠네요. 감사합니다. 이부분은 메모해놓을게요.


    문득 생각해보니

    막연히 왜 http요청수를 줄이면 좋은지 잘 모르고 주장을 펼첬었네요.

    이부분에 대해서도 생각할 기회가 생겼네요. 감사합니다.

  • 돈까스
    4k
    2020-10-13 20:13:37

    방법2가 낫습니다.

    동일한 데이터를 2번 호출한다면 문제이지만, 서로 다른 데이터는 따로 호출하는 게 낫습니다.

    그 커넥션 2개를 한개로 바꾼다고 한들 성능이 얼마나 빨라질까요?


    그리고 다른 측면으로 생각해보시죠.

    그 DB 커넥션 한개를 순차적으로 조회해서 한번에 2개의 데이터를 가져와 화면에 그리는 것과

    서로 독립된 쓰레드로 동시에 조회해서 빨리 조회된 것을 먼저 UI에 뿌리는 것 중에 어느쪽이 사용자가 느끼기에 반응이 빠르다고 느낄까요?


    정답은 없습니다. 규모나 API의 형태 사용 패턴 등을 보고 해야 하겠죠.

    그렇기 때문에 웬만해서 성능은 가장 나중에 생각하세요.

    성능을 튜닝하는 방법은 굉장히 많이 있습니다.

    그런 방법을 잘 쓰기 위해서는 서로 관련이 없는 기능들은 다 쪼개져 있을수록 좋습니다.

    개별적으로 튜닝을 해서 효과를 보기 좋으니까요.


    그리고 쪼개져 있는 걸 합치는 것은 합쳐져 있는 걸 쪼개는 것보다 쉽습니다.

  • Frudy
    5k
    2020-10-13 20:18:58 작성 2020-10-13 20:21:27 수정됨

    돈까스

    자세한 답변 정말 감사해요.

    알려주신 내용 토대로 공부하는데 참고할게요.


    그리고,


    성능을 튜닝하는 방법은 굉장히 많이 있습니다.

    //

    이부분에 대해,


    성능이 중요하니까 제 방법이 좋다. 라는 논리를 적었는데

    다른 방법으로 더 좋은 성능을 내는 방법이 없을까,

    무슨 근거로 내 방법이 더 좋은성능을 낼수 있다고 생각하는걸까, 

    기타등등 왜 이런 질문을 스스로 못던졌는지 돌이켜보게 되네요.


    얻어갈게 많은 답변입니다. 감사합니다.

  • 후니
    1k
    2020-10-13 20:53:39

    좋은 질문, 좋은 답변들 엄지척

  • 송자바TV
    99
    2020-10-13 21:03:33

    @Frudy

    단점이 없어보입니다.

    개발하실 때 성능을 고려하시면서 개발을 하신다는게 좋아보입니다.


    요구사항이 어떻게 되있는지는 모르겠지만

    만약 요구사항이 검색조건 상관없이 통계는 최초1번만 가져오면 된다라는 과정이라면


    최초에 접속시에만  회원목록 + 통계 합쳐진 API(1) 를 콜해서 데이터를 바인딩처리하면 되구요,

    회원목록 검색 또는 페이지 번호 바뀔 시 회원목록 조회 API(2) 를 타게 처리하면 됩니다.


    예시 api url.


    1. /api/user/totalList (회원목록 + 통계)

    2. /api/user/list (회원목록)


    데이터 바인딩하는부분은 둘다 상황에서 쓸 수 있게 method를 쪼개 놓으시면 되구요,

    jstl이든, vuejs, react, jquery든 모듈화 해놓으면 같이 사용할 수 있습니다.


    참고로 개인적으로 일을 처리할때 좀더 효율적으로 개발을 할려고 사용했던 패턴을 적어드린것이며,

    참고만 하시면 될것같습니다.

  • 최심바
    201
    2020-10-14 00:21:26

    2번이요!

    서로 다른 기능이라면 분리하는 것이 유지보수나 기능확장 측면에서도 좋습니다.

    회원리스트 조회라는 기능으로 추측해보면, 내부시스템일 가능성이 있어 보이네요.

    그렇다면 트래픽은 많지 않을 것이니 성능은 크게 문제 없을 겁니다.


    각 API의 처리속도가 어느정도 인지는 잘 모르겠습니다만,

    아무래도 회원리스트 보다는 차트에 사용될 30일간의 데이터를 처리하는 것이 더 오래 걸릴 것 같아 보이네요.

    그게 맞다면, 윗분들께서 말씀주신 대로 비동기로 처리하는 것이 좋아 보입니다.

    회원리스트가 굳이 더 오래 걸리는 차트데이터를 기다릴 필요는 없으니까요 :)


    그리고 DB커넥션(DB요청횟수?)은 두가지 방법 다 동일하지 않나요?

    서로 성격이 다른 데이터로 보여서요, API를 통합한다 해도 두번 조회를 해야 하지 않나 싶습니다. ^^;



  • Frudy
    5k
    2020-10-14 08:57:03

    회원리스트 조회라는 기능으로 추측해보면, 내부시스템일 가능성이 있어 보이네요.

    그렇다면 트래픽은 많지 않을 것이니 성능은 크게 문제 없을 겁니다.

    ㅡㅡ

    오......


    서로 다른 기능이라면 분리하는 것이

    ㅡㅡㅡ

    오....


    전혀 생각하지못한 부분들이에요.

    답변자님 실력 좋으시네요.

    감사합니다.


    커넥션부분은,

    조인으로 안되는게 없는줄알았는데

    제가 조인잘모르고 한 소리였어요.

    그부분은 제잘못이에요.

  • 욥욥욥
    925
    2020-10-14 09:06:08

    팀장님이 그래도 인내와 기다림(?)을 아시는 분 같네요 ㅎㅎ

    전 2번 한표요.

    db 커넥션은 좀 잘못된 표현 같아요.

    어지간하면 풀을 사용하기 때문에 쿼리 요청이 두번 간다고 하는게 맞아보입니다.

    유지보수도 장기적으로 2번이 나아보이고

    성능 문제는 상상만으로 대화하면 끝이 안나요.

    이런건 jmeter 같은 걸로 충분합니다.

    테스트로 데이터 비교하면 끝이에요.

    1번으로 하셔도 큰문제는 없어요.

    납득 안가시면 생각하시는데로 하시고 고민해보시면 될것같아요 나중에 쪼개면 그만입니다.

    계속 고민하고 의심하면서 좋은 개발자로 성장하시길 빕니다.

  • daywalker
    842
    2020-10-14 09:13:58

     추후에 회원 데이터가 많아질 경우에 대한 생각도 해야겠네요.

    그리고 회원 목록에 다른 테이블을 조인해서 가져와야 될 경우가 생길수도 있구요.


    API를 적은횟수로 호출하는것도 좋지만 기능을 잘 구분해서 만드는것도 중요하다고 봅니다.


  • HJOW
    1k
    2020-10-14 09:35:27

    이런 문제 때문에 GrapeSQL 이 나왔을겁니다.

    업무에서 사용하는 DB 테이블들을 GrapeSQL 에 연동시켜놓고

    화면개발할 때, 저게 다 필요한 정보다 라고 하면, GrapeSQL 문법에 맞게 필요한 정보들을 요청하면 됩니다.

  • HOngSnail
    125
    2020-10-14 09:48:48

    잘보고갑니드아

  • 정교니
    1k
    2020-10-14 09:59:19

    정말 오래간만에 좋은 질문과 좋은 답변들인거 같네요

    저도 잘 배우고 갑니다 ㅎ

  • 사자카로스
    997
    2020-10-14 10:39:57

    1번으로 한들 db접근이 줄어들진 않을거 같습니다.

    쿼리로 다 조인해서 가져올거면 그거야말로 헬 오브 헬이죠.

    1번으로 구현한다면 조인보단 facade 레이어를 두는 방향으로 처리할거 같네요.

    화면 중심으로 Api를 설계했으면 1번, restful형태라면 2번 선택할거같아요.

  • mirheeoj
    11k
    2020-10-14 11:16:33

    api 3개필요 (회원하나, 차트하나, 회원+차트 하나 총 3개)

    api 2개필요 (회원하나, 차트하나)

    이 계산은 기능이 두 가지일때에만 해당합니다. 만약 기능이 더 추가되면 경우의 수가 크게 늘어납니다. 

    예를 들어 기본 기능이 A, B, C라고 하면 각각의 API에다가 AB, BC, AC, ABC가 추가돼야 합니다. 기본 기능이 A, B, C, D라고 하면 훨씬 더 복잡해짐은 자명하고요. 

    물론 AB, BC, AC, ABC가 전부 필요하진 않을 수도 있습니다. 아마 대부분 그렇겠지요. 그런데 이걸 미리 판단하는 것도 쉽지 않은 일입니다. 미래에 어떤 일이 생길지 모르니까요.  

    ---

    저라면 반드시 꼭 그렇게만 해결해야 하는 이유가 생기기 전까지는 1은 생각하지 않을 것 같네요. 


  • 뒷집할머니
    1k
    2020-10-14 12:04:23

    2번


    성능이 크리티컬하게 차이 나지 않는 한

    로직이 간단한게 유지보수에도 좋음

  • 초무쿤
    5k
    2020-10-14 12:29:51

    2번유.

  • 마르세유1
    1k
    2020-10-14 15:33:22

    2번요. 설명은 다 작성해놓으셨네요.

    api콜 몇번 줄인다고 성능차이 별로 안납니다...

  • Jaccobby
    126
    2020-10-14 15:53:34

    2번에 한 표 던집니다.

    유지보수성이 더 중요한 것 같아보이기 때문입니다.

    글에서 말하는 논지와는 벗어난 감이 있지만, 클라이언트 개발까지 고려하면 확실히 2번이 더 좋아보인다는 생각이 듭니다.

    데이터 속성자체가 누적 데이터라 어차피 실시간 데이터가 아닙니다. 때문에 저보고 성능을 올리라고 하면 차라리 클라이언트 캐싱을 선택할 것 같습니다. 

    예를 들어 일단위로 eviction 한다고 하면, 

    클라이언트에서는 하루에 한번만 요청하고 이후에는 아예 http call 없이 데이터를 그릴 수 있겠쥬.

  • kamy
    86
    2020-10-14 16:48:46

    퍼포먼스를 중요하게 다룰거면 해당 퍼포먼스가 중요하게 다뤄지는 상황인지 먼저 고려를 해야죠

    관리자 페이지는 소수의 관리자 인원들만 보게 되는거인데, 거기서 성능을 따진다? 불필요한 논쟁입니다

    게다가 무슨 api콜 n번하냐 n+1번하냐로 따지고 있는데....

    저렇게 묶여있는 api를 만들기 위해서 서버 작업자가 다시 작업해야 하는 로드를 생각해보면, 이런 성능 이슈는 사소하게 느껴질거같네요

  • Frudy
    5k
    2020-10-14 20:19:00

    아무쪼록 부족한 개발자의 질문에 정성스럽게 답변해주셔서 다들 감사합니다.


    여전히 논리력이던 지식이던 다 부족하다는걸 늘 배웁니다^^;

    알려주신 지식과 의견은 잘 참고하도록 하겠습니다.


    멀리 갈것도없이 바로 오늘 응용이 되더라구요.

    이거 어제 답변 못받았으면, 오늘 헛수고를 할뻔했습니다.


    이게 왜 Weekly Best에 올라갔는지.. .ㅎㅎ;;;

    민망하네요 ㅠㅠ

  • freekun
    171
    2020-10-14 22:09:14

    2번

    이유는 길게 설명해야 해서 일단 패스

  • 가을
    1k
    2020-10-15 09:09:23

    팀장님 의견이 더 바람직합니다.

    1. api는 재사용이 가능해야 합니다. 차후 모바일등으로 확장시 단일기능에 대한 api가 존재하여야 유지보수에 수월합니다.

    2. was는 생각보다 견고합니다. 리퀘스트 한번더 들어오는 것으로 퍼포먼스를 고려할만한 부하가 되지 않으며, 그러하다 하더라도 1번에 유지보수성이 가지는 이점이 훨씬 우월합니다. 나중에 퍼포먼스가 저하된다면 그때 합치면됩니다.

    3. 디비커넥션을 추가로 맺지 않습니다. 견고하게 만들어진 디자인패턴, 아키텍처라면 커넥션풀을 사용하고 있으므로, 추가적인 디비커넥션이 없어야 합니다.

  • 키류
    281
    2020-10-15 09:21:29

    ㅎㅎ 유지보수 상 2번이 낫습니다. 

  • 흑돈
    11
    2020-10-15 15:52:12

    저는 개인적으로 기준을 잡고 합니다.


    만일 1번의 성능이 2번보다 30% 이상 개선 된다면, 1번

    아니라면 2번 입니다.


    그렇다고 하더라도 가능하면 2번으로 하려고 할 것 같습니다.

    나중에 유지보수 때 꼬이면 골치아파서요.

  • 가가멜리
    1k
    2020-10-15 16:44:10

    전 2번입니다.

    1번의 경우 url을 머로 할지 고민이 되네요

    고민이 된다  =  하지 않는것이 좋다

    api url 만 봐도 멀 가져오는지 아는게 편합니다. 

  • 얻으민
    1k
    2020-10-16 00:36:47

    저는 2번이 좋아보이네요.


    이런 히스토리 모른 상태에서 새로온 팀원이 해당 API를 보면 어떻게 생각할까요?

    추가로 1번으로 했을때 얻을 수 있는 성능상 이점이 크지 않을겁니다.

  • cat11
    426
    2020-10-16 08:43:38

    2번이요

    성능상 극대화를 할 이유가 있을때 성능최적화를 고려하는게 맞다고 생각합니다

    지금은 두개지만, 비슷한 이유로 인해 같은 것들이 수십개로 늘어나면요? 

  • 곰개발ㅈ ㅏ
    189
    2020-10-16 08:44:27 작성 2020-10-16 09:26:30 수정됨

    @HJOW

     혹시 사람들이 다른 기술이라고 오해할 수 있어 GraphQL로 정정합니다.

  • 곰개발ㅈ ㅏ
    189
    2020-10-16 09:03:50
    일단 1번이냐 2번을 논하기에 앞서 REST vs GraphQL에 관한 이야기로 넘어갈 수 있습니다. 일단 무엇이 좋다를 논하기에 앞서 아래 조건들을 생각해 봐야 합니다.

    - 페이지가 로드 될 때 가장 먼저 보여줘야 할 항목은 무엇인가? 그것이 사용자의 편의에 어느정도 중요한 것인가? 
    - Request가 실패 할지라도 다른 항목을 보여주는데 영향이 없어야 하는가? 에러 핸들링을 어떻게 설계해야 하는가?

    REST의 경우는 Relation을 payload에 같이 포함시킬 경우, Principle을 위반하게 됩니다. GraphQL은 Relation을 포함하는 것이죠.
    하지만 GraphQL의 기본 개념은 API를 호출하는 Client에게 책임을 넘김으로 인해 좀 더 유연한 개발을 위함이지 그 의미가 무조건 모든 항목들을 한 Payload에 담아야 한다는 의미는 아닙니다.

    그래서 위 질문에 어떻게 답을 하느냐에 따라 달라집니다.
  • 곰개발ㅈ ㅏ
    189
    2020-10-16 09:18:49 작성 2020-10-16 09:22:06 수정됨

    그리고 이 논쟁에서 성능에 관한 이야기는 별개로 논의되어야 합니다.

    예를 들어 API A, B, C를 호출하는데

    A = 1초, B = 0.5초, C = 5초가 걸린다고 할 때, 따로 호출하면 2안은 1초만에 A항목을 먼저 볼 수 있지만, 합칠 경우 6.5초를 기다려야 겠죠. 근데 성능에 관한 논의가 별도라고 이야기 하는 이유는 통상 API의 응답 속도가 1초 이상을 넘어가는 것이 잘못된 것입니다.

    일반적으로 각 서비스에는 SLA ( Service level agreement ) 라는 것이 있고, 95 ~ 99 Percentile 기준으로 응답시간이 500ms를 넘으면 안됩니다. 

    의미인 즉슨 1번과 2번의 방법으로 합치던 합치지 않던 속도가 느린 API는 잘못된 것입니다.

  • Frudy
    5k
    2020-10-16 12:43:55

    와....

    곰개발자님 역시 정말 뛰어나시네요.

    정말 합리적인근거에요.

    전혀 생각하지못한부분이에요.

  • 코딩으로밥벌어먹자
    136
    2020-10-18 16:51:22

    많은 의견이 ㄷㄷ graphql 을 사용하는 중인데 이런 부분에서 여러 쿼리를 하나의 요청에 담아 보낼 수 있다는 장점이있습니다

  • lkwa201
    262
    2020-10-19 09:27:02

    방법2에 한표요.

    기능당 따로 불러오는게 맞다고 생각합니다. 한번에 불러오는 api 데이터가 많다면 랜더링 속도가 느려질거 같다는 제 생각입니다.

  • 박종복
    493
    2020-10-19 15:36:39

    해당 API Server가 관리자 페이지만을 서비스하기위한 것이라면

    1번 질문자님이 제시한 방법이 맞다고 생각합니다.


    다른 Application을 서비스하거나 가능성이 존재할 경우

    2번 팀장님 의견이 맞다고 생각합니다.


    왜냐하면 API 는 특정 Application 의존적이면 안되기 때문입니다.


    그리고 각각의 API를 나누면서 클라이언트에서 여러개 API가 동시 호출되면서 성능 문제가 발생시키는데

    이런 문제를 해결하기위한 방법으로 위에서 언급된 GraphQL과 Server side rendering, 그리고 

    API 서버 앞단에 관리자페이지를 위한 Server(BFF)를 구축하는 방법들이 있습니다. 

  • star16m
    721
    2020-10-19 17:34:38

    저도 2번으로 합니다

    정답은 없다지만

    rest와 graphql, 개발, 유지보수 이런 차이점을 떠나서

    저런 대시보드형태의 페이지들은 지금 현재는 리프레시 기능이 없을지 몰라도 추가하게 될 가능성이 높아요

    실시간 변경 데이터인경우 당연히 그걸 위해 대시보드 페이지가 만들어지는 거고요

    페이지 전체가 아닌 개별 api별 1분마다 리플레시 혹은 유저 커스텀 하게끔

    그리고 일별, 주간별 데이터인 등 캐시를 적용할 때도 개별 api로 되어있는것이 좋습니다



  • 수학은신의언어
    35
    2020-10-19 18:09:25

    저는 2번이요.
    개발은 실수를 최소로 줄이는 것이 좋아요. 

    보기에 간단하고 사람의 손이 적게 들어 가는 코드가 좋은 코드 입니다.

    회사에 좋은 선임 개발자가 있는 것이 부럽네요.

  • kku911
    10
    2020-10-19 22:38:43

    테트리스 라는 게임을 생각해보면, 

    각 개체를 구성하는 가장 작은 "네모" 칸으로만 나오게 되면, 
    테트리스를 어떻게 쌓아야할지 고민할 이유가 없어집니다. :)


  • Mambo
    5k
    2020-10-20 06:24:44 작성 2020-10-20 06:29:43 수정됨
    해당 화면에서 한번에 호출하는 API수를 체크해보심이 좋을듯합니다. 브라우저에서 호출되는 요청 수 제한이 있습니다.
    2번이 기본이되 API 호출이 제한이 걸릴정도로 많다면 통합 API를 만들어야겠죠

    https://www.google.com/amp/s/blog.bluetriangle.com/blocking-web-performance-villain%3fhs_amp=true
  • ckk9618
    277
    2020-10-20 09:27:08

    저는 이럴경우에는 더 먼미래를 생각(추가기능?같은)+유지보수 때문에

    1.5번정도로 타협합니다.

    개발할때에는 2번식으로하게되면 어차피 분리되어 유지보스에 편하되

    첫로드할때에는 2번식으로 개발된 분리된 서비스들을 한번에 호출하여 한번만 호출하는식으로


    어차피 나중에 다개발했다가 한블럭만 또 갱신해야할경우가 생기면 2번식으로 개발했기때문에 그것만 호출하여 다시 그려주면되기때문에 이방법을 선호합니다 저는.

  • 로그인을 하시면 댓글 을 등록할 수 있습니다.