תבניות של API

[חוקר]

@davidnead אמר בתבניות של API:

זה מה שהתכוונתי לשאול. כלומר זו גרסת PHP. לא מענין.

אבל יש להם כמובן גרסת צד לקוח מבוסס vue + bootstrap נקי עם התממשקות לAPI לכל הפעולות, כאשר צד שרת אתה בונה במה שתרצה (אצלי זה nodejs)

[aaron]

בעבר יצא לי גם לעשות סקר שוק גדול למדי בדיוק על מה שאתה קורה לו "תבניות של API".
שבסופו של דבר, תקרא לזה כך או אחרת, הכוונה היא לheadless cms.
וספציפית לאלה שמבוססים API.

בתכלס אין יותר מידי פתרונות בתחום הזה, יש בעיקר את strapi, שאני לא יודע למה אתה מזלזל בו, הוא מעולה. אולי לא לכל סדרי גודל של נתונים, אבל מניח שלרוב כן.
יש תחליפים כמו keystone (אני רואה שכבר הזכרת) הוא אמנם נותן לך יותר שליטה בידיים, אבל תכלס לא חוסך יותר מידי בכתיבה של בוילרפלייטס.
(צריך לבדוק מה השתנה בגירסא האחרונה, לא הספקתי להתעדכן)

יש גם את directus, בזמנו הרגיש קצת בוסרי, מניח שכבר יותר טוב כיום.

בסופו של דבר, אם אתה לא מחפש את הUI שCMS נותן לך, אז אין שום עניין לחפש "תבנית" לAPI.
אתה כנראה סה"כ רוצה לכתוב איזה מבנה בסיסי של האובייקטים שלך, ולחשוף פעולות CRUD עליהם. שזה בגדול DB as API..
לזה כנראה keystone מעולה. ובטוח יש תחליפים דומים.
(הייתי מציץ על prisma אם לא מפריע לך לחשוב על שימוש בgraphql)

[davidnead]

@aaron אמר בתבניות של API:

בעבר יצא לי גם לעשות סקר שוק גדול למדי בדיוק על מה שאתה קורה לו "תבניות של API".
שבסופו של דבר, תקרא לזה כך או אחרת, הכוונה היא לheadless cms.
וספציפית לאלה שמבוססים API.

בתכלס אין יותר מידי פתרונות בתחום הזה, יש בעיקר את strapi, שאני לא יודע למה אתה מזלזל בו, הוא מעולה. אולי לא לכל סדרי גודל של נתונים, אבל מניח שלרוב כן.
יש תחליפים כמו keystone (אני רואה שכבר הזכרת) הוא אמנם נותן לך יותר שליטה בידיים, אבל תכלס לא חוסך יותר מידי בכתיבה של בוילרפלייטס.
(צריך לבדוק מה השתנה בגירסא האחרונה, לא הספקתי להתעדכן)

יש גם את directus, בזמנו הרגיש קצת בוסרי, מניח שכבר יותר טוב כיום.

בסופו של דבר, אם אתה לא מחפש את הUI שCMS נותן לך, אז אין שום עניין לחפש "תבנית" לAPI.
אתה כנראה סה"כ רוצה לכתוב איזה מבנה בסיסי של האובייקטים שלך, ולחשוף פעולות CRUD עליהם. שזה בגדול DB as API..
לזה כנראה keystone מעולה. ובטוח יש תחליפים דומים.
(הייתי מציץ על prisma אם לא מפריע לך לחשוב על שימוש בgraphql)

מה היתה המסקנה שלך? במה בחרת להשתמש?

[davidnead]

@aaron אמר בתבניות של API:

בתכלס אין יותר מידי פתרונות בתחום הזה, יש בעיקר את strapi, שאני לא יודע למה אתה מזלזל בו, הוא מעולה. אולי לא לכל סדרי גודל של נתונים, אבל מניח שלרוב כן.

strapi הוא CMS זה אומר שהוא אומר לך "אל תכתוב קוד אני אכתוב בשבילך". זה אומר פעולות מייגעות של יצירת אובייקטים דרך הממשק שלהם. וזה אומר מעט מאוד גמישות ושליטה בשינוי הקוד תכל'ס ושילובו באפליקציה שלך.
בנוסף, הוא לא ממש תורם. כי יש לו מעט מאוד תבניות מוכנות, מה שאומר שאתה צריך ליצור את האובייקטים לבד, וכל היתרון שנשאר הוא שעושים את זה דרך הממשק - שזה מבחינתי בעיקר חסרון.

