GitHub star history ফিরল—নতুন API-তে পরিচয় নয়, শুধু দৈনিক সংখ্যা
GitHub ৪ সেপ্টেম্বর ২০২৬ নতুন REST endpoint GET /repos/{owner}/{repo}/stargazers/history প্রকাশ করেছে। GitHub-এর প্রকাশনা ঘোষণায় বলা হয়েছে, endpoint-টি timestamp-সহ ঐতিহাসিক star count দেয়, কিন্তু individual stargazer-এর পরিচয় প্রকাশ করে না।
৪ সেপ্টেম্বরের এই release-এর ফলে public repository-র দৈনিক star chart আবার API data থেকে তৈরি করা সম্ভব। তবে পুরোনো integration-এ কেবল route বদলালেই হবে না: user ও starred_at-নির্ভর record-এর জায়গায় সপ্তাহভিত্তিক aggregate response পড়তে এবং pages-এর বিপরীতমুখী সময়ক্রম ঠিক করতে হবে।
Response-এ পরিচয়ের বদলে যা থাকে
Response একটি array; প্রতিটি object-এ week, total ও days থাকে। week সংশ্লিষ্ট calendar week-এর শুরুর Unix timestamp, total সেই সপ্তাহে তৈরি হওয়া star-এর সংখ্যা এবং days রবিবার থেকে শুরু হওয়া সাতটি দৈনিক count। অর্থাৎ শিরোনামের «শুধু দৈনিক সংখ্যা» বলতে identity-bearing record-এর বদলে aggregate count বোঝানো হয়েছে; weekly total-ও response-এ summary হিসেবে থাকে।
GitHub-এর REST reference অনুযায়ী সপ্তাহগুলো most recent first আসে, star না-থাকা সপ্তাহে zero count থাকে, প্রতি page-এর default ও সর্বোচ্চ আকার ৩০ সপ্তাহ, page ১ থেকে শুরু হয়ে সর্বোচ্চ ১০০ পর্যন্ত যেতে পারে, এবং public resource-এর ক্ষেত্রে authentication ছাড়াই endpoint ব্যবহার করা যায়। একই reference সতর্ক করেছে যে week ও day boundary সব ক্ষেত্রে UTC-র সঙ্গে মেলার নিশ্চয়তা নেই।
নথির example object হলো {"week": 1754784000, "total": 19, "days": [0, 12, 7, 0, 0, 0, 0]}। এতে login, user ID, avatar URL বা profile URL নেই; কোন ব্যক্তি কখন star দিয়েছেন, সেটিও আর আলাদা event হিসেবে ফেরে না। total ও days একই সময়সীমার দুই রূপ, তাই importer চাইলে সাতটি daily count-এর যোগফল দিয়ে weekly total যাচাই করতে পারে।
Public repository-তে token বাধ্যতামূলক নয়
একটি public repository-র ন্যূনতম request হলো Accept header-সহ https://api.github.com/repos/OWNER/REPO/stargazers/history। Documentation-এর cURL নমুনায় Authorization header থাকলেও public resource-এর জন্য সেটি endpoint contract-এর বাধ্যতামূলক অংশ নয়।
Authenticated request-এ GitHub App user access token, GitHub App installation access token অথবা fine-grained personal access token ব্যবহার করা যায়; token-এর repository permission হিসেবে read-level Metadata প্রয়োজন। Private resource বা unauthenticated rate limit যথেষ্ট নয় এমন workload-এ token প্রাসঙ্গিক, কিন্তু শুধু public star chart দেখাতে ব্যবহারকারীর personal token চাওয়া API-র প্রয়োজন নয়।
পুরোনো GET /repos/{owner}/{repo}/stargazers route এবং নতুন history route একই data contract নয়। প্রথমটি stargazer তালিকার জন্য তৈরি; দ্বিতীয়টি পরিচয় বাদ দিয়ে repository-র সময়ভিত্তিক aggregate দেয়। তাই পুরোনো user-object model নতুন response-এর ওপর প্রয়োগ করলে parser ব্যর্থ হবে।
পুরোনো scraping থেকে কী হারাবে, chart কীভাবে ফিরল
পুরোনো integration custom star media type ব্যবহার করে প্রতিটি stargazer-এর সঙ্গে starred_at timestamp নিত, timestamps সাজিয়ে curve বানাত এবং প্রয়োজনের অতিরিক্ত username, avatar ও profile URL-ও সংগ্রহ করত। Star History-এর migration বিবরণে বলা হয়েছে, সেবাটি নতুন endpoint গ্রহণ করেছে এবং আগের দুই মাসে ভেঙে যাওয়া chart এখন আবার কাজ করার কথা।
এই migration-এর পর tool আর কে star দিয়েছেন, সেই profile ধরে enrichment করা বা ঘণ্টা-মিনিটের event time পুনর্গঠন করা সম্ভব হবে না। নতুন API-র সবচেয়ে সূক্ষ্ম resolution হলো days array-এর দৈনিক bucket; তাই user directory, ব্যক্তিভিত্তিক attribution, cross-repository identity matching বা hourly activity view-এর বিকল্প এটি নয়।
শুধু দৈনিক star additions বা সময়ভিত্তিক aggregate curve দরকার হলে পরিচয় বাদ পড়া chart-এর জন্য কার্যগত ক্ষতি নয়। Request-এর খরচ আর repository-র stargazer সংখ্যার সঙ্গে সরাসরি বাড়ে না; weekly objects আনতে হয় repository-র বয়স অনুযায়ী। তবে identity-নির্ভর feature এবং aggregate chart-কে একই migration হিসেবে বিবেচনা করা যাবে না।
Weekly pages থেকে দৈনিক series তৈরির ক্রম
নতুন endpoint-এর প্রথম page-এ সাম্প্রতিক সপ্তাহ থাকে; পরের page-গুলো repository তৈরির সপ্তাহের দিকে যায়। Chart সাধারণত পুরোনো থেকে নতুন সময়ক্রম চায়, তাই pages সংগ্রহের পরে weekly objects-এর পুরো sequence উল্টাতে হবে—শুধু page ২-কে page ১-এর আগে বসালে প্রতিটি page-এর অভ্যন্তরীণ newest-first order ঠিক হবে না।
- OWNER ও REPO বসিয়ে history route call করুন। Public repository হলে Accept header দিয়ে unauthenticated request শুরু করা যায়; প্রয়োজন হলে per_page=30 দিন।
- Page ১ থেকে প্রতিটি response সংগ্রহ করুন। response-এ নির্ধারিত page size-এর চেয়ে কম object এলে বা খালি array এলে থামুন; page-এর সর্বোচ্চ সীমা অতিক্রম করবেন না।
- সব weekly object একত্র করে সম্পূর্ণ array oldest-to-newest ক্রমে উল্টে দিন। এতে page boundary-র দুই পাশের সপ্তাহও সঠিক ধারাবাহিকতায় আসবে।
- প্রতিটি object-এর days[0] থেকে days[6] পড়ুন। প্রথম মান রবিবারের bucket; week timestamp থেকে ধারাবাহিক সাতটি point তৈরি করুন, কিন্তু boundary-কে অনুমান করে UTC midnight বা স্থানীয় midnight-এ জোর করে বসাবেন না।
- দৈনিক chart-এ day count সরাসরি ব্যবহার করুন। Cumulative additions curve চাইলে সবচেয়ে পুরোনো bucket থেকে running sum হিসাব করুন এবং প্রতি সপ্তাহে days-এর যোগফল total-এর সঙ্গে মিলিয়ে transformation যাচাই করুন।
পুরোনো parser যদি user array, starred_at অথবা stargazer-সংখ্যাভিত্তিক page আশা করে, নতুন response-এর জন্য আলাদা data model প্রয়োজন। পুরোনো identity cache-এর ওপর aggregate objects লিখে দিলে schema-র অর্থ বদলে যাবে; তাই cache ও downstream fields-ও version বা migration boundary দিয়ে আলাদা রাখা উচিত।
নতুন history আর বর্তমান star total এক জিনিস নয়
History response প্রতি দিনে তৈরি হওয়া star-এর count দেয়; এটি কোনো দিনের শেষে সক্রিয় stargazer-এর সরাসরি snapshot নয়। ফলে days array যোগ করে যে cumulative series পাওয়া যায়, সেটি star-creation events-এর curve। পরে সরিয়ে নেওয়া star, মুছে যাওয়া account বা অন্য account-state পরিবর্তনের কারণে এটি repository-র বর্তমান displayed total-এর সঙ্গে সব সময় অভিন্ন হবে—এমন নিশ্চয়তা contract দেয় না।
Weekly object-এ cumulative running total-ও নেই। অতীতের কোনো বিন্দু পর্যন্ত cumulative additions নির্ণয় করতে repository তৈরির সপ্তাহ পর্যন্ত প্রয়োজনীয় pages এনে daily counts যোগ করতে হবে। বর্তমান release তাই chart ফিরিয়েছে, কিন্তু পুরোনো public identity access, hourly resolution বা প্রস্তুত cumulative series ফেরায়নি; প্রকাশিত contract এখন week, total, days, newest-first pagination এবং public-resource authentication নিয়মেই সীমিত।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।