תבניות של API

[davidnead]

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

@davidnead
האם אתה צריך אתרים מעוצבים ולכל לקוח אתר חדש נפרד לגמרי למטרות שלו? או שיש לך נישה מסויימת שמאחדת את האופי של הלקוחות שלך?
אני למשל נמצא בנישה שאני מפתח מערכות טלפוניות, אבל לכל לקוח יש לי ממשק נפרד לפי הצרכים שלו, טבלאות שונות, פעולות שונות, API שונה והתממשקות לשירותים חיצוניים שונים, וכמו"כ ההתממשקות עצמה מול המערכת הטלפונית (באמצעות API של ימות המשיח).
לפני כמה שנים חיפשתי פרימוורק שאוכל לבנות עליו ממשק טוב ומצאתי את YII2 זה בנוי בPHP, ובשונה מוורדפס שניתן לבנות איתו אתר שלם ללא לגעת בקוד, ב YII אתה חייב לגעת בקוד, זה מיועד רק למתכנתים, אבל עושה להם את החיים קלים יותר, יש בו CRUD מצויין, יש גנרטור שניתן ליצור לכל טבלה בד"ב את הקבצים הנדרשים, ולאחר יצירת המודל וכו' אתה יכול לשנות וכתוב מה שבא לך ולהשתמש במחלקות ופונקציות העזר שהפרימוורק מביא.
בניתי עם זה הרבה ממשקים ומאות טבלאות, ולכל לקוח יש גישה רק לטבלאות שלו, ולכל לקוח אני שם פונקציות והתממשקות לשירותים שונים לפי צרכיו.
אציין שאני כבר כמה שנים עובד עם זה, והתחלה הכרתי את היכולות הבסיסיות ביותר שלו, ועם הזמן למדתי אותו יותר ויותר לעומק, הוספתי לזה כל מיני פונקציות ושינויים בקבצי הליבה בעצמם, שידרגתי את הגנרטור, הוספתי אפשרות של ייבוא מאקסל שלא הייתה קיימת במקור, ועוד.
אני לא מכיר את Laravel אבל אני מאמין שזה משהו בסגנון.
אך במשך הזמן יצא לי פה ושם שהייתי צריך כל מיני אפשרויות בצד קליינט (ב YII מוטמע כבר bootstrap ו jquery) ונמשכתי לעבור לאפליקציות SPA מבודד צד לקוח וצד שרת.
עד שהגעתי לפרוייקט אחד מורכב מאוד שהייתי צריך הרבה השקעה בצד לקוח ולכן הלכתי על vue, הלכתי על תבנית בתשלום שקניתי כאן ובהשקעה של זמן מה הצלחתי ב"ה להקים ממשק בסיסי ואני מתקדם איתו ומעשיר את הידע בVUE.
כשהתחלתי לפתח את הממשק בVUE תיכננתי לעשות תבניות מסויימות ולהעשיר את ארגז הכלים שלי שאוכל להתחיל להקים את כל שאר המערכות שלי והממשקים שלי עם VUE בצד לקוח ו nodejs צד שרת.
אבל למעשה אני רואה שכשמגיע לקוח ומבקש לי שהוא צריך מערכת רישום מסויים שהוא נותן לי טבלת אברכים ושגר להם הודעה והם יבחרו האם להרשם וכדומה, הכי קל לי לעשות זאת עם הכלים הישנים, אני יוצר טבלה חדשה בד"ב, באמצעות הגרנרטור אני יוצר את קבצי ה PHP, מייבא את הטבלה, יוצר משתמש חדש, מוסיף לו הרשאת גישה לטבלה, מוסיף לו לחצן של קישור לטבלה, ושולח לו פרטי גישה וסיימתי. הלקוח מקבל לינק, נכנס עם פרטי הגישה, יש לו כפתור "רישום ל...", הוא נכנס, יש לו טבלה עם אפשרות צפייה ועריכה ומחיקת והוספת שורה, סינון ומיון, יבוא וייצוא לאקסל. ואם הוא צריך לחצן לשליחת המידע לשרת חיצוני או כל תוספת אחרת אני פותח את קובץ הקונטרלר שנוצר ע"י הגנרטור, מוסיף פונקציה, ובמידת הצורך מוסיף view לזה וכו'.
אני מרגיש שזה הכי הוגן ללקוח, שמבחינתו אין לו הרבה נפק"מ האם הייתי בונה בPHP או בnodejs כאשר מה שדרוש לו הוא סה"כ שיגור הודעה טלפונית עם ממשק צפייה בתוצאות.
אולי אם יהיה לי יותר זמן אוכל לכתוב פוסט אחר נפרד על הרשמים שלי מPHP מול nodejs שאם שניהם אני עובד כל הזמן.
מה באתי לומר כאן?
הייתי בטוח שאחרי שאהיה בקי בטכנולוגיה החדשה אתחיל לפתח הכל שם, באה המציאות והוכיחה לי בפנים שזה לא בדיוק, אלא תמיד אצטרך לחשוב מה טוב וכדאי להשקיע ללקוח הנוכחי.
ייתכן שזה באמת מהלך טוב להכיר 2 טכנולוגיות חלוקות ולהתרגל להשתמש בכל אחת לצרכים שהיא מתאימה.

ראשית - לא. אין שום מכנה משותף ללקוחות שלי.

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

לגבי התבנית שהבאת - עברתי גם על תבניות VUE וזו אכן נראת מצוינת. מה זה laravel המדובר שם?

[חוקר]

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

מה זה laravel המדובר שם

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


דהיינו התוצאה הסופית היא אותה תצוגה רק ששפת הפיתוח שונה
למשל ב laravel הממשק מבוסס גם צד שרת לכתחילה

[davidnead]

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

למשל ב laravel הממשק מבוסס גם צד שרת לכתחילה

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

[חוקר]

@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 אחר.

בהצלחה.