יש תחליפים כמו keystone (אני רואה שכבר הזכרת) הוא אמנם נותן לך יותר שליטה בידיים, אבל תכלס לא חוסך יותר מידי בכתיבה של בוילרפלייטס.

עוד לא חפרתי שם מספיק, אבל לא הבנתי מה הגדולה שלו. הוא סך הכל מספק תחביר לבנות CURD+API אבל תכל'ס אתה צריך לבנות הכל לבד. (אולייש כאלו שזה יותר קל להם). יש שם אמנם כמה פרוייקטי דוגמא כמו בלוג אבל זה בקטנה ולא נותן מענה.

יש גם את directus, בזמנו הרגיש קצת בוסרי, מניח שכבר יותר טוב כיום.

לא מכיר. מה זה?

בסופו של דבר, אם אתה לא מחפש את הUI שCMS נותן לך, אז אין שום עניין לחפש "תבנית" לAPI.
אתה כנראה סה"כ רוצה לכתוב איזה מבנה בסיסי של האובייקטים שלך, ולחשוף פעולות CRUD עליהם. שזה בגדול DB as API..
לזה כנראה keystone מעולה. ובטוח יש תחליפים דומים.

בטח שיש ענין. אני אבהיר למה אני מצפה. אני לא מצפה לקבל רק שלד בסיסי כללי.
אני מצפה לסוג של ספריה שמכילה הרבה רכיבים קלאסיים. למשל:
ניהול הרשאות, לוגין, תיבת הודעות פנימית, פוסטים (בלוג), חנות, צ'ט, הגדרות חשבון, סטטיסטיקות אתר, ניהול לקוחות, ניהול קורסים וכו' וכו'.
כמובן עם אינטרפייס שמאפשר לאנשים ליצור פלגינים ורכיבים נוספים.

הספריה צריכה לבצע 3 פעולות:

