Hi all,
Sorry guy, I couldn't make it in time for the meeting.
My feedback below.
<wip>
## Notes
* Frontend will be rewritten
* Backend ? is this worth the rewrite ?
* Pyramid as a framework does not have a strong community and adoption
* Django is the industry standard for Python based web application
I did audit the code of both API and the monolithic pyramid app after flock and came to
the same conclusion (besides some design choices which don't make sense).
However, I would say not to rewrite the backend but to merge some of the backend's
badges management/call-flow w/in the API and provide only one service.
The frontend will then relies on this API.
This will also provide to admins a better interface to manage badges (awards, update,
adding, promote, etc).
* Current application is very slow
* Badges image are big
What I noticed is not all images are the same regarding sizing, ratio, format (looks like
more w/ the oldest).
Don't get me wrong, I'm talking about the image object, not the badge itself
* Needs to download a lot of data to load a page
* If rewrite this need to be kept in mind
This is a design concerns I'd say. Also, need to take into account the servers
(including their location) which serve those files.
We will have to make some architecture choices on how/what to display based on the page
the end-user is on and the load the page requires.
* Python2 dependencies not maintained
* Rewrite could also be porting current app to Django and slim down
the number of pages/feature
* maybe 1 user page and 1 admin page.
+1 w/ Miro's comments
I'd be in favor of using AIOHTTP which provides pretty good efficiency regarding
server load/speed, good feature out-of-the-box and so much more. I'd be glad to tell
more about it if you're interested in for those who don't know.
Also, we need to think about how an IT infrastructure will deploy such services based on
their architecture. How many instances, do they need a reverse-proxy in front of them, the
daily requests load, etc?
* Start with the frontend --using a JS framework and let the backend
with pyramid but just serve JSON instead of templates.
As I said above, I'd be in favor of removing pyramid (even though I support pyramid
and was one of those who voted to have it as a selected framework for infra dev)
But we need at some point to get thing right w/ the right tools when needed and for what I
say, I don't think Pyramid, Django would be a good fit.
* Refactoring Backend is difficult --> need experienced developer
there and a specification
* Focusing in on the pain point first will give improvement performance
I'd say a specification for *both* backend and frontend are def required. Specifically
when you're not skilled enough.
That would also help new contributor to jump in.
* Moving off the message driven backend would be good in order to make
the application more generic and not only Fedora centric.
* Potential to get more contributors from other communities.
* Virtual Hackfest - September 13-15th
* Idea to sit down and look at the technical pain point. Slow
Requests, Exception in the consumer etc
* Write these down and come up with a plan to improve these.
Why wait for Sept, 13?
I'd say let's start right now to dig this up.
To summarize:
In short term scenario, fix AMAP the slowness, while in the long term we start by
redesigning the API based on current call-flow w/ in mind an architecture that lets us
add/alter anything based on the redesign of the Front specification.
Cheers,
-x