Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 06 18:59
    iamareebjamal commented #2184
  • Feb 06 18:03
    PragatiVerma18 commented #2184
  • Feb 06 17:58
    PragatiVerma18 commented #2184
  • Feb 06 17:56
    PragatiVerma18 commented #2184
  • Feb 06 17:49
    iamareebjamal commented #2184
  • Feb 06 17:47
    PragatiVerma18 commented #2184
  • Feb 06 17:43
    PragatiVerma18 commented #2184
  • Feb 06 17:35
    iamareebjamal commented #2184
  • Feb 06 17:33
    PragatiVerma18 commented #2184
  • Feb 06 15:35
    Dishebh commented #2184
  • Feb 06 15:27
    PragatiVerma18 synchronize #2184
  • Feb 06 15:09
    PragatiVerma18 commented #2184
  • Feb 06 15:07
    Dishebh commented #2184
  • Feb 06 14:56
    PragatiVerma18 synchronize #2184
  • Feb 06 14:48
    iamareebjamal commented #2184
  • Feb 06 14:48
    iamareebjamal commented #2184
  • Feb 06 14:47
    Dishebh commented #2184
  • Feb 06 14:46
    PragatiVerma18 commented #2184
  • Feb 06 14:45
    iamareebjamal commented #2184
  • Feb 06 14:44
    PragatiVerma18 synchronize #2184
Raj Vaibhav Dubey
@rajvaibhavdubey
@kushthedude
Kush Trivedi
@kushthedude

@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.

Mario Behling
@mariobehling
@kushthedude @rajvaibhavdubey I have created a branch v2. Do you want to try to set up a frontend and backend with Django and ReactJS? https://github.com/fossasia/badgeyay/tree/v2
Kush Trivedi
@kushthedude

@rajvaibhavdubey

  • I have seen the v.1 of badgeyay, it would be nice to develop the server work with the minimal UI and then make the UI more scalable as it is done currently.
  • But on the contrary, badgeyay has a simple functionality to generate badges and manage them. And making the v.1 and then making a new UI may require quite more work.

@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.

Mario Behling
@mariobehling
Ok, let's look out for someone who can help with the transition. Currently we don't have someone strongly pushing the development forward. So, this is a good time to move ahead with an alternative.
@/all If anyone is interested to help with the transition of the project to Django + ReactJS, please go ahead :-)
Kush Trivedi
@kushthedude
I think we should consult Areeb for server queries. He has expert knowledge in python related stuff.
Asel Peiris
@AuraOfDivinity
@mariobehling I would be down to help if such rebooting takes place using React!
Mario Behling
@mariobehling
@AuraOfDivinity That is cool! Would you be able to set up a project structure for Django as a backend (in a backend folder) and ReactJS as a frontend (in a frontend folder) and make a PR to the branch V2, please?
Asel Peiris
@AuraOfDivinity
@mariobehling Im sorry. I'm not sure whether I'm the most suited for the job. I'm pretty new to web technologies (Been learning react the last month) but I'd definitely be down to contribute if someone else could take the lead and specify the required tasks!
Mario Behling
@mariobehling
:thumbsup:
Raj Vaibhav Dubey
@rajvaibhavdubey
@kushthedude @mariobehling I don't think we need to switch to Django, FLASK + React would be a pretty cool. What makes Badgeyay sloppy is emberJS. Besides Django is a comparatively heavy framework, Flask would be suitable for lightweight application as Badgeyay.
The workload would also reduce drastically by staying on FLASK, only the frontend changes need to be performed.
Areeb Jamal
@iamareebjamal
Flask is lightweight but it has many quirks because of unopinionated API. I would recommend Django as it is extremely popular and new developers don't need to learn new paradigm as with Flask. Every Flask app is new thing in itself. Integrations with flask also have quirks whereas they are readily available in Django. If there is a need of lightweight alternative, FASTAPI is better as it is much more lightweight and also async https://fastapi.tiangolo.com/
However, I still recommend Django because Django 3 will be async, and we should go with something that requires the least amount of maintenance of configuration
For frontend, I think Vue is amazing, because its learning curve is very low as compared to React and flexibility is also greater for people who don't like JSX. You have options to use SFC, class-based components and even JSX if you want, It has growing popularity and is used by large scale sites like GitLab. Given that, React is more mature and established, and has a bigger community and more libraries. So, if everyone is comfortable with React, then it is better to use it than Vue :+1:
Areeb Jamal
@iamareebjamal
Also, going in any direction, you should use next if using React and nuxt if Vue for the same benefits as Django for frontend. Opinionated architecture with the ability to go server-side rendered in the future. Nuxt has the option of static site generation as well which means the benefit of server side rendering at compile time without deploying any server
Also, recommend using TypeScript instead of JavaScript from the start to avoid bugs early and catch bugs at build time than at runtime
Areeb Jamal
@iamareebjamal
Commenting more on Flask and Django resource usage - open-event-server Flask server with many functionalities added which are in Django OOTB and other stuff, it runs 1 process with 120 MB RAM, of which you want to run at least 4 processes in you want any concurrency as single process handles 1 request at a time. A much more bulky Django server at the company I work at takes 180 MB per process. Not much difference for the benefits.
This won't be true for async framework since a single process can handle multiple requests concurrently, hence consuming less resources. A single 100 MB FASTAPI process can handle many requests/s whereas you need to run 10-20 Flask/Django processes to handle the same amount of requests synchronously. 10*150 MB = 1.5GB RAM
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).
Areeb Jamal
@iamareebjamal
So, depending upon the kind of work you mainly want to do on the server. I/O bound - DB, network access => async. CPU bound - image manipulation, computation => sync
Mario Behling
@mariobehling
@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.
Kush Trivedi
@kushthedude

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:

