Open-event-server: Implementation of frontend framework and enahnced APIs

[mariobehling]

Using a frontend framework could allow new contributors to join UI development more easily. It would also allow developers to focus more.

What is required to make this happen? What is missing?

[niranjan94]

We need to think about an API-centric approach.

“An API-Centric Web Application is a web application that basically executes most, if not, all its functionality through API calls.”

An API-Centric approach will reduce code repetition and allow for an easier maintenance. Implementation of additional features in the future would also be easier.

This way, the organiser server will be completely decoupled from the python API server. (this would allow us to get a lot of frontend developers onboard who have little to zero experience with python)

So, to make this happen, we will need the following as a start.

• More API endpoints would need to be added to perform all the admin tasks too.
• We would require a front-end javascript framework.

For the frontend framework, we have loads of options. But I'd shortlist it to these three

• Ember.js - Has everything you'll ever need for building a huge web-applications. Pretty easy to learn. And the official documentation is awesome, detailed and very easy to understand. (_this is my preference though_ 😉)
• Vue.js - New kid on the block. Very easy to learn. But not as mature enough as the others, but under active-development.
• Angular - The overlord of javascript frameworks. Very well known. Typescript is pretty cool. Haven't used this one much but have heard it's pretty cool.

Now, coming to the API.

What do we already have ?

• Authentication
• Role-based control
• Basic CRUD operations
• Swagger docs

What we need ?

• We'll need to stick to a standard API schema. Preferably JSON API
• Need more endpoints since everything that is done right now in the server will need to be done via API calls.
  
  
  
  • Ticketing
  
  
  • Full-fledged event/ticket creation
  
  
  • Event statistics
  
  
  • Sales info
  
  
  • Admin settings
  
  
  • Notifications
  
  
  • Speaker invites. Proposal submission.
  
  

[niranjan94]

It would also be great to decouple the front-end from this repository and have this one for just the API server.

For example, repo could be renamed as open-event-api-server and the frontend could reside in open-event-frontend or open-event-organizer-frontend

[mariobehling]

@niranjan94

decouple the front-end from this repository

Yes, seems like a logical step, but I think this would come a bit later. How can we keep our current workflow and what are the next steps to decouple the front-end? Could you open issues, please and list them here?

[niranjan94]

@mariobehling if we go for a front-end framework, it would be best if we move it to a separate repo. Because that framework would have it's own build script, folder structure and tests and everything.

And before we open issues, we'll have to decide on a front-end framework

[mariobehling]

@niranjan94 Can we start with implementing the APIs first and solve the bugs of the system first to get the project more stable?

Starting a front-end repo - we should also think about our approach to design. What is a good approach here? Bootstrap, Material?

[niranjan94]

@mariobehling cool. We'll start with APIs first.

For frontend we need two frameworks. The app framework (js) and the UI framework. For UI, instead of the usual bootstrap or material, we could go with Semantic UI. Beautifully built. Professional looking. Highly customizable. has numerous components.

[niranjan94]

In-fact semantic UI has a lot of components that would be of great use to us.

[mariobehling]

@niranjan94 Ok, great.

1. About the APIs: Please open issues.

2. Semantic UI looks great, but I am worried that it is mainly depending on one developer for over a year.

3. Regarding the front-end actually an option would also be to split the current repo after the APIs are ready into a) API server and b) Python front-end, isn't it? So, actually there could be different front-ends.

[niranjan94]

About the APIs: Please open issues.

• Will open more issues about API @mariobehling

Semantic looks great, but I am worried that it is mainly depending on one developer for over a year.

• I'm not sure about that. It is actively developed. And also, if you take bootstrap into consideration, even now, we use a lot of third-party bootstrap plugins for various functionality that has less or sometimes even zero activity on their respective repos. But in the case of semantic, almost all of those are part of the core library. I have been using semantic for projects and I have never had a need to look for an external library since it was already part of it.

Regarding the front-end actually an option would also be to split the current repo after the APIs are ready into a) API server and b) Python front-end, isn't it? So, actually there could be different front-ends.

What is the use of a python-frontend ? The whole point of an API-centric project is to keep all the logic in one place (the API) and let everything else just use the API. (That way don't have code duplication.) So, why do we need a _python_ frontend. ?

[mariobehling]

What is the use of a python-frontend ?

The reason for my question is: How do we make the transition from the current one-stop solution? How long would the development of a new front-end take? If we would have a separate python-frontend we might be able separate the repositories rather earlier than later.

Anyways, the big questions are: What would be a realistic timeframe in which we could achieve a release (if we go with ember or angular plus semantic)? And, how can we keep the project running continuously as a service?

[niranjan94]

@mariobehling

If we would have a separate python-frontend we might be able separate the repositories rather earlier than later.

I don't agree on that. What we have right now is a frontend deeply coupled with the backend. (which is also a cause of issues for us and making it harder for maintenance). So, whatever it is, it's gonna take the same effort to separate them both.

I would suggest, once we start the work on API, the frontend work also starts. (I can setup a base frontend project with ember+semantic in day or two (angular might take a while longer for me as I haven't used it much) along with travis, eslint and basic API integration so that the work can start there too).

At one point, we would have to completely stop all work on the current python frontend and work only the API and new frontend.

A realistic time-frame ... 3 - 5 months of parallel work on both API and frontend to reach current frontend state. But then, once we reach that state, maintenance of code would be much easier compared to what we have now. Also, performance would also be great.

In the meantime, eventyay would still be running on the old frontend.

[niranjan94]

@mariobehling in fact, until the new frontend is done, we will still be maintaining the old frontend (with only minor bug fixes ... No feature additions) and API v1 (any breaking bug-fixes only) while working intensively on the API v2.

eventyay.com will be running on v1 until v2 is done (any breaking bugs will be fixed as hotfixes). staging.eventyay.com can start running v2 once we're at 25% of completion for testing.

[aviaryan]

@mariobehling @niranjan94
I also agree with switching to a separate frontend + a backend only server. In addition to the already discussed points here, here are some more reasons on why this will benefit our project in the long term.

1. BUGS - Most of the bugs we face are related to the frontend flow of the server. This is because frontend is very unorganized. Lots of logic has been included in the jinja templates. If we switch to a pure API frontend, the logic work done at frontend will greatly reduce and it's job will be majorly limited to sending and receiving data from the server. This will reduce bugs by a very high percentage.

2. Codebase - Frontend code is highly un-organized because a framework was never chosen from the start. This problem reproduces inductively i.e. if a new contributor sees the code as un-organized, he is most unlikely to work on it in an un-organized manner himself. This will go on and on and reduce code and application quality.

3. Standards - All the quality web apps we see (& use) are switching to a separate frontend for the same reasons.

While it may seem that this change can take lots of time, I feel the time spent on it will be well worth it in the long run.

[niranjan94]

Child-issues have been opened. Front-end repo created at fossasia/open-event-frontend. This discussion can be closed. More specific discussion issues could be opened if and when needed.

Closing this now.