dmz 개발창고

개념부터 약간 다르다.

이건 라이브러리 도구 vs 프레임워크를 비교하는 거다.

라이브러리 도구와 프레임워크의 가장 큰 차이는 개발 흐름의 주도권을 누가 가지고 있는가에 달렸다.

개발자가 코딩할 때, 라이브러리는 자신에게 필요한 기능만 사용해도 되므로, 개발 주도권이 개발자에게 있다.

프레임워크는 개발 주도권이 프레임워크에게 있다.

(웹 개발을 시작하는 방법부터 기능을 구현하는 모든 것을 프레임워크에서 정해 놓은 대로 따라야 한다.)

부트스트랩의 장점

부트스트랩의 단점

뷰의 장점

뷰의 단점

Maven같은경우는 pom.xml  이란 이름으로 쓰고 (Spring에서),

Gradle은 (스프링부트), (안드로이드) 에서 주로 쓰는것임 

pom?  -Project Object Model

-프로젝트 정보 ,빌드 설정, 빌드 환경 ,POM연관 정보

pom.xml파일을 말하며 Maven의 기능을 이용하기 위해 POM이 사용됨

보통 프로젝트를 진행하게 되면 많은 라이브러리들을 활용해서 개발함

라이브러리들의 수가 수십개가 훌쩍 넘어관리하는 것이 힘들어짐.

Maven은 내가 사용할 라이브러리 뿐만 아니라 해당 라이브러리가 작동하는데 필요한

다른 라이브러리들까지 관리하여 네트워크를 통해 자동으로 다운 받아줌

Maven은 JDK설치와 같이 설치가능.

환경변수 잡아주고 하면 cmd에서 mvn –version을 통해 버전을 알 수 있고 설치가 가능함

Gradle

Gradle이란 빌드 배포 도구임.

안드로이드 앱을 만들때 필요한 공식 빌드시스템이며 JAVA, C/C++, Python 등을 지원함

메이븐의 경우 XML로 라이브러리를 정의하고 활용하도록 되어 있으나, Gradle의 경우 별도의 빌드스크립트를 통하여 사용할 어플리케이션 버전, 라이브러리등의 항목을 설정

특징: 스크립트 언어로 구성 (XML과 달리 변수선언, if, else, for등의 로직이 구현가능)

(메이븐 레파지토리를 동일하게 사용할 수 있어서 설정된 서버를 통하여 라이브러리를 다운로드 받아 모두 동일한 의존성을 가진 환경을 수정가능)

Gradle이 메이븐보다  늦게 나온만큼 사용성, 성능 등 비교적 좋은 스펙!

Gradle이 Maven보다 좋은점

• Build라는 동적인 요소를 XML로 정의하기에는 어려운 부분이 많다.
  • 설정 내용이 길어지고 가독성 떨어짐
  • 의존관계가 복잡한 프로젝트 설정하기에는 부적절
  • 상속구조를 이용한 멀티 모듈 구현
  • 특정 설정을 소수의 모듈에서 공유하기 위해서는 부모 프로젝트를 생성하여 상속하게 해야함 (상속의 단점 생김)
• Gradle은 그루비를 사용하기 때문에, 동적인 빌드는 Groovy 스크립트로 플러그인을 호출하거나 직접 코드를 짜면 된다.
  • Configuration Injection 방식을 사용해서 공통 모듈을 상속해서 사용하는 단점을 커버했다.
  • 설정 주입시 프로젝트의 조건을 체크할 수 있어서 프로젝트별로 주입되는 설정을 다르게 할 수 있다.

속도! Gradle은 메이븐보다 최대 100배 빠르다.

지금 시점에서 Gradle을 사용하지 않을 이유는 익숙함 뿐인 것 같다

( Maven과 익숙해진 XML을 버리고 Gradle과 Groovy문법을 배우는 것은 적지않은 비용이 든다. 특히 협업을 하는 경우, 프로젝트 구성과 빌드만을 위해 모든 팀원이 Groovy 문법을 익혀야 한다는 사실은 Gradle을 사용하는데 큰 걸림돌이 된다.)

(협업과 러닝커브를 고려하여 여전히 Maven을 사용하는 팀이 많고 부족함 없이 잘 사용하고 있지만, 빌드타임 비용문제로 이어질경우 Gradle을 사용해야 할 것 같다. 왜냐하면 Gradle이 Maven보다 최대 100 배 빠르기 때문이다.)

출처

https://gradle.org/
https://maven.apache.org/
http://egloos.zum.com/kwon37xi/v/4747016
https://bkim.tistory.com/13

https://hyojun123.github.io/2019/04/18/gradleAndMaven/

Cookei