1. לייצר DB מתוך כלל הרכיבים שאבחר, ולעדכנו לפי הצורך אם אני מוסיף רכיב.
2. לייצר אובייקטים של ORM מותאמים לטבלאות שנוצרו
3. ליצור קלאסים עם פונקציות API בסיסיות לכל רכיב/טבלה. (כמו למשל fundUser, login, addProduct וכו')

לי נשאר לבחור אלו רכיבים אני רוצה, ולהתחיל להשתמש. בדומה לוורדפרס, עם הבדל קטן: התוצאה שלי אינה ממשק אלא קוד, והשינויים שלי יהיו עריכת הקוד (הוספת פונקציות שונות לAPI, ויצירת שדות/טבלאות נוספות משלי עם API מתאים ושילובם לפי הצורך בקוד שנוצר ע"י המחולל של הספריה).
ההבדל בין זה לשני הדוגמאות הנ"ל היא ראשית שאיני צריך להתעסק עם ממשק אלא אני מקבל קוד מוכן (לא אינטרפייס!) ועורך אותו, שנית שיש מספיק רכיבים לשלב.

הייתי מובן מספיק?

[davidnead]

@חוקר אמר בתבניות של API:

@davidnead

איך פונים אליך באישי?

[ש.ב.ח.]

@davidnead
בהקשר לשאלתך על Laravel
האמת שעברתי על רובו של האשכול הזה ועדיין לא הגעתי למסקנה מה אתה רוצה
ואולי זה בגלל שאני לא מכיר את nodejs בשביל להבין מה לא טוב לך שם

אני מכיר את PHP עם Laravel
לספרייה זו יש הרבה הרבה דברים שמקילים עליך את החיים בעבודה
את הטבלאות אתה יכול ליצור או לשנות ע"י שימוש בקוד
אתה מרגיש שאתה מדבר עם הDB בגובה העניים
יש גם מערכות יחסים (לניהול קשרי גומלין)
ועוד מלאן דברים ושירותים שנותנים לך לחייך בעבודה...
ויש לו גם הרבה חבילות בקהילה של הקוד הפתוח.

ממליץ לך קצת לקרוא עליו אולי אליו התכוונת...
https://laravel.com/docs/8.x/
נסה לעבור על מה שמעניין אותך (עקוב אחר הניווט בסרגל הצידי)

ואם באה לך טעימה והדרכה נעימה
https://laracasts.com/series/laravel-8-from-scratch

[aaron]

@davidnead אמר בתבניות של API:

strapi הוא CMS זה אומר שהוא אומר לך "אל תכתוב קוד אני אכתוב בשבילך". זה אומר פעולות מייגעות של יצירת אובייקטים דרך הממשק שלהם. וזה אומר מעט מאוד גמישות ושליטה בשינוי הקוד תכל'ס ושילובו באפליקציה שלך.

לא נכון, יש אפשרות להגדיר מודולים כקוד

@davidnead אמר בתבניות של API:

מה היתה המסקנה שלך? במה בחרת להשתמש?

הסקר שוק לא היה למטרת פרויקט ספציפי, סתם כי אני אוהב להכיר תחומים בצורה רחבה. ואני מתכנת פייתון בעיקר.

@davidnead אמר בתבניות של API:

אני מצפה לסוג של ספריה שמכילה הרבה רכיבים קלאסיים. למשל:
ניהול הרשאות, לוגין, תיבת הודעות פנימית, פוסטים (בלוג), חנות, צ'ט, הגדרות חשבון, סטטיסטיקות אתר, ניהול לקוחות, ניהול קורסים וכו' וכו'.
כמובן עם אינטרפייס שמאפשר לאנשים ליצור פלגינים ורכיבים נוספים.

הגישה שלך מתאימה לWP, אני מניח שהיא לא פופולרית באיטרציה הנוכחית של עולם התכנות כי היום אוהבים כמה שפחות vendor lock in.

בסופו של דבר אתה צריך לשבת להגדיר במדויק את החלקים שנצרכים עבורך לכל חלק ממה שכתבת, למצוא את הכלים הרלוונטים שאתה בוחר לעבוד איתם וליצור לך בוילרפלייט שיגנרט בסיס שמכיל את כל אותם חלקים.
תוכל לפרסם את זה כקוד פתוח, אני מאמין שזה יתפוס תאוצה אפילו.

מוזמן להתחיל לפרוס את מחשבותיך לגבי החלקים הנדרשים, מניח שרבים ישמחו לקחת חלק.

[חוקר]

@davidnead אמר בתבניות של API:

איך פונים אליך באישי?

7226644@gmail.com

[davidnead]

@חוקר אמר בתבניות של API:

אבל למעשה אני רואה שכשמגיע לקוח ומבקש לי שהוא צריך מערכת רישום מסויים שהוא נותן לי טבלת אברכים ושגר להם הודעה והם יבחרו האם להרשם וכדומה, הכי קל לי לעשות זאת עם הכלים הישנים, אני יוצר טבלה חדשה בד"ב, באמצעות הגרנרטור אני יוצר את קבצי ה PHP, מייבא את הטבלה, יוצר משתמש חדש, מוסיף לו הרשאת גישה לטבלה, מוסיף לו לחצן של קישור לטבלה, ושולח לו פרטי גישה וסיימתי. הלקוח מקבל לינק, נכנס עם פרטי הגישה, יש לו כפתור "רישום ל...", הוא נכנס, יש לו טבלה עם אפשרות צפייה ועריכה ומחיקת והוספת שורה, סינון ומיון, יבוא וייצוא לאקסל. ואם הוא צריך לחצן לשליחת המידע לשרת חיצוני או כל תוספת אחרת אני פותח את קובץ הקונטרלר שנוצר ע"י הגנרטור, מוסיף פונקציה, ובמידת הצורך מוסיף view לזה וכו'.
אני מרגיש שזה הכי הוגן ללקוח, שמבחינתו אין לו הרבה נפק"מ האם הייתי בונה בPHP או בnodejs כאשר מה שדרוש לו הוא סה"כ שיגור הודעה טלפונית עם ממשק צפייה בתוצאות.

השימוש שתיארת על יצירה קלה של טבלאות וכו' אם איני טועה אין לזה קשר לPHP או נוד. היה לי בעבר משהו דומה, שאגב גם היה בPHP ואני מבין על מה אתה מדבר. מוסיף בקלות קונטרולר+VIEW והלקוח מקבל טבלה עם CURD וייצוא. אך מה שעושה את זה לפרקטי כ"כ זה לא הפריימוורק או השפה אלא כי זה פרוייקט ותיק ומושקע שלך שהכנת לך (במשך... ?) סט כלים מותאם לצרכיך. אם היית עושה אותו דבר בNODE לכאורה התוצאות היו לא פחות טובות כולל נוחות ומינימליסטיות השימוש.

[zvizvi]

@dovid אמר בתבניות של API:

@yossiz אמר בתבניות של API:

יש לי חבר שטוען לי כל הזמן ש-strapie היא התשובה לכל הבעיות של מפתחי נוד.

מזל שבסוף הואלת לכתוב על זה!
נראה מדהים וגם נראה שיעזור בהחלט ל@davidnead
לטובת המחפשים:
https://strapi.io/
https://github.com/strapi/strapi

בדגש על Strapi V4 שעכשיו בבטא, ובא לפתור הרבה בעיות (ויש הרבה) שישנן בגירסה הנוכחית

[davidnead]

טוב, למי שחשב שהתייאשתי.

בהמשך להתיעצות שלי עם ינון פרק, הוא הציע לי לבדוק על Ruby On Rails, הוא סבר שזה שלד תכנה שמתאים לציפיות שלי. אבל אני עקשן, אז קצת ויקיפדיה הוביל אותי לsailsjs שממש במוצהר אמור להיות תחליף בNode לRuby On Rails.

לפי ההצהרות שלהם זה עושה רושם טוב מאוד.
זה כולל יצירה אוטומטית של קונטרולרים+API, כולל יצירה ושינויים של DB ומודולים בהתאם, סוג DB חופשי לבחירתך. וצד לקוח חופשי גם כן.
בנוסף התכנה מגיעה עם אפשרות התקנה ריקה, או עם הבסיס של הרשאות ויוזרים וכו' מוכן. היא עובדת עם גנרטורים שזהבעצם הכלי החזק שמאפשר יצירת דברים בקלות - ובעיקר הרבה גנרטורים מוכנים מהקהילה שבעצם מאפשרים לתפור פאזל בקלות.

אז זה נשמע טוב, התחלתי לבדוק את זה. היו כמה דברים שמצאו חן בעיני (כמו למשל שזה שומר יחסית על קונבנציות ולא ממציא), ויש עוד כמה סימני שאלה משמעותיים (הראשון בהם הוא שהדיפולט שם הולך עם טמפלייטים של אקספרס והרבה מיקוד בMVC בהתאם).

אז לפני שאני ממשיך הלאה להשקיע שעות בלימוד המערכת ולראות כמה היא מתאימה לי, אני מנסה את מזלי אולי מישהו מכם התנסה בה ומכיר אותה ויכול לספר קצת עליה.

[מנצפך]

@davidnead
לא!

יש לי ניסיון בזה.
אל תתפתה ליכולת להשתמש בכמה מסדי נתונים, אין שום פרוייקט בחיים האמיתיים שהחליף מסד נתונים.

הSAILS משתמש בכל מיני ספריות לא מעודכנות. כמו waterLine שזה ה ORM הכי מזעזע שפגשתי.

אני לא מדבר על בעיות של זליגות זכרון שכמעט גרמו לי להתקף לב.
וחוץ מזה, זה JS ישן שלא תומך באמת ב CLASS וכל זה, הוא מייבא את הcontrollers שלך ע"י חיפוש כל ה *.JS בתיקיה...

לאחר מעשה, זה היה לי טוב בשביל להעלות מהר (ובלי ניסיון) פרוייקט.
היום אני מצטער שאני שם.
אני ממליץ לך בחום, קח תבנית מוכנה, שזה אומר מבחינתי, מבנה תיקיות ברור.
controllers
models
DAL
ועוד. אני בעצמי לא מומחה גדול למבנה פרוייקטים.
תחליט על איזה ORM שאתה רוצה (objectiveJS או sequlizeJS)
וצא לדרך.
מסד נתונים, זה לא קשור לכאן. אני אישית אוהב PG.
תשמור על הפרדה בין ה ORM לבין בcontrollers ע"י ה DAL (אני לא סגור שזה מה שה DAL אמור לעשות. אבל תעשה שכבה כזאת).
ואז תהיה חופשי מבחינת ORM.

שרת תשתמש ב EXPRESS

אל תבנה על איזה CLI שיבנה לך. זה סתם מסרבל ולא נותן כלום בהיקפים של צוות קטן. (1 +-...)

תפריד את הצד לקוח (SPA) לפרוייקט נפרד. לדעתי. וודאי שירוץ על שרת (סטטי) נפרד על Port אחר.

בהצלחה.