많은 플랫폼, 동일한 코어 코드베이스, 최상의 전략?

Question

작은 웹 앱을 개발 중입니다. 고급 기능은 없으며 데이터베이스의 기본 쿼리 만 있습니다.

웹 사이트 자체는 일반적인 방법과 Facebook Connect를 통해 로그인 할 수 있으며 일부 CRUD 기능이 있습니다.

나는 iPhone 응용 프로그램과 Android 응용 프로그램뿐 아니라 '기본'Facebook 응용 프로그램을 만들 것입니다.

제 질문은 코드베이스를 유지하는 가장 좋은 방법은 무엇입니까?

데이터베이스 레코드를 추가, 편집 및 삭제할 수있는 기본 API를 작성하기 전에이 작업을 수행했으며 모든 플랫폼에서 API에 HTTP POST를 사용했습니다. 이로 인해 코드베이스를 유지 관리하고, 버그를 수정하고, 업데이트하는 등의 작업이 매우 쉬워졌습니다. 한 곳만 업데이트해야했기 때문입니다. 개별 앱 자체에는 실제로 일부 스키닝과 일부 cURL 요청 만있었습니다. 이 기능은 모바일 앱 (iPhone 및 Android)에서 훌륭하게 작동했지만 웹 사이트 및 Facebook 앱에서 불필요한 http 요청을 만들었습니다.

이 상황에 접근하는 가장 좋은 방법은 무엇입니까? 2 개의 웹 사이트 (Facebook 및 일반 웹 사이트)와 API를 만들어야합니까? 이렇게하면 유지 관리가 더 어려워 질 수 있지만 훨씬 더 안정적이고 빠릅니다. 유지 관리가 쉬운 API 일뿐입니다.

코드베이스는 CodeIgniter의 PHP이며 데이터베이스는 MySQL입니다.

Answer 1

PHP 클래스로 API를 작성한 다음 HTTP API를 감싸 야한다고 생각합니다.

PHP 클래스 API

:

<?php // myproducts.class.php 

class MyProducts 
{ 
    static function addProduct($name, $price) 
    { 
    // add the product 
    } 
} 

다음의 HTTP API :이

<?php // api/products.php 

// read HTTP POST and decode it as json 
$postParams = json_decode(file_get_contents('php://input')); 
if (!$postParams) 
    throw new exception("Could not decode POST data, invalid JSON."); 

// run the desired action 
$classMethod = $postParams['action']; 
$arguments = $postParams['arguments']; 
$result = call_user_func_array(array('MyProducts', $classMethod), $arguments); 

// print result as JSON 
print json_encode($result); 

, 당신은 쉽게 HTTP API를 이야기하는 OBJ-C 클래스를 쓸 수 있습니다 .

NSData *postData = [@"{\"action\": \"addProduct\", \"arguments\": [\"Foo\", 42.00]}" dataUsingEncoding:NSUTF8StringEncoding]; 
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:API_URL cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:60]; 
[request setHTTPMethod:@"POST"]; 
[request setHTTPBody:postData]; 
NSHTTPURLResponse *urlResponse = nil; 
NSError *error = nil; 
NSData *responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&urlResponse error:&error]; 

NSLog(@"response: %@", [[[NSString alloc] initWithData:responseData encoding:NSUTF8StringEncoding] autorelease]); 

분명히 JSON 인코딩/디코딩을위한 Obj-C API를 찾고 싶을 것입니다. 사용 중 TouchJSON

Answer 2

당신이 설명하는 것과 같은 몇 가지 프로젝트를 만들었습니다. 동일한 플랫폼, codeigniter 및 MySQL,이 경우에 약간의 차이가 있습니다. 내가 지금까지 유용 발견했습니다 것은 귀하의 웹 사이트가 페이스 북은 iframe에서 볼 때, 귀하의 사이트를 치는 사용자 에이전트가

'facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)' 

그래서 당신이 그것을 감지 할 수있는 것입니다.

