Development on local machine
AtlasX Web Application (Berlin Template) ถูกออกแบบมาให้สามารถทำงานแยกอิสระจากเว็บเซอร์วิสโดยเฉพาะ หากต้องการเรียกใช้งาน Rest API จากเว็บเซอร์วิส เช่น การใช้ระบบล็อกอิน, การเรียกใช้ Stored procedure หรืออัพโหลดไฟล์ไปยังเซิร์ฟเวอร์ สามารถจัดเตรียมเว็บเซอร์วิสและเว็บแอพพลิเคชันตามรายละเอียดดังต่อไปนี้
เตรียมเว็บเซอร์วิสให้พร้อม
ในส่วนของเว็บเซอร์วิส เราสามารถเตรียมพร้อมให้เว็บแอพฯ เรียกใช้งานได้ 3 วิธีด้วยกัน ได้แก่
| วิธีการ | รายละเอียด | Url สำหรับเรียก Rest API | เหมาะสำหรับ |
|---|---|---|---|
เซิร์ฟเว็บเซอร์วิสด้วย .NET CLI | ใช้ .NET CLI เซิร์ฟเว็บเซอร์วิสขึ้นมาด้วยคำสั่ง dotnet run สามารถศึกษารายละเอียดเพิ่มเติมได้จากที่นี่ | https://localhost:5001 หรือ http://localhost:5000 | (1) PA/PG กำลังเริ่มต้นขึ้นโครงใหม่ด้วยตัวคนเดียว (2) มีการปรับแก้เว็บเซอร์วิสบ่อยครั้ง (3) ต้องการความรวดเร็วในการศึกษาและทดสอบโฟล์วการทำงานของแอพฯ |
โฮสต์เว็บเซอร์วิสบน Local IIS | ทำการ Publish เว็บเซอร์วิสแล้วนำไปโฮสต์บน IIS ของเครื่องนักพัฒนาโปรแกรม สามารถศึกษารายละเอียดเพิ่มเติมได้จากที่นี่ | https://localhost/demo-service หรือ http://localhost/demo-servicedemo คือชื่อของเว็บเซอร์วิส แต่ละโครงการใช้ชื่อแตกต่างกันออกไป ดูกฏการตั้งชื่อและตั้งค่าระบบเพิ่มเติมได้ที่นี่ | (1) เว็บเซอร์วิสไม่ค่อยมีการปรับแก้แล้ว (2) ต้องการทดสอบก่อนนำไป Deploy ที่เครื่องเซิร์ฟเวอร์กลางหรือเซิร์ฟเวอร์ Staging/Production เซิร์ฟเวอร์กลาง คือเครื่องเว็บเซิร์ฟเวอร์ที่ทางทีม AtlasX จัดสรรไว้ให้โครงการนำแอพฯ มาโฮสต์เพื่อทดสอบก่อนนำไปติดตั้งที่ Staging และ Production |
โฮสต์เว็บเซอร์วิสบน IIS ของเซิร์ฟเวอร์กลาง | ติดต่อทีม AtlasX เพื่อทำการตั้งค่า CI/CD โดยทีม AtlasX จะช่วยแนะนำวิธีการใช้งานไฟล์ Jenkin และการควบคุมคุณภาพของ Source code ด้วย SonarQube | https://appserver2.cdg.co.th/demo-service หรือ http://appserver2.cdg.co.th/demo-service – demo คือชื่อของเว็บเซอร์วิส แต่ละโครงการใช้ชื่อแตกต่างกันออกไป ดูกฏการตั้งชื่อและตั้งค่าระบบเพิ่มเติมได้ที่นี่–แต่ละโครงการอาจจะได้เซิร์ฟเวอร์กลางแตกต่างกันออกไป ดังนั้นชื่อ Domain จะแตกต่างกันออกไป เช่น appserver2.cdg.co.th, appserver4.cdg.co.th เป็นต้น | (1) มีนักพัฒนาโปรแกรมในทีมมากกว่า 1 คน แล้วมีการเรียกใช้งานเว็บเซอร์วิสด้วยกัน (2) ต้องการความรวดเร็วในการ Deploy เพียงแค่ Merge โค้ดเข้า Jenkins branch จากนั้น CI/CD จัดการ โฮสต์และติดตั้งเว็บเซอร์วิสให้อัตโนมัติ |
คอนฟิกเว็บแอพฯ ให้รองรับกับการทำงานของเว็บเซอร์วิสแต่ละวิธี
ในโครงสร้างของ AtlasX Web Application (Berlin Template) ได้จัดเตรียมคอนฟิกต่าง ๆ เพื่อให้นักพัฒนาโปรแกรมสามารถปรับแก้ได้อย่างง่ายดาย โดยคอนฟิกจะถูกเก็บอยู่ที่ไฟล์ environment.ts สำหรับ Develop และไฟล์ environment.prod.ts สำหรับ Production
เนื่องจากเราจะพัฒนาเว็บแอพที่เครื่องของตัวเอง ดังนั้นจึงจำเป็นต้องแก้ไขคอนฟิกในไฟล์ environment.ts เพื่อให้เว็บแอพฯ ทำงานร่วมกับเว็บเซอร์วิสโดยการปรับแก้ค่าของ webServiceUrl
File: environments/environment.ts
import { AxAuthenticationConfig } from '@atlasx/core/authentication'
import { ApplicationConfig } from '../app/core/config/application.config'
// This file can be replaced during build by using the `fileReplacements` array.
// `ng build --prod` replaces `environment.ts` with `environment.prod.ts`.
// The list of file replacements can be found in `angular.json`.
export const environment: ApplicationConfig & AxAuthenticationConfig = {
production: false,
// เซิร์ฟเว็บเซอร์วิสด้วย .NET CLI
webServiceUrl: 'https://localhost:5001',
// โฮสต์เว็บเซอร์วิสบน Local IIS
// webServiceUrl: 'https://localhost/demo-service',
// โฮสต์เว็บเซอร์วิสบน IIS ของเซิร์ฟเวอร์กลาง
// webServiceUrl: 'https://appserver2.cdg.co.th/demo-service',
// Other configuration below here
// ...
}รันเว็บแอพฯ
- เปิด Terminal ขึ้นมา
- ย้ายไปที่โฟล์เดอร์
ClientAppด้วยคำสั่งcd ClientApp - รันเว็บแอพฯ ด้วยคำสั่ง
npm start - เปิดเว็บบราวเซอร์แล้วเข้าไปที่ http://localhost:4200 จากนั้นทดลองเล่นโฟล์วล็อกอิน จะสังเกตุเห็นการ Redirect ไปยังเว็บเซอร์วิสตาม Url ที่เราทำการคอนฟิกไว้ใน
environment.ts
ในการพัฒนาแอพฯ ที่เครื่องของเราเองยังไม่มีความจำเป็นต้องใช้งาน DataParser เนื่องจากเครื่องเราเองสามารถมองเห็นเว็บเซอร์วิสได้อยู่แล้ว ดังนั้นจึงไม่จำเป็นต้องเซิร์ฟ Backend (โปรเจค .NET ที่อยู่ในโฟล์เดอร์ ServerApp) ขึ้นมา