ParthS007 on gh-pages
Travis CI Clean Deploy abad11d (compare)
rajvaibhavdubey on development
fixes version for marshmallow-j… (compare)
ember serveI get a blank page
I understand that v9.11.2 was recommended but then I got this error.
error firstname.lastname@example.org: The engine "node" is incompatible with this module. Expected version "6.* || 8.* || >= 10.*". Got "9.11.2" error Found incompatible module.
So I used the latest version of node
Here is a question for you: What do we do with this project?
How can we move away from Firebase? The original idea was that we will be fast developing an app using Firebase, but this was nearly two years ago. So, it has not worked out and instead resulted in making the project dependent on a proprietary service, that we even have to pay for.
Secondly, EmberJS is always a great solution, but the community is also smaller than let's say for ReactJS. We have good experience with ReactJS with SUSI.AI and a lot of people contribute.
Thirdly, the question is about Flask in this project. It is a great tool for small projects, but a lot of things need to be developed from scratch. It can be very fast and easily customized, but we have to develop a lot of components ourselves. Alternatively Django already has a lot of components, e.g. for commerce that can just be plugged in. It is also Python and we could potentially re-use existing code.
Due to our limited resources and earlier choices we were not able to push this project a lot forward. So, we should go a step back and discuss a reboot of v2 for this project. What are your ideas? @gabru-md @ParthS007 @abishekvashok @kushthedude @yashLadha
Also, I think the main purpose of badgeyay is to get integrated with Eventyay. And we could easily generate
Event Badges from the
Event Dashboard itself. I think it would be better if we can get an opinion from Open Event Mentors too for the reboot of V.2 BadgeYAY.
@kushthedude I don't know where the idea comes from that Badgeyay needs to be integrated with Eventyay. It should rather be ready to be used/integrated with any list or service that provides events including eventbrite, eventnook etc. We could use the project to open up proprietary services step by step.
That is more beneficial. Proving badgeyay as an independent service.
@kushthedude What would be necessary to do for the reboot using Django and ReactJS? What are the next steps?
@mariobehling I think we should first gather intel from the mentors already working on the python related projects and ex-GSoCer who have worked on badgeyay. And then we can choose the right development cycle for the reboot.
FASTAPI is faster in throughput than even Node or Go (due to starlette) so take these things into consideration (Python is considered about 20x slow than Node).
But Django and Flask will be staying till later period as you said @iamareebjamal :wink:
@iamareebjamal Thanks a lot for this detailed feedback! Looks like Django + ReactJS would be a good choice as community backing and maturity is an important point. If anyone wants to start please make a PR to the v2 branch.
@mariobehling We should also make decision which thing to go for first, Making the migration to react or migrating to django. As doing both simultaneously may get ugly.
@mariobehling If the goals are that simple, why create a separate frontend (react). We don't have any dynamic component, so a server side rendered site will be better than a client-side rendered site.
Difference can be seen here.
Client Side Rendered - https://open-event-fe.netlify.com/
Server Side Rendered - https://www.eventbrite.com/
It can be said that open-event-server was a complex piece of software (frontend wise), so it made sense to separate its backend and frontend, but eventbrite is as complex if not more and they have done
All great websites follow the same pattern:
So, is there any specific reason we want to separate backend from frontend?