때때로 인증을 필요로하지 않으면 사용자 에이전트를 기반으로 CSS 파일을 변경하는 것으로 벗어날 수 있습니다. 인증이 필요하면 별도의 컨트롤러를 작성하거나 js SDK를 사용하십시오. 이것이 충분하지 않거나 귀하의 사이트가 더 복잡한 경우 페이스 북과 일반 웹 사이트에 대한 별도의보기를 가지고 사용자 에이전트에 따라 전환하십시오. API에 도움을 줄 수는 없지만 웹 사이트와 동일한 API 모델을 사용할 것이라고 생각합니다. 별도의 컨트롤러가 필수입니다.

Answer 3

조금만 더 생각해 보면 특히 웹 사이트와 웹 사이트가 모두 REST 원칙을 기반으로 구축 된 경우 약간의 노력 만 있으면 API를 얻을 수 있습니다. 예를 들어 컨트롤러에 '추가'메소드가있는 경우 웹 사이트와 API 모두 거의 똑같은 작업을 수행합니다. 뷰에 전달할 데이터 트리 (배열 또는 객체 포함)를 설정 한 경우 요청이 API를 통해 이루어지면이 트리의 JSON 인코딩 표현을 반환 할 수 있습니다.

메인 애플리케이션과 관련하여 기본 웹 사이트와 얼마나 유사한 지에 따라 동일한 코드 서명자 설치시 두 라우팅 및/또는 URL 재 작성 마법과 함께 사이트를 구축 할 수 있으므로 공통된 모델, 컨트롤러, 또는 확장 가능한 템플릿 라이브러리를 사용하는 경우 유사한보기

Answer 4

1 월부터 Kohana를 사용하고 있습니다. 우리는 Codeigniter에서 옮겼습니다. 계단식 파일 시스템을 사용하면 코드를 쉽게 구성 할 수 있습니다.

다중 플랫폼 사용의 예로 Android가 있습니다. 우리는 대부분의 논리를 PHP로 밀어 넣었습니다. 그런 다음 연결 및 속도에 대한 일부 헬퍼가있는 Android WebView로 가져 와서 네이티브 앱처럼 표시합니다.

Kohana를 사용하면 API 호출을위한 JSON보기 만 만들면됩니다. 요청을 확인하여 AJAX가 JSON 또는 다른보기를 사용할지 여부를 결정할 수 있는지 확인할 수 있습니다.

브라우저 또는 모바일 앱 사이에서 결정하기 위해 Google 모바일 앱스 고유의 사용자 에이전트 문자열을 설정 한 다음 PHP 측에서 테스트합니다. 또한 몇 가지 다른 레이아웃 파일을 가질 수있는 뷰 계층 구조가 있습니다. 모바일 요청 용, 웹 애플리케이션 용, 특정 유형의 사용자 용 등이 있습니다.

전반적으로 Kohana는 Codeigniter보다 융통성이 뛰어나며 웹 응용 프로그램 및 API를 구축하기위한 훌륭한 기반입니다.

Kohana의 단점은 문서가 다소 가난하다는 것입니다. 그러나 일단 사용을 시작하면 빨리 이해할 수 있습니다. 코드베이스는 깨끗하고 읽기 쉽습니다.

죄송합니다. Kohana에 대해 많이 읽으 셨지만, PHP를 사용하고 융통성있게 사용하고 싶다면 IMHO를 시작하십시오.

Answer 5

나는 N-Tier 방식을 택할 것이다. '모바일'(iOS 및 Facebook) 앱을 최상위 계층으로 처리하십시오. 대부분의 시간을 데이터를 표시하고 사용자가 입력하는 데 소비합니다. 건강한 AJAX를 통해 그들은 비즈니스 로직을 처리하고 지속성을 처리하는 "컨트롤러"역할을하는 PHP 응용 프로그램과 함께 작업합니다. & 동시성. 예, 많은 데이터가 돌아 다니고 있지만 조기에 최적화하지는 마십시오. 앱을 개발할 때 데이터를 캐시 할 수있는 위치를 생각하고 과도한 요청을 발견하면 이후 버전에서 최적화하십시오. 안타깝게도 Javascript/PHP 경계를 넘는 엔티티 관계 관리자는 실제로 존재하지 않으므로 잠시 롤업을합니다.