תבניות של API

[davidnead]

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

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

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

[dovid]

@davidnead הטעות היא שלי, חשבתי שפריזמה זה דוטנט...

[dovid]

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

אז מה שאתה אומר לי שזה בעצם נכון שnodejs מתאים רק לפרוייקטים גדולים (כאלו שהקמת הפרוייקט זה החלק המאוד זניח)

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

[davidnead]

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

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

אז מה שאתה אומר לי שזה בעצם נכון שnodejs מתאים רק לפרוייקטים גדולים (כאלו שהקמת הפרוייקט זה החלק המאוד זניח)

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

כלומר אותו רעיון. פרנסה לא תוציא מזה...

[davidnead]

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

@davidnead תביא לי את הpackage.json של הפרוייקט האחרון שלך.

למשל?

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

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

[yossiz]

אין לי המון המון נסיון, אבל ממה שיש לי (שברובו בזכות מישהו אחר שאני רוכב בעיקר על הנסיון שלו)

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

הם בונים הכל מאפס? הם נעזרים במרכיבים שהם בנו עם הזמן?

כן וכן

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

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

(רק לענ"ד) התשובה אמורה להיות כן...

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

[dovid]

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

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

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

[davidnead]

@dovid
אני אמנם נדנדתי פה הרבה בשבועיים האחרונים, אבל במקביל גם עבדתי קשה ועשיתי המון שיעורי בית. חרשתי הרבה דברים כולל את הסטראפי הזה. לאף אחד לא התחברתי.
הסטראפי הזה אמור להיות מקבילה של וורדפרס רק בnode, וממילא הוא אמנם לא PHP אבל יש לו את החסרונות של מערכת ניהול תוכן. (לא רוצה למען השם לייצר את הDB שלי ע"י קוביות ושדות של UI). ויחד אם זה אין לו את עיקרה היתרון של וורדפרס - השפע של התוספים שמאפשרים לך באמת לתת מענה לכל הצרכים.
אתה מקבל CMS מינימלי שבקושי יש לו תבניות ותוספים, אבל גם קשה מאוד לפתח בתוכו ולהשתלב איתו מבחינת סרוור סייד.

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

היום מצאתי את מה שהיה נראה לי הכי קרוב: keystonejs

היה נשמע בוידיאו שהוא מתאר את הבעיה שלי מצוין ובא לתת עליה מענה. תכל'ס הורדתי למחשב ושיחקתי עם זה ולא באמת הבנתי מה אני מרוויח מזה.

[חוקר]

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

[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