Also it would be great if you could help in reviewing PR's related to v.2 @iamareebjamal .

@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.

Areeb Jamal
@iamareebjamal
I think backend would make more sense, or else frontend will have to be rewritten twice. Once for current API and then new API
Mario Behling
@mariobehling
The frontend is not every far developed. There are a number of issues with it and they might get resolved quickly in React.
@kushthedude Please go ahead with setting up a clean project with Django as a backend and React as a frontend in V2 branch, if you have time. Or anyone else can also go ahead.
Sahil Bondre
@godcrampy
@mariobehling Hi, I'd like to help with the React part. Django + React seems like a good decision. I was thinking if we could chunk down the V2 issue into several smaller issues as this transition seems like a huge overhaul.
Suneet Srivastava
@codedsun
@godcrampy Yes, we have created a similar issue here.
fossasia/badgeyay#2168
Prateek Jain
@prateekj117
@iamareebjamal @mariobehling Would like to contribute to the development of the new badgeyay system.
Kush Trivedi
@kushthedude
@iamareebjamal Let's discuss the use-cases in the Badgeyay Meeting.
@mariobehling When will the next meeting be held?
Suneet Srivastava
@codedsun
@mariobehling Yes I also want to be get involved in the next meeting. Thanks
Mario Behling
@mariobehling
Hey, great to see so much interest in moving things forward. The current set of features is a good goal for a next version. We need the "badge-builder" to work in Django. Basic thing for the beginning: A way for people to login and reset an account etc. So, standard features that are available in Django. Right now there is not so much to discuss. Basically, we need developers to chime in and move the initial project forward.
Areeb Jamal
@iamareebjamal

@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/

  1. Loads in 15 seconds
  2. Blank page. Downloads 8 MB of Javascript
  3. Then calls the API and renders the HTML. User has to wait for 15 seconds
  4. The standard authentication flow is broken. User is logged out of every 24 hours and is more difficult to integrate than normal Django Auth Flow

Server Side Rendered - https://www.eventbrite.com/

  1. Loads in 2 seconds
  2. HTML and CSS right off the bat for the user. User can see the site as soon as HTML gets parsed. Javascript is there just to enhance the site
  3. Standard authentication flow in Django. So, no duplication of authentication/authorization in the backend and frontend. All auth lies in the server, so no bugs like a speaker can access admin panel because there was a bug in frontend. Or speaker can override email because there was a bug in backend. All logic remains in 1 place.

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 fine better with Django SSR and then JavaScript for enhancement. And badgeyay is even simpler. Django only will give a lot of benefits and an API can be made as a single source of truth for other clients.

All great websites follow the same pattern:

  1. GitHub - Rails mainly and jQuery to enhance
  2. GitLab - Rails + Vue to enhance
  3. Eventbrite - Django + React/jQuery to enhance (Create Event + Dashboards in JS)
  4. Meetup - Node.JS rendered React site

So, is there any specific reason we want to separate backend from frontend?

Not to say, it'd be much simpler workflow
Kush Trivedi
@kushthedude
@iamareebjamal I didnt know eventbrite is server side rendered !

Badgeyay is a small and simple service with the generation of badges and having its statistics. I think server-side rendering should be enough.

Client Side Rendered - https://open-event-fe.netlify.com/

  1. Loads in 15 seconds
  2. Blank page. Downloads 8 MB of Javascript
  3. Then calls the API and renders the HTML. User has to wait for 15 seconds
  4. The standard authentication flow is broken. User is logged out of every 24 hours and is more difficult to integrate than normal Django Auth Flow

Also, the reason for slow loading of our FE is due to the various dependencies we are using for simple tasks like scrolling or linking.

Areeb Jamal
@iamareebjamal
@kushthedude Any site with client side rendering will almost always have high time to interactive than server side rendered app. Because the content will be displayed after page load + JS fetch + execute + API fetch + render in client side vs page load + render in server side rendering
Only good use case for CSR SPA is an webapp (squoosh.app/proxx.app) or admin dashboard/analytics (Google Play Dev/Firebase Dashboard) because they will need client side rendering anyway.
Mario Behling
@mariobehling
@iamareebjamal Yes, agree. How to move ahead?
Areeb Jamal
@iamareebjamal
I'll approve the initial setup of Django and then move to discuss DB model structure
Mario Behling
@mariobehling
:thumbsup:
Ekta Arora
@ektaarora3501
@kushthedude I would like to work on Django backend part. Can you tell me current status and what we have to proceed next ??
Nikhil Vats
@Nikhil-Vats

@kushthedude Can you suggest me a solution for issue #2140?

The deploy to docker button is no longer available, it was there in the beta version of docs only. I can create a custom svg for the button. What do you think? Link to PR - #2157

Tanmay Rauth
@tanmayrauth
@mariobehling @iamareebjamal @kushthedude I would like to contribute to the development of the new badgeyay system. Can you tell me what should i do to proceed next ?
Nihal Pandey
@stark019
I am facing a problem with running frontend on my system can somebody help me through it.
Suneet Srivastava
@codedsun
yes @stark019 Please post your query
Nihal Pandey
@stark019
@codedsun I am unable to proceed further after running ember serve command