쿠키가 뭔지 일단 알아보자~!

서버는 쿠키를 사용해서 너의 브라우저(크롬, 엣지 등)에 데이터를 넣을 수 있단다.

너의 관한 것을 기억하려고.

일단, 니가 사이트에 방문하면 너의 브라우저는 서버에 페이지를 요청하겠지.

서버가 응답할때 필요한 데이터(니가 요청한 데이터)와 함께

너의 브라우저에 보낼 쿠키가 있을 수 있는 것이지!

서버 -------------< CSS, HTML, Datas.... & Cooikes >-------> 브라우저

일단 받았으니깐,

브라우저는 쿠키를 저장하고, 

그 웹사이트에 접속할때 마다. 브라우저는 요청할때 쿠키도 같이 보내게 될거야. !

쿠키는 사이트마다 달라, 엄밀히 말하면 도메인마다 다른거지.

korea.com 에서 주고받은 쿠키 (초코칩쿠키) 와 japan.com 에서 주고받은 쿠키(방사능맛쿠키) 는 다른거지.

쿠키는 서버가 정한 기간에 따라 유효기간이 있어

쿠키에는 여러가지 정보를 담을 수 도 있어, 이걸로 인증도 가능하고 말이지.

내가 항상 쓰는 설정이 있으면 쿠키를 주고 받아서 기존에 쓰던 설정대로

데이터를 불러올수 있어

세션을 알아보잦! (Session)

너의 브라우저에서 무언가를 요청을 하게 되면, 쿠키를 주고 받는다고 이야기 했어

자 , 로그인이 필요한 웹사이트에서 무언가를 요청해서 데이터를 확인하거나 페이지 이동을

하고싶을때마다 로그인을 해야할까?

내가 로그인 한 상태인지 서버는 어떻게 알 수 있지?

우리는 한번 로그인을 하고 나면 일정시간동안 , 로그인을 안해도 웹사이트를 이용할 수가 있어.

그건 세션이 유지되는 덕분이지 엄밀히 말하면 세션 ID를 서버가 계속 확인하고 있는거라구!

로그인을 하게되면 서버는 세션ID를 생성해서 발급해줘

마지 임시 출입증이라고 생각하면 좋을것 같아.

쿠키를 이용해 브라우저가 갖고 있다가 무언가를 요청할때 다시 이 임시출입증을 쿠키에 담아서 보내겠지.

그러면, 서버는 쿠키에 담겨진 세션ID를 가지고 너가 누군지 알수 있단 말인거야~

옹키동키?

참고로 세션을 이용해서 IOS나 Android 앱을 만들수는 있지만, 쿠키는 사용할 수 없어 

그건 브라우저에만 해당되는 얘기야.

하지만 이럴경우 토큰(Token)을 사용해.

서버에 토큰을 보내는거지~ 마찬가지로 토큰을 서버에 보내고, 서버는 토큰으로 누구인지 찾는거지.

어쨌든, 세션에서 가장 중요한건, 로그인한 유저들의 모든 세션ID를 DB에 저장해놓아야 한다는 것이야.

많은 유저들이 접속 했을때는 그만큼의 세션DB 자원도 더 많이 많이 필요하게 되는 것이지.

그래서 JWT를 쓰기도 해 JWT는 토큰방식으로 처리하기 때문에 세션DB를 가질 필요가 없지.

서버는 유저 인증하느라 많은 일을 하는 수고로움이 덜어지지.

JWT와 세션의 차이점은 무엇일까?

세션은 로그인정보를 주고 나면 세션ID를 생성해서 DB에 저장하고, 그 정보로 인증을 하지.

JWT는 아주 긴 String형태의 토큰을 생성해서 (ID 정보가 담긴) 브라우저에 넘겨주고

다시 받을때 이정보를 분석해(위조된 토큰인지, 무슨정보가 담겼는지) 유저가 맞는지 판단하는거지.

단, JWT는 암호화 되지 않은 문자열이라, 궁금하겠지만, 보안관련한 내용은 여기서 다루지 않을거야.

하지만 리소스를 필요로 하지 않는점과 개발의 심플함은 굉장한 매력이지.

요약.

*쿠키 = 전달 매개체

*토큰 = 서버가 기억하기 위한 특정텍스트 모음

*JWT = 정보를 포함한 토큰, 정보가 들어있으므로 DB없이 검증가능.

------------------------------------------------------------------------------------------------------------

[참조 : 해당 내용은 유튜브 -

노마드코더의 [세션 vs 토큰 vs 쿠키? 기초개념 잡아드림. 10분 순삭!]와

기타 IT관련 서적, 및 IT관련 웹사이트 등에서 참조하였습니다. ]