Code Flow Part 1 — Service Start & Entry Point
Why This Matters
Before you can contribute to SyncApp code, you need to know where it starts and how the service initialization flows. This is the foundation for understanding every code path that follows.
What You'll Learn
- Where the SyncApp entry point is: main() → service start for Linux/cloud vs Windows/on-prem
- What pre-mains are and when they run before the main entry point
- How the service start function is implemented and what it initializes
- The overall code structure: which packages handle what responsibility
- How to navigate the SyncApp codebase to find the right starting point
Watch Video
Open in Google Drive
💡 Open in Drive for AI-powered transcript search
Lesson Summary
SyncApp has two entry points: one for Linux (cloud) and one for Windows (on-prem). Each calls the same core service start function. Pre-mains run before main() and handle initialization tasks like configuration loading. The service start function is the implementation of the daemon start interface. This is where HTTP server setup, scheduler initialization, and adapter registration happens. Understanding this startup sequence is the first step to reading and contributing to SyncApp code confidently.
Key Concepts
SyncApp Entry Pointmain()Service StartPre-mainsLinux vs Windows BinaryCloud vs On-Prem EntryService InitializationAdapter Registration
Key Takeaways
01There are two binaries: one for Linux (cloud SyncApps) and one for Windows (on-prem SyncApps)
02Pre-mains run before main() — they handle setup that must complete before the service starts
03Service start is the implementation of the daemon.Start interface — look for it when tracing initialization
04All adapters (PMS integrations) are registered during service start
05Follow the code from main() → service start → scheduler setup → adapter registration when onboarding to